It produced this output:
SEC_ERROR_REVOKED_CERTIFICATE
My web server is (include version):
apache 2.4
The operating system my web server runs on is (include version):
debian 13
My hosting provider, if applicable, is:
me
So, the actual problem: This is the third time a LetsEncrypt Certificate issued with CertBot has been revoked a few days after creation. After a little investigation, I found out that this specific certificate is listed in the current CRL list, which can be obtained from http://e8.c.lencr.org/37.crl. The entry in this CRL reads as follows:
Serial Number: 0618AC94D5F0233BFF29B496220187A218A4
Revocation Date: Mar 7 23:03:59 2026 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Cessation Of Operation
I'm pretty sure that a) the business did NOT cessate operation, and that b) no person in this company issued something to revoke this certificate.
So the question is - why is the certificate flagged, how do we find out how this happened and what can we do to prevent this in the future?
Revoking a certificate requires similar permissions to getting a certificate. Could you tell us which ACME client you are using and what version so that we can look for reasons it might revoke a certificate.
Also, are you manually renewing certificates as the CT logs look irregular for your domains?
If the revocation request is from a Subscriber account which did not order the certificate in question, but has demonstrated control over all identifiers in the certificate, Let’s Encrypt may ignore the revocation reason in the request and set the reason to “cessationOfOperation”.
So I suspect that there is, in fact, someone or some automated system in your company (or who otherwise has access to the domain) which is specifically revoking the certificate. I don't think any of us here would be able to give you more details than that.
You will need to ask the company itself about that.
Certbot is not the only way to get a cert. Some ACME Clients may revoke a cert when it gets issued a new one. Right now that domain is using a valid cert issued on Mar 2 Sorry, just noticed the tool below does not check CRL. Still, you need to ask the company about that.
Yeah, I noticed that too late and updated my post. It is odd as there were two certs issued on Mar2. One is revoked and the other is not (this one: crt.sh | 24732876267 ). Yet, the company server is using the revoked cert. Looks like their ACME Client is not working well.
Let's Encrypt obviously does revoke certificates if mandated, but I don't think "Cessation Of Operation" would ever be a revocation reason used by Let's Encrypt if they revoke the certificate themselves. This, IMO, would only be done if Let's Encrypt gets this specific ACME revocation request with that specific revocation reason by the ACME client.
We run certbot 4.0.0 on the system, which is run by ISPConfig Version: 3.3.1
It's a virtual machine for one of our customers, and there are two people including myself who have access to this system, and my colleague is on vacation... so I'm pretty sure that no one accidentally or intentionally revoked the certificate.
Hello all...
just for the records: Problem has been identified and fixed.
The cause: We have a mixed configuration on that specific server, partially built by ispconfig software and manual additions. The server in question is manually added while a server config in ispconfig was still present, but disabled.
ispconfig has a configuration option called "Revoke a certificate before deleting it (prevents Let's Encrypt renewal warnings)';" which has been triggered for some reason we don't yet know, but it was indeed ispconfig's internal certbot process that actively sent a revocation before removing the corresponding certificate.
Thanks for all the pointers, they helped me look in the right direction and finally managed to find the reason for this
Even leaving aside that LE doesn't send renewal warnings any more (so there's no reason for it any more), this really seems like a silly option. In the best case, it prevents three warning emails that might be a little confusing; in the worst case it does nonsense like we see here.