Fix for an Expired Intermediate SSL Certificate Chain

June 2020 Update: With a large number of sites affected by the recent expiring of a root certificate, we thought it would be valuable to again share this guide on intermediate TLS/SSL certificates in the certificate chain. Note that intermediate certificates rely on root certificates. For more information on root certificates, read The Impacts of Root Certificate Expiration.

Orignal 2014 Content

On July 26, 2014 at 12:15 PM, some customers and users on sites secured by DigiCert reported that they were getting an untrusted certificate error.

The problem is related to a locally installed legacy intermediate certificate that is no longer used and no longer required for the certificate installation. The problem can affect any client platform with a locally cached or installed intermediate certificate.

So far we’ve seen the issue happen with:

  • Clients (mainly OS X) with the expired intermediate installed in their local keychain.
  • Server-to-server connections on Windows environments, where one server still has the legacy certificate installed.

Expired Legacy Intermediate Certificate

The expired certificate in question is the “DigiCert High Assurance EV Root CA” [Expiration July 26, 2014] certificate. This temporary intermediate certificate was used in years past as part of a compatibility chain for older devices.

This certificate has not been used for over three years and is unnecessary for installations.

From additional information, users affected appear to have the expired intermediate in the ‘login’ keychain or stored locally on their server or in have the expired intermediate installed on a backend server or application.

Fixing the expired intermediate certificate on Mac OS X

The errors on Mac OS X are due to a locally installed intermediate certificate in the login keychain.

OS X users can resolve the issue by deleting the certificate from their Login keystore using Keychain Access.

In Keychain Access go to View -> Show Expired Certs and search for ‘DigiCert High” to find the DigiCert High Assurance EV Root CA that expired on July 26, 2014. Delete this certificate and close Keychain Access.

(Credit to Allen Hancock @yesthatallen for the solution in picture form and others who jumped in with responses)


Repair Intermediate Certificate on Windows, Exchange, ISA, TMG, Lync

Administrators running Windows/Exchange with an ISA server or TMG can run the DigiCert SSL Installation Diagnostics Tool.

Affected servers will produce the warning, “Your server is not sending the right intermediate certificates.” On Windows servers, this can be resolved using the DigiCert Utility.

When the Utility runs on your server, a warning may appear. Click “Action Required” and “OK” to delete the expired intermediate and enable the correct certificate chain. The server will most likely need to reboot for the change to take effect.

If you are unable to run the utility, you can manually delete the DigiCert High Assurance EV Root CA certificate expiring on July 26, 2014 to resolve this issue. You do not need to reissue your certificate.

Fixing the expired intermediate certificate on Apache

Administrators on Apache, can replace the SSLCertificateChainFile with the correct DigiCertCA.crt provided with the certificate received from DigiCert, which may downloads from your DigiCert account under your order details.

No action required for most certificate installations

All current installations of certificates issued by DigiCert include the most up-to-date intermediates in order to establish trust with browsers.

But administrators who received the notifications from DigiCert should remove the expired legacy intermediate from their server to avoid any potential conflicts.

If you have details on other affected platforms, please contact support so we can get additional details and update our documentation for other users to resolve the cached intermediate error.

If you need assistance with this or any other issues, our support team is always happy to help.

Posted in Announcements, SSL

26 thoughts on “Fix for an Expired Intermediate SSL Certificate Chain

  1. This might be helpful to some of your customers too. We have had the same issue, not with mac devices but with our Citrix Access Gateways and F5 load balancers which rely on a cached certificate chain. Simply upload the new CA bundle and activate it on your SSL profiles, job done.

    1. Thanks for the feedback. Yes, most devices should automatically switch over to use the latest DigiCert root since the expired root hasn’t even been included in any installation over the last three years. But we’ve seen that if the root exists, then some devices still try to use it.

      Also any client that has a locally cached version of the certificate will need to remove it. We’re hearing about a few other platforms out there that also require removing the expired intermediate.

      Glad that worked for you.

      1. No worries, I thought I’d post since this is caused a major outage in our business yesterday. Our cert was a wildcard issued 4 years ago so anybody with a cert issued in 2010-2011 will have the same problem. Internet browsers handle that without problems, it’s a different story for devices like access gateways and load balancers though…


      2. Flavio would you be able to explain how the automatic switch you discribe above is meant to work because we have a lot of windows 7 desktop pc’s that are having this problem and I would like to work out why its not automatically switching.

  2. We have Exchange and ISA server (all running on Windows) and have just been affected by this. It brought down all Outlook Web Access and ActiveSync for 500 users. Not pleased. Took me a morning to find the fix… and then saw it posted here.

    1. Apologies for the frustration this has caused. I do appreciate the info, I’ve updated the instructions on the post and also have sent a note to our support reps so that any other users experiencing the same thing can quickly resolve it.

    1. Thanks Jeff. I’ve updated the instructions here with a screenshot of the utility and specifically mentioned the issue for Lync too. Your post is very thorough.

  3. Would be glad if certificate vendors (like Digicert) issued heads-up emails at least a couple of months before such expiration dates to all their customers:

    “Dear Mr. Customer, some of our certs will expire in the coming months, please make sure those are not used in your infrastructure.
    -List follows with human readable certificate names, serial number and thumbprint
    -Steps how to get rid of those expired certificates”

    As far as I understand, this wasnt an unexpected event out of the blue, could have prepared for this better, so other customers in this comment list wouldnt have faced business-affecting downtime. Especially if their end-entity certificate was still valid, and only one of those intermediate certs expired. Windows doesnt warn about expiration of issuer certificates, only about the end-entity one. So would be the duty of the vendor to alert customers. Especially if those intermediate issuer certs were not even in the chain for the end-entity certificate so couldnt trigger the internal alarm clock of the IT staff (if I am not misunderstanding the scenario here).

    By the way, let me recommend something you Flavio, if you agree:
    implement a Lync system (including the Lync Edge server) for guinea pig reasons. Lync is the perfect candidate for any certificate or PKI-related issues, it depends on certificates really heavily. If an event like the current one does not have any influence on that Lync system, I may quite confidently say it wont affect your customers out in the wild seriously.

  4. We’ve seen API integration clients running on Windows Server 2003 (calling our Linux based services) and under Java impacted by this as they have the expired root CA cached (Windows) or installed locally (Java trustStore). Rebooting the Windows machine where the API client resides cleared the SSL cache and resolved the problem. Haven’t been able to resolve where its lingering for the Java API client.

  5. For Apache reverse proxy for Exchange OWA, we needed to (also) reinstall the actual certificate. We replaced the DigiCertCA cert as well, but that did not solve the problem, checked viaDigicert Cerificate checker

  6. I’ve deleted the cert on OSX’s keychain and now main sites loads but static pages doesn’t. Now it mentions another cert: “DigiCert SHA2 Extended Validation Server CA”, with the error message: “This certificate was signed by an unknown authority”. Tried looking for this cert in my keychain but it doesn’t appears.
    Is this issue related?

  7. We’ve updated the certificate used for the site and it should chain to a different root that should not be involved in the expiration issue.

    You should now be able to access the post without running into the error.

  8. Hi.. I have a same issue today, I have two TMG array configured. the old Intermediate cert only show at TMG02, in TMG01 there no old intermediate CA. how come this issue happend after 5 month ? thanks 🙂

  9. I’m having the same issue with one of my Git repositories. When I try to push it to a fresh BitBucket remote repository I get the error on my terminal: “fatal: unable to access ‘…’: SSL certificate problem: Invalid certificate chain”. Unfortunately, I don’t have the expired certificate in my keychain. I do only have a valid one expiring 2031. Any other idea what might cause this behaviour? Thanks!

    1. Hi flohei,

      I talked with our support team and they recommended that you call in. They weren’t able to troubleshoot the problem with the information you provided. Call us 24/7 at 1.801.701.9600 or chat with them on

  10. I hope someone is still reading this but I’m getting an ssl cerificate problem but the issue I am getting is that it’s getting another certificate from another site for some reason, got any ideas?

Comments are closed.