After the handshake mechanics, TLS has a payload problem: the certificate chain rides in the server’s first flight, and revocation checking historically added third-party lookups on the client’s critical path. Both are optimizable, both are usually ignored, and at edge scale both are measurable.
Chain size is flight size
The server’s certificate plus intermediates must fit in the handshake flight; oversized chains spill into extra round trips exactly where you were trying to save them. Practical hygiene: send the leaf and required intermediates only, never the root (clients hold roots already), prefer ECDSA certificates whose signatures are dramatically smaller than RSA’s, and audit what your edge actually serves, because default bundles love shipping redundant certificates.
Revocation, from broken to stapled
Classic OCSP had the client ask the CA whether the certificate was revoked: a third-party lookup, on the critical path, that failed open when the CA was slow, privacy-leaking and performance-hostile at once. OCSP stapling inverts it: the server fetches the signed revocation status periodically and staples it into the handshake, so clients verify freshness without any external call. The ecosystem has since moved further, with short-lived certificates and browser-side revocation lists shrinking OCSP’s role, but stapling remains the correct posture wherever it applies.
The certificate-lifetime trend is worth tracking as an operational planning item: maximum public certificate validity has compressed repeatedly, and the industry direction points toward lifetimes short enough that revocation becomes nearly moot, certificates expire before revocation would matter. For infrastructure teams this converts certificate management from an annual ceremony into continuous automation, and it makes your CDN’s certificate automation quality, issuance, renewal, deployment lag across the fleet, a genuine selection criterion. Ask vendors how long a renewed certificate takes to reach every edge node; the answers range from seconds to embarrassing.
What your CDN should be doing
Managed edge TLS should handle all of this invisibly: tight chains, ECDSA-first with RSA fallback, stapling maintained with valid responses, session tickets rotated. Verify rather than assume: an SSL testing tool against your production hostnames reveals chain bloat, missing staples and protocol posture in one report. When the CDN manages certificates, misconfiguration here is their bug and your ticket; when you bring your own, the hygiene list above is yours.
In practice
Run the test suite against every production hostname quarterly and diff the results: chains grow when certificates renew through new intermediates, staples silently lapse, and configuration migrations reset defaults. Fifteen minutes of scheduled verification keeps a class of slow regressions out of your handshake, and the report doubles as evidence when a vendor claims everything is fine.
Our provider scorecards include TLS hygiene as tested, not as documented. The gaps between the two are the findings.