Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I'm Ari, a Product Manager for Pantheon, a Let's Encrypt partner. I'm opening this thread on behalf of a customer.
Customer attempted DNS-01 challenge. TXT record looks like it's deployed successfully:
dig +short TXT _acme-challenge.dev-transform.reputation.com.
But we're seeing an error:
cannot verify challenge with authorization in "revoked" status
We're also seeing this issue for another one of their domains test-pantheon.reputation.com and no other customers are reporting issues.
We haven't seen this error before. Can you please advise?
Is this an error you are seeing in certbot or some custom software? Is the error being reported by the Let's Encrypt API?
Can you share the order URL (like this:
https://acme-v02.api.letsencrypt.org/acme/order/104744762/58610589240)? - that would allow review of the outstanding authorizations.
Which ACME client (and version) are they using?
Thanks for your reply. It's a custom integration. Ah, just checked our codebase and see that that error message is from our software, but looks like the Let's Encrypt API is returning the authorization status as "revoked." I'm not sure how to identify the order URL, but wanted to get this thread going, and sounds like one of our engineers may need to add more detail next week.
My wild guess is that if the authorization had included a domain name that was authorized with TLS-ALPN-01, then during their recent incident they needed to revoke the existing authorization. (Or maybe it got revoked somehow even without using TLS-ALPN-01?)
In any event, I'm guessing the main thing you'd need to do is just to no longer use that authorization but make a new one. But it'd be hard to describe you'd do that in your custom integration without more details. Probably it should automatically make a new one if it discovers that the authorization is revoked.
It doesn't appear LE revoked the certs. Checked both domains with LE's tool and it returned the following.
[dev-transform.reputation.com]: FQDN was not found in the impacted list.
[test-pantheon.reputation.com]: FQDN was not found in the impacted list.
Did you or your client receive an email from LE telling you/them the authorization was going to be revoked the TLS-ALPN-01 challenge was used?
It's possible the hostnames were validated using the
tls-alpn-01 challenge with that validation authorization cached and consequently revoked without even being used for issuing a certificate.
Your client should be able to use new authorizations without using the cached ones.
Certificate != authorization. I don't think LE send out mails for authorizations, just for certificates.
As per Questions about Renewing before TLS-ALPN-01 Revocations :
"On 26 January 2022, Let's Encrypt notified subscribers (with a valid contact email) that on 28 January 2022 we we will revoke certificates issued in the last 90 days and validated with the TLS-ALPN-01 challenge. "
Yes, but OP specifically has troubles with a revoked authorization:
So I'm unclear what anything in this thread has to do with a revoked certificate. Yes, OP might have a revoked certificate too, but I don't see how that is an issue here.
An authorization that was once
valid may be changed to
revoked. An authorization that is valid may have a certificate issued for it, but a revoked certificate implies a revoked authorization that would otherwise permit that certificate to be issued. RFC 8555 section 7.1.6:
So that authorization, even if it was not used to issue a certificate, would otherwise have been used to issue a certificate that needs to be revoked. So the client has to make a new order and get a new authorization.
And that's, I think, is exactly what's happening here. The client tries to re-use a revoked authorization from an older order. It should just request a new order I believe, with new authorizations.
That should have stated exact start and end dates.
"Last 90 days" is vague/subject to interpretation.
90 days from Jan 26? [this choice would revoke 2 days of recently expired certs]
90 days from Jan 28? [this choice would revoke 2 days of unaffected certs (Jan 27, Jan 28)]
I know: Completely irrelevant here
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.