Hi,
I just renewed my LE cert and imported it into cert storage. Now I can see both of LE certs in EMC, the old one, valid until June 11th, and the new one, valid until September. For the old one EMC reports “valid”, but for the new it says “Certificate revocation check failed”.
There is no proxy in our company and downloading the CRL file directly from servers IE works. What could be the problem?
Thanks and regards,
Stefano
Is it possible for you to say the names secured by these certificates? That could make it easier to investigate.
https://certificate.revocationcheck.com/ is an online service that can show you what a third party sees, so that could be helpful even if you can’t tell us the affected name.
I doubt you’ve done this, but one easy way to get a revocation failure (or indeed any date-time based check failure) is to have the date set incorrectly, e.g. wrong time zone. So please do check that, especially if the revocationcheck web site says it’s fine but your server still says it isn’t.
It is possible to do the revocation check steps by hand, to try to diagnose what exactly goes wrong that way, but I don’t know the best way to go about that in Windows, so let’s come back to that only if the other ideas don’t help.
Is it possible for you to say the names secured by these certificates?
Thanks a lot for your input, tialaramex. Unfortunately this is a company mail system, so I cannot publish the respective domains. What might be of interest for further investigation is that I used the "ACMESharp" environment to create the primary certificates three month ago and to renew them now. When running the respective ACME powershell commands for renewing a certificate I don't get any error message from LE, all seems fine. But, as said before, the renewed certificate does not get checked against CRL (I see this message in EMC).
The Exchange Server has access to the internet via Ports 80 and 443, which should be enough for downloading the CRL.
I tried https://certificate.revocationcheck.com. But I'm not to deep into certs theme and I only know what to do with the first of the three tests (it does not report any failure).
May be I should try to create a new certificate instead of renewing it (it's a SAN certificate)?
Thanks in advance if there is any other idea.
Regards,
Stefano
By “the first of the three tests” I guess you mean the tab TLS/SSL connection on that site? That would work so long as it can get the affected certificate from a web server. For example maybe a webmail / OWA server that uses the certificate you’re concerned about. If you need to test a certificate that’s not on a web server (or not on a web server reachable from the public Internet) you want the second tab, “Certificate Upload” and just need to make a copy of the certificate (not any other data, just the certificate) in PEM format, which is some text starting ---- BEGIN CERTIFICATE ---- and paste it right in the first box of the second tab. All the optional stuff can be left blank and push “Check Revocation Status”.
Microsoft’s documentation suggests you may be able to tell your server to use this certificate even though it hasn’t been able to re-assure itself of the revocation status. If you want to, and particularly if you’re happy that the status isn’t really “revoked” you could use this step to at least buy more time to figure out why it isn’t able to verify for itself.
https://technet.microsoft.com/en-us/library/aa997231(v=exchg.141).aspx
It can’t hurt to make a new certificate, but it’s unlikely to make a real difference.
I notice that Microsoft’s documentation talks only about CRLs, revocation lists which cover every revocation for a particular CA. But Let’s Encrypt doesn’t use CRLs at all for its “leaf” certificates, it issues many millions of certificates, and if even 0.1% were revoked that would be many thousands of revocations on the CRL. So to implement revocation for Let’s Encrypt leaf certificates they use only OCSP the Online Certificate Status Protocol. That might perhaps be relevant somehow, but I can’t see how this would mean your old certificate was OK, but the new one fails the check. Puzzling.
One final Microsoft-specific idea is that your two certificates (the one about to expire and the new one) might have different Intermediates (see the “issuer” section of the certificate itself). We know the Windows system can get confused about the difference between two intermediate certificates named Let’s Encrypt Authority X1 and Let’s Encrypt Authority X3 and that’s caused some people with Windows web servers pain. Since I haven’t seen the certificates you’ve got this problem with I can’t be sure if that’s relevant, but if you inspect the certificates themselves, preferably from a non-Windows PC, you may be able to see if the old one was issued by X1 (the new one will definitely be from X3).
Hi guys, I just fixed this issue on our Exchange cluster and wanted to give you the answer.
You need to import these 6 certificates (https://letsencrypt.org/certificates/ – download the .der version) onto your Exchange servers. Import them for Local Computer, and let them automatically select the certificate store (they’ll go to Intermediate Certificate Authorities->Certificates).
Then go into ECP again and refresh the certificates tab and the certificates will no longer say “Revocation check failed”
I hope this helps somebody! I couldn’t figure out why one of our servers was fine but the other two weren’t until I started digging around and discovered that I forgot to import those on the tertiary servers 
In my case problem is solved. Unfortunately I’m not sure why. What I did was to delete local certificate and intermediate certificate again via certificate snap in and to create a complete new certificate with Let’s Encrypt (I reduced th number of SANs by omitting the server name and that probably forced LE not to reissue the old cert but to create a new one). I retrieved and installed the new certificate with certicate snap in by explicetly chosing “Own Certifcates” as storage. I was not asked where to store the intermediat certificate, it was stored into the right storage automatically. Next day I realized that my LE-certificate was shown as “valid” in EMC.
Not sure whether LE or MS changed something or whether creating a new certificate with different SAN did the trick.
Thanks to tialaramex.
Regards,
Stefano.
Little off subject but tdelmas.eu revocation status reports a warning:
Expires cache header is not the same as the NextUpdate field (RFC 5019 section 6.2)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.