HTTPS and TLS Certificates Explained

HTTPS is HTTP carried through Transport Layer Security. TLS encrypts data in transit, detects modification and normally authenticates the server’s hostname with a certificate. Those properties protect the connection between client and endpoint; they do not guarantee that the site’s content is honest, that the endpoint is uncompromised, or that data is handled safely after arrival.

TLS versus SSL terminology

Secure Sockets Layer was the predecessor to TLS. SSL versions are obsolete and should not be negotiated, but “SSL certificate” remains common language for the certificate used by a TLS website. A modern checker may retain the familiar name while validating a TLS connection with current system trust rules.

What happens during a TLS connection

The client opens a TCP connection, or another supported transport for newer HTTP versions, then begins a TLS handshake. It offers protocol parameters and a server name. The server selects compatible cryptography, presents a certificate chain and proves possession of the private key. The client validates the chain and hostname. Both sides derive session keys, after which HTTP messages can be encrypted and integrity-protected.

Modern TLS uses ephemeral key agreement in common configurations, which can provide forward secrecy: later compromise of a certificate private key does not automatically decrypt previously captured sessions. Exact guarantees depend on the negotiated protocol and cipher suite.

Certificate identity

A certificate contains a public key, validity dates, issuer, extensions and one or more names. Browsers use the Subject Alternative Name extension for hostname matching. A certificate for www.example.com does not automatically cover example.com; both need suitable entries. A wildcard such as *.example.com generally covers one label like shop.example.com, not the apex or several nested labels.

The SSL Certificate Checker connects on port 443 using the submitted hostname for SNI and certificate verification. A successful result means the current chain is trusted under that environment, the dates are acceptable, and the requested hostname matches. It is still one connection at one time.

Certificate authorities and trust

A public certificate authority signs certificates under policies enforced by browser and operating-system trust programs. Servers often send an end-entity certificate plus intermediate certificates. The client attempts to build a chain to a root already in its trust store. Roots are usually not sent because the client must possess and trust one independently.

Different clients can reach different results if their trust stores, clocks, supported algorithms or cached intermediates differ. A server that omits an intermediate may work on a device that cached it and fail on a clean client. Private organizations can also operate internal CAs trusted only on managed devices.

SNI and shared hosting

Many HTTPS sites share an IP address. Server Name Indication carries the intended hostname early enough for the server to choose the correct certificate and virtual host. Connecting to the numeric address without the hostname can yield a default certificate or wrong content. A safe diagnostic that pins a resolved IP must still preserve the original hostname for SNI, Host and certificate verification.

Expiration and renewal

Certificates are valid only between their not-before and not-after times. Short lifetimes reduce the period in which stale authorization remains useful and encourage automated renewal. “Days remaining” is operational context, not a linear security score: a certificate with one day left can be fully valid now, while a long-lived certificate can have a hostname mismatch or untrusted issuer.

Renewal can fail because of an expired domain-control challenge, DNS or firewall changes, rate limits, account problems, or a deployment that did not reload new files. Monitoring should test the certificate actually presented from outside the service, not merely inspect a file on one server.

Common certificate errors

HTTPS, redirects and HSTS

A site often redirects HTTP to HTTPS. The first HTTP request is still unencrypted, so HSTS can tell a browser that has learned the policy to upgrade future requests before sending them. Preload lists can provide that knowledge earlier, subject to browser rules. HSTS does not repair an invalid certificate: once HTTPS is required, validation still has to succeed.

Use the Website Status Checker or Redirect Checker to see whether a URL ends at HTTPS. A redirect demonstrates navigation behavior, while the certificate checker demonstrates TLS identity and trust. They answer complementary questions.

What encryption does and does not reveal

TLS protects HTTP paths, headers and bodies from ordinary observers between endpoints. Network observers can still learn connection metadata such as IP addresses, timing and volume. DNS may reveal names unless an encrypted resolver path is used, and SNI visibility depends on protocol support and deployment. The destination server necessarily handles plaintext application data after decryption.

HTTPS is essential transport protection, not a trust badge for content. Phishing sites can obtain valid certificates for names they control. Users still need to inspect the domain, and operators still need secure applications, access control, updates and careful data handling.