How to Check If Your Linux Server Uses an Affected DigiCert Certificate Chain

Part 3 of 6

A practical Linux guide to inspecting TLS certificate chains with OpenSSL before DigiCert trust changes cause browser errors.

Introduction

Once you know that browser trust changes are coming, the next question is obvious: how do you check whether your own server is affected?

The good news is that Linux gives you simple tools for this. One of the easiest ways is to inspect the live TLS chain with OpenSSL.

Basic OpenSSL check

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

This shows the certificate chain presented by the remote server.

Save and inspect each certificate

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{i++} {print > ("cert-" i ".pem")}'

for f in cert-*.pem; do
  echo "==== $f ===="
  openssl x509 -in "$f" -noout -subject -issuer -dates
done

This helps you review each certificate in the chain and see who issued it, who it belongs to, when it starts and ends, and whether the issuer looks like an old or current DigiCert hierarchy.

Also check your web server configuration

For Nginx, the certificate file usually needs to contain the leaf certificate followed by the required intermediate certificates in the correct order.

You should also ask yourself a few questions:

• Do we pin roots or intermediates anywhere?
• Do we use Java keystores or custom trust stores?
• Do we have containers, appliances, or internal services that assume a certain chain?

If you find that your server is still presenting an older path, the usual fix is to reissue or renew the certificate onto a supported hierarchy and then test the new chain before rolling it out.

Closing thoughts

A live certificate check takes only a few minutes, but it can save you from a very confusing browser outage later.

Read next: Are TLS Certificate Lifetimes Really Dropping to One Month? Here Is the Real Timeline

---