🔒 TLS / SSL Internals

Yes, for most purposes. TLS 1.2 with ECDHE and a modern AEAD cipher suite (AES-GCM, ChaCha20-Poly1305) is considered secure as of 2025. The main reason to target TLS 1.3 is the 1-RTT latency improvement and the reduced attack surface (no renegotiation, no CBC modes, no static RSA). If you have clients that only support TLS 1.2 (very old embedded devices, some corporate proxies), TLS 1.2 with a strong cipher suite is acceptable. But TLS 1.2 configurations often drift toward weak cipher suites in practice — TLS 1.3 eliminates that risk by removing the weak options entirely.

A key is a number (e.g., 32 random bytes for X25519). A certificate is a structured document (X.509 DER ASN.1) that binds a key to an identity. The certificate contains the public key, the subject (hostname or organization), the issuer (which CA signed it), a validity window, and extensions (SANs, key usage). The CA signs the certificate with its own private key. A client verifies the signature using the CA's public key (from the CA's own certificate).

The certificate contains a public key of a specific type (RSA, ECDSA P-256, or Ed25519). The TLS handshake signature (CertificateVerify) is made with the corresponding private key. In TLS 1.3, authentication is negotiated separately from the AEAD cipher — the signature_algorithms extension lists which signature types the client accepts; the server picks one that matches its certificate. So if a server has an ECDSA P-256 certificate, it will sign with ECDSA P-256; the cipher suite only specifies the data encryption (e.g., AES-128-GCM). This separation is new in TLS 1.3.

There's no hard protocol limit, but basicConstraints: cA: TRUE, pathlen: N on an intermediate caps how many additional CA levels can be signed below it. A pathlen of 0 means that intermediate cannot sign any further CA certificates — it can only sign leaf certs. This is how CAs limit chain depth. RFC 5280 recommends chains no deeper than 4 certificates; browsers typically enforce stricter limits. Deep chains (4+ hops) add latency and increase failure probability.

For public internet-facing services: no. Browsers and clients will reject self-signed certificates unless explicitly configured to trust them. For internal services, dev/test environments, and mTLS where both sides are configured in advance: yes. Self-signed certs are appropriate when you control both sides of the connection and can configure the client to trust the cert by thumbprint (HPKP-style) or by installing the CA cert in the trust store. Kubernetes ingress controllers often use self-signed certs internally with cert-manager managing the rotation.

A certificate's validity window is only one of ~15 checks a browser performs. Common reasons for "insecure" despite a valid cert: (1) the hostname doesn't match — the SANs don't include the hostname you're visiting; (2) the certificate chain is incomplete — the server didn't send intermediate certs; (3) revocation check failed hard (must-staple cert with no valid OCSP response); (4) the certificate was issued after the cert was revoked; (5) CT log checks failed in Chrome — the cert doesn't have sufficient SCTs for the browser's CT policy. Use openssl s_client -connect example.com:443 -showcerts and sslsabs.com to debug.

Certificate Transparency (RFC 6962) is a logging infrastructure that requires CAs to publish every certificate they issue to publicly auditable CT logs. Each certificate includes Signed Certificate Timestamps (SCTs) — proofs that the certificate was logged. Browsers check CT logs to detect misissued certificates (CAs accidentally issuing certs for domains they don't control). Chrome requires EV certs to have at least 2 embedded SCTs; DV certs issued after April 2018 must also have SCTs. CT doesn't replace the CA trust model — it's an auditing layer on top of it. You can't validate a cert against CT logs yourself without downloading and checking against the log's Merkle tree, but you can view issued certs at crt.sh.