What should you test before changing a TLS certificate?
Asked by
MellowPine47
A certificate was replaced a few months ago and appeared to work normally in Chrome and the test environment. After the change reached production, several older phones and a partner application could no longer connect. The problem was discovered only after deployment. What checks do you run before a certificate change to catch compatibility issues across older devices, browsers, and non-browser clients?
Answers
Be careful with DNS and edge-case browser behavior too. Split-horizon DNS, HTTPS records, proxies, and newer features such as Encrypted Client Hello can make different browsers reach different endpoints or present different certificates. Compare DNS answers and the actual handshake from each network and client when the results do not line up.
Reply to this answer
Check the certificate with an external TLS scanner before deployment, then test it from the same kinds of clients you support. I would verify the full certificate chain, subject alternative names, expiration, signature algorithm, and protocol settings rather than relying on a browser alone.
Reply to this answer
A missing intermediate certificate is a very common cause. Chrome may silently retrieve the intermediate through AIA or already have it cached, while older phones and command-line clients usually will not. Run `openssl s_client -connect host:443 -showcerts` and confirm the server is sending the complete chain. Also check whether the new chain ends at a root that older devices actually trust.
Reply to this answer
Put the change through a staging environment and your normal change process, then include compatibility testing against the oldest supported phone and any partner client. Besides the chain, check SANs, TLS versions, cipher support, and signature algorithms. A browser test only proves that one modern browser can build a successful connection.
Reply to this answer
I keep automated external checks on every public endpoint and run command-line TLS tests as part of the release checklist. The practical minimum is: inspect the served chain, test with OpenSSL or curl, scan from outside the network, and verify the result on an old supported client. If only Chrome was tested, Chrome's compatibility behavior may be hiding the production failure.
Reply to this answer
Add your answer
Answers are reviewed before publication.
NovaCrate61: This also explains why a Windows machine can look fine even when the deployment is incomplete: it may already have the intermediate or root cached locally. Test from a clean device or isolated client instead of assuming the desktop trust store represents everyone.