Check What the HTTPS Padlock Actually Proves

The padlock answers a narrow question: is this connection encrypted to the hostname in the certificate? It does not say the business is honest, the page is free of malicious code, or the person who registered the domain is who you hoped they were.

That is still an important promise. It is just a transport promise, so test it like one.

Inspect the real handshake

Start with the public hostname rather than a certificate file copied from a dashboard:

openssl s_client -connect app.example.com:443 \
  -servername app.example.com -showcerts </dev/null

Verify four things separately:

The hostname appears in the certificate's Subject Alternative Names.
The leaf and intermediate certificates build to a trusted root.
Every required certificate is within its validity window.
HTTP redirects finish on the intended HTTPS hostname.

The -servername flag matters because many servers host several domains on one IP. Without SNI, you can inspect the wrong certificate and spend an hour debugging evidence from another virtual host.

Keep transport and application trust separate

A phishing site can have a perfectly valid certificate. So can an app that leaks data after the TLS connection reaches it. Put the remaining checks in a different column:

Who controls the domain and account?
Does the page load scripts from unexpected origins?
Does the app authorize this user for this data?
Are redirects and callback URLs restricted?
Is sensitive information exposed after decryption at the server?

The padlock is telling the truth. It is answering a different question.

Never fix TLS by disabling TLS

Flags such as -k, --insecure, or rejectUnauthorized: false are useful only as a labeled diagnostic to prove certificate verification is the failing layer. They are not production fixes. The repair is the correct hostname, chain, trust store, or renewal.

Add a renewal alert with enough lead time to investigate the full chain. Also test every hostname users actually visit, including www, API subdomains, redirects, and callback endpoints. One valid certificate on the apex does not cover an unlisted name.

What Claude can help with

Claude can turn handshake output into a checklist and separate certificate facts from application risks. It should not label a site safe based on a valid certificate. The workflow makes that boundary explicit and keeps the raw chain, dates, and redirect targets as evidence.

Run the starter locally

npm test
npm run validate
npm run sample

The safe dry-run returns a reviewable report shape. Docker Compose adds n8n for orchestration. No certificate, DNS record, or server configuration is changed by the starter.