What TLS protects and where that protection ends
TLS protects application data in transit against eavesdropping and modification and enables authentication of the peer. In the usual HTTPS case, the server demonstrates its identity through a certificate. This does not authenticate a user account. A phishing site can also have a valid certificate for its own domain name. Application vulnerabilities, compromised devices and data after decryption remain separate concerns. RFC 9325: security services.
The connection ends at the TLS endpoint. If a CDN or reverse proxy sits in front of the origin server, the browser's HTTPS connection initially protects the path to that intermediary. The onward connection to the origin needs its own appropriate protection, including certificate verification. A positive browser finding at the CDN does not establish the security of this internal path. Implementation and architecture explains responsibilities and verification points.
Understanding TLS 1.2 and TLS 1.3
TLS 1.3 is the preferred basis for modern HTTPS services. Since July 2026, RFC 9846 has replaced the original RFC 8446 specification. This is a backwards-compatible update to TLS 1.3 with clarified and stricter requirements, not a new version number. TLS 1.0 and 1.1 must no longer be negotiated under RFC 8996. Suitably configured TLS 1.2 support may remain relevant for clients you need to support. RFC 9846 §1.2, RFC 8996, RFC 9325.
On narrow screens, scroll the table sideways.
| Property | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Normal full handshake | Typically two TLS round trips | Typically one; additional negotiation can require more |
| Cipher suite | Combines several algorithm choices | Determines AEAD encryption and hash; key exchange and signature are selected separately |
| Static RSA key exchange | Historically available; do not select it for secure modern operation | Removed; this does not generally exclude RSA certificates |
| Forward secrecy | For example, with ephemeral ECDHE | Depends on the mode; consider PSK-only and early data separately |
| Handshake visibility | Large parts, including the certificate, are unencrypted | Encrypted after ServerHello; this does not hide the initial ClientHello |
The round trips are not a guaranteed page load time and do not include a preceding TCP connection establishment. Resumption, HelloRetryRequest and other transport variants change the sequence.
Forward secrecy means that later compromise of long-term keys does not readily allow earlier session data to be decrypted. The algorithms actually selected and the handling of ephemeral keys must support this. TLS 1.3 also permits PSK-only operation without a fresh asymmetric exchange. 0-RTT data has no general replay guarantee across connections: an early request may arrive more than once. Enable early data only with an explicit application design; bookings, payments and other state changes must not become repeatable simply for the sake of a fast handshake. RFC 9846 §§2.2–2.3 and 8.
Examples in the TLS 1.3 base specification are TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. It also includes TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256; the latter has a shortened authentication tag and its own usage limits. This list is not a recommendation to enable every variant, a complete future registry or a universal ranking for mobile devices or servers. Use maintained profiles for your actual TLS stack and assess them against your requirements. RFC 9846: cipher suites.
A testing platform also has its own rating criteria: the SSL Labs Rating Guide consulted for this article caps the grade at A− without TLS 1.3. This establishes neither a legal duty to use TLS 1.3 nor an automatic A+ after enabling it. Qualys SSL Labs: Rating Guide 2009r.
Check names, validity and the trust chain separately
Schematic explanation · not a measurement
Certificate path and trust decision
Verifying client
Root accepted locally as a trust anchor
The client also checks:
- Name in the SAN
- Validity period
- Path and client rules
TLS endpoint
- Leaf certificate
The server's key and identities.
- Required intermediate certificates
Connect the leaf to the rest of the certificate path.
The server sends the leaf and intermediate certificates to the client.
Sending a root certificate from the server does not itself establish trust. The verifying client decides whether to accept the anchor.
Simplified path; alternative chains and client policies are possible.
A certificate associates a public key with specific identities and conditions. HTTPS needs these checks in particular:
On narrow screens, scroll the table sideways.
| Check | What must be correct | Common misconception |
|---|---|---|
| Target name | The DNS name being contacted has a matching Subject Alternative Name (SAN); an IP target needs a matching IP SAN | A certificate for example.com automatically covers www.example.com |
| Time | The verification time falls between notBefore and notAfter; the client clock is correct | “Valid for another 30 days” already proves trust |
| Path | Signatures and conditions along the certificate chain lead to a trust anchor accepted by this client | A supplied self-signed root certificate must therefore be trusted |
| Usage and rules | Key usage, constraints, algorithms and applicable client rules are satisfied | A positive Node check is equivalent to every browser check |
RFC 9525 places the server identity in the SAN; a Common Name alone does not meet this current naming model. *.example.com can cover exactly one leftmost name level, such as shop.example.com, but neither example.com nor a.b.example.com. A DNS SAN for a name does not replace an IP SAN when connecting directly to an IP address. RFC 9525 §§6–7 and Appendix A.
The server usually supplies its leaf certificate and the required intermediate certificates. The client uses them and its trust store to build a path. A trust anchor does not become trustworthy merely because the server sends it. Different root stores, caches, software versions and enterprise rules can produce different results. Mozilla's policy describes its own trust store and scope. RFC 5280 §6, Mozilla Root Store Policy.
Server Name Indication (SNI) helps a server hosting several websites select the appropriate certificate for the requested name. Connecting only to the IP without correctly sending and checking the name can accidentally test the default certificate. SNI selection and subsequent name verification serve different purposes.
Choose certificates and make renewal reliable
The following CA/B maximum validity periods apply to newly issued publicly trusted TLS subscriber certificates. They concern the certificate's total lifetime, not its remaining validity at the time of a scan, and do not apply to every private enterprise PKI.
On narrow screens, scroll the table sideways.
| Issuance date | Maximum validity | Maximum reuse of domain/IP validation |
|---|---|---|
| 15 March 2026 to before 15 March 2027 | 200 days | 200 days |
| 15 March 2027 to before 15 March 2029 | 100 days | 100 days |
| From 15 March 2029 | 47 days | 10 days |
The CA/B rules recommend slightly shorter validity periods than each absolute maximum. Individual validation methods and providers can impose stricter limits. The dates do not retrospectively shorten certificates already issued; renewals are new issuances. Reuse of identity data and certificate validity are separate rules. CA/B Baseline Requirements §§4.2.1 and 6.3.2.
ACME automates domain control validation and issuance, among other steps. The validity rule does not generally require ACME as the only method. Choose automation that fits the CA, hosting and permissions. DNS-based validation can require extensive DNS access; restrict it to the necessary tasks where possible. HTTP-based validation must reach the correct endpoint despite redirects, CDNs and access controls. RFC 8555.
A reliable process involves more than a successful issuance request:
- Inventory every certificate and TLS endpoint, including CDNs, origins, subdomains and alternative names.
- Issue and renew well before expiry; report failures to a responsible person or team.
- Deploy the new certificate, private key and chain in a controlled way and correctly reload the affected service.
- Check externally which certificate is actually served; account for distribution across multiple nodes.
- Monitor remaining validity and failed renewals independently. If a key is lost or compromised, arrange replacement and revocation with the CA.
A short lifetime reduces certain exposure periods but does not replace these checks. Six hours of remaining certificate validity can be normal or an urgent risk: what matters is whether the next successful replacement is evidenced and possible in time.
With ECDSA or RSA, distinguish the server key, CA signature and negotiated key exchange. An RSA leaf certificate can, for example, be signed by an ECDSA CA. ECDSA P-256 provides compact keys and is a common option for current clients. RSA is not restricted to Windows XP. Decide based on client requirements, security strength, the CA and the TLS implementation.
A blanket claim that “256-bit ECDSA and 2048-bit RSA are equally secure” would be wrong: NIST assigns RSA-2048 approximately 112 bits of classical security strength, and RSA-3072 and 256-bit ECC approximately 128 bits. This classification does not establish quantum resistance. Likewise, “a 64-byte ECDSA signature” describes a raw format, not every DER-encoded TLS/X.509 signature; the latter's length varies. Total certificate size also depends on names, extensions and the issuer chain. Assess speed and CPU costs for the specific implementation. NIST SP 800-57 Part 1 Rev. 5, Table 2, RFC 9846 §4.3.3.
Revocation and Certificate Transparency
A CA can revoke a certificate before it expires. The revocation information a client uses and how it responds to failures depend on its implementation and configuration. OCSP stapling sends a signed status response during the TLS handshake and can avoid a separate client request. This requires suitable CA and client support and a fresh, valid response. The presence of a staple does not establish its validity without verification; its absence is not a defect for every CA either.
Let's Encrypt discontinued its OCSP responders on 6 August 2025 and uses CRLs for revocation information. Do not therefore inherit a blanket OCSP requirement from older configuration examples. For other CAs, check their current service and your clients' requirements. Let's Encrypt: ending OCSP support.
Certificate Transparency (CT) makes certificate issuance verifiable through logging services and helps detect unexpected certificates. A Signed Certificate Timestamp (SCT) is initially a signed promise from a log. The presence of SCT structures proves neither that their signatures have been verified, that inclusion has occurred, nor that every browser rule is satisfied. Chrome considers factors including the number of SCTs, distinct operators and log status; delivery methods and version boundaries also matter. Chrome CT Policy.
Post-quantum methods and technical requirements
Hybrid key agreement combines a classical method with a post-quantum cryptographic method. The client, server and negotiated group must support this combination. It protects a different part of the connection from the certificate signature. TLS 1.3 alone is not evidence of PQC. In the local check documented for the German source, TLS 1.3 ran with both X25519 and P-256; both observations involved classical key agreement.
Adoption figures need a denominator: Cloudflare reported that post-quantum encryption accounted for 52 per cent of human-generated web traffic in its observation base in early December 2025. This is a dated operator observation, not evidence of the same share across all HTTPS traffic or of your website's configuration. Cloudflare Radar: 2025 year in review.
BSI TR-02102-2, version 2026-01, prefers TLS 1.3 and continues to recommend suitable TLS 1.2 configurations until the end of 2031. It also recommends exclusively classical key agreement only until the end of 2031. Algorithm lists, minimum key lengths and scope must be read together: §3.6 specifies at least 3000 bits for RSA signature keys. The recommendation for certain PKCS#1 v1.5 signature schemes ended in 2025; this does not automatically give every existing RSA certificate an expiry date. The technical guideline replaces neither an implementation check nor a risk assessment. BSI TR-02102-2.
PCI DSS requires strong cryptography within its applicable scope. PCI SSC explicitly clarifies that PCI DSS does not prescribe one particular TLS version across the board; SSL and vulnerable early TLS do not meet the requirement. A protocol number alone is therefore insufficient here too. PCI SSC: FAQ on TLS versions.
NIS2 and §30 of Germany's BSIG require appropriate measures and cryptography policies for entities within scope. Whether particular technical specifications are binding depends on the applicable scope and obligation. Neither HTTPS nor a scanner grade establishes comprehensive legal compliance. Web security and compliance explains the legal context.
Practical checks and interpreting findings
Test with the required name, SNI, enabled name and trust verification, and a known client version. A read-only diagnostic example for a domain you own is:
openssl s_client -connect www.example.com:443 \
-servername www.example.com -verify_hostname www.example.com \
-verify_return_error -showcerts </dev/nullReplace the example domain. The OpenSSL trust store used must be appropriate for the target; for an internal PKI, explicitly provide the intended CA store. -showcerts displays the certificates sent by the server, not a chain already verified. Without -verify_return_error, the diagnostic tool can continue despite verification errors. The result says nothing about every other browser, location or certificate variant. OpenSSL s_client.
The Web Security Check can capture the negotiated TLS version, cipher and limited certificate findings. After an HTTPS redirect, the separate TLS check generally describes the final HTTPS host; the result records the tested host and any host change. This is not an individual check of every intermediate redirect destination. DNS and other subsidiary checks may refer to a different starting point.
The TLS check connects to a vetted IP address and assesses certificate trust using Node/OpenSSL plus an additional name check. For analysis, it can also contact a server with an invalid certificate; an established connection therefore does not mean “trusted”. Time validity, trust and name errors must be read together. The public check inventories neither all protocols and ciphers nor every CDN node, browser root store or internal connection. This TCP-based TLS check does not cover HTTP/3 over QUIC either.
The additional legacy check establishes support for old TLS only after successful negotiation. Failure can also be caused by the test client or transport. The CT evaluation reads embedded structures in a separate retrieval; it does not verify SCT signatures, log inclusion or full browser CT compliance. The check also establishes neither OCSP validation, successful future renewal nor a complete PQC assessment.
The local counterchecks documented for the German source tested a missing intermediate certificate, an unknown root, an incorrect name, an expired certificate and a certificate not yet valid separately. Node could also accept a test certificate whose name appeared only in the Common Name. This illustrates the boundary between a particular verifying client and current naming rules; it is not a recommendation to omit SAN. Repeat the decisive cases with the clients you actually support.
Frequently asked questions
Is a valid certificate enough to make a website secure?
No. Names, the trust chain and the connection must be correct; the application, access rights and data processing remain separate responsibilities.
Do I have to use TLS 1.3?
It is the preferred basis for new implementations. A specific legal or contractual requirement must be established from the rules that apply. TLS 1.0 and 1.1 must no longer be negotiated under the current protocol requirements.
Does TLS 1.3 rule out RSA?
No. The removed static RSA key exchange is different from an RSA server key or an RSA certificate signature. Check the algorithm, key length and client support separately.
Must every certificate already be renewed within 47 days?
No. The 47-day maximum validity applies to the relevant new public certificates from 15 March 2029. Providers may already offer shorter profiles. Renewal and deployment should always be automated and monitored in good time.
Do I need OCSP stapling?
That depends on the CA, certificate and clients. An OCSP staple is not a general operational requirement for current Let's Encrypt certificates.
Does TLS 1.3 prove a hybrid post-quantum handshake?
No. You need to check the group actually negotiated. Certificate authentication and key agreement remain separate aspects.
Further reading and implementation
HSTS complements the move to HTTPS, while DNS security covers DNSSEC and CAA. Implementation architecture connects public responses, proxies and operations.
Sources and review date
Source review: 27 September 2026. The German source was technically reviewed against the linked primary sources. RFCs define mechanisms, CA/B and root store rules define their own scope, and BSI and PCI set different requirements or recommendations. The local synthetic checks establish limited Node/OpenSSL observations; they are not browser, operator or compliance acceptance tests.