Certificate Changes in 2026: My Full Linux Admin Blog Series

A complete series covering TLS basics, DigiCert trust changes, certificate lifetime reductions, and automation for Linux users.

Introduction

Over the past few posts, I have covered the basics of TLS certificates, the DigiCert trust-chain changes affecting older hierarchies, the real certificate validity timeline, and practical automation steps for Linux admins.

Full series

1. TLS Certificates Explained Simply: A Beginner-Friendly Guide for Linux Users
2. Why Mozilla and Chrome Are Distrusting Some Older DigiCert Certificate Chains
3. How to Check If Your Linux Server Uses an Affected DigiCert Certificate Chain
4. Are TLS Certificate Lifetimes Really Dropping to One Month? Here Is the Real Timeline
5. How to Automate TLS Certificate Renewals on Linux Before Short Lifetimes Become a Problem
6. My 2026 Certificate Checklist for Linux Admins and Website Owners

This is a good time for admins to review their live certificate chains, move away from affected old trust paths, and make renewal automation part of normal operations.

My 2026 Certificate Checklist for Linux Admins and Website Owners

Part 6 of 6

A practical 2026 checklist for TLS certificate trust changes, DigiCert chain updates, automation, and monitoring.

Introduction

If you do not want all the background detail and only want the practical action plan, this is the post to save.

2026 is important for two reasons: some older DigiCert trust paths are losing browser trust, and certificate lifetimes are on a path toward becoming much shorter.

The checklist

Start by listing every public HTTPS service you manage. That includes websites, blogs, reverse proxies, APIs, dashboards, VPN portals, and mail-related TLS endpoints.

Next, inspect the live certificate chain for each service. Do not assume that a non-expired certificate means everything is fine.

Then check whether any system still depends on older DigiCert G1-rooted issuance before the April 15, 2026 distrust deadline. Also review whether any affected intermediate or cross-signed certificate components need action before the published May 15, 2026 revocation event.

After that, look for custom trust logic in your environment:

• pinned roots
• pinned intermediates
• bundled CA stores
• Java keystores
• container images
• mobile apps
• internal software that assumes a specific trust chain

Then move to renewal automation. If you still renew manually, start testing ACME-based renewal now.

Finally, add monitoring. At a minimum, monitor for:

• upcoming expiry
• failed renewals
• unexpected chain changes
• missing intermediates
• service reload failures after renewal

Closing thoughts

Certificates used to be something many admins could ignore until close to expiry. That is no longer a good strategy.

The safer approach now is clear: understand the chain, update old trust paths, automate renewal, and monitor the process properly.

Series complete.

---

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

---

Why Mozilla and Chrome Are Distrusting Some Older DigiCert Certificate Chains

Part 2 of 6

Older DigiCert certificate chains are losing browser trust in 2026. Here is what is changing, who is affected, and why it matters.

Introduction

You may have heard people saying that Mozilla is no longer trusting old DigiCert certificates. That statement is directionally true, but it needs more detail.

The issue is not that DigiCert as a whole is being distrusted. The real issue is that some older DigiCert G1 root hierarchies are reaching the point where browsers will no longer trust affected TLS chains.

What is changing?

According to DigiCert, Chrome and Mozilla Firefox will stop trusting active TLS end-entity certificates chaining to certain older DigiCert G1 roots on April 15, 2026.

The affected older roots include:

• DigiCert Assured ID Root CA
• DigiCert Global Root CA
• DigiCert High Assurance EV Root CA

This matters because a certificate can still look perfectly fine from an expiry-date point of view and still fail in modern browsers if the trust chain behind it is no longer accepted.

Who is most likely to be affected?

DigiCert moved default public TLS issuance to newer hierarchies in March 2023, so many customers may already be fine. The environments most likely to need attention are the ones that still use older issuance paths, pin specific intermediates or roots, maintain private or custom trust stores, or hard-code trust assumptions into software, appliances, or containers.

There is also another important date. DigiCert has published revocation plans for several G2 and G3 intermediates, plus two G5 cross-signed roots, for May 15, 2026. If a system still depends on one of those components, certificate validation can fail even if the leaf certificate itself is still within date.

What this really means

Do not only check whether your certificate is expired. Check whether the full chain behind it is still trusted.

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

---