According to section 7.6 of RFC 8555 RFC 8555 - Automatic Certificate Management Environment (ACME), "an account that holds authorizations for all of the identifiers in the certificate" can revoke this certificate.
Could the same be applied to certificate downloading ?
When I tried to download a certificate using an account other than the issuing account, despite it has valid authz on the domain, I got "Account in use did not issue specified certificate".
Why a third party account can revoke a cert but is not able to download it ? And how it retrieves the cert value in order to issue the revoke request if it can not download it ?
I'm not quite following your question; how would a different client than the one the issuing account has used end up having the URL for the certificate from the order object? Are you thinking of one client getting the certificate URL, and then passing that URL to some other client with a different account?
(I may just be missing things; many other people have much more familiarity with the spec than I do.)
Certificates are publicly available, either from the website serving the certificate or due to the fact they're logged by Certificate Transparancy Logs (e.g. you can search and download them from sites like https://crt.sh/). But not from the ACME API.
Why would you want to download a certificate using the ACME service to begin with? Being able to revoke a certificate does make sense, as it's not always the same user issuing and revoking a certificate e.g. after a DNS handover. If the hostname(s) are transfered to a different owner, you'd want to revoke any previously issued certificates owned by anyone else. But for downloading a certificate using ACME, there's no good usage to think of IMO.
No, I'm as puzzled as you are.
If you hold authorizations, you can issue a new certificate, up to rate limits, but you can't request the certificate from another account. I don't think we intend to change this, and don't think it would be spec-compliant.
Another account can revoke a certificate if it holds authorizations for the names because that's required by the CA/Browser and root programs, effectively.
I then should not got "Account in use did not issue specified certificate"
I did not say publicly available using the ACME API. I meant either from the server serving the cert itself or Certificate Transparancy Logs. I'll edit that latter part additionally in my post.
I'm still interested in the use case you want to use this for.
The third party account can only revoke a certificate after demonstrating they are now in control of all domains in the Certificate. This is basically only used as a failsafe in case someone has a compromised server. It can also be used if there is a change of ownership in domains, but the utility is minimal as ALL domains in the certificate must be authorized to the third party so it can't be done if any other domains on the cert are not transferred to the new owner.
There has never been a need for an account to use the ACME API to find certificates for a domain issued to other entities, as that can be handled with public Certificate Transparency Logs.
You are best off to use CT logs to find these certificates, as they cover submissions from multiple CAs. If there were an ACME feature to list competing certificates for a domain, it could inherently only show certificates issued by that ACME server. If there is any concern or worry, CT logs should be monitored and referenced – not a single ACME server like LetsEncrypt.
The Certificate is also essentially worthless without the PrivateKey. The only thing that can be done with the Certificate without the PrivateKey, is a revocation after a new authorization.
The third party account can obtain the certificate from the website or certificate transparency logs.
Small side-note about CT logs: while Let's Encrypt does submit the final certificate to CT logs and not just the pre-certificate, not all CAs submit the final certificate unfortunately.
And there is always the case of "having the private key".
[not very likely in almost all circumstances, but worth the mention]
All of Let's Encrypt's certificate download URLs are publicly available via unauthenticated GET. For example, this link will download the current certificate for https://www.letsencrypt.org (among other hostnames) directly from the ACME API. This is because certificate contents are inherently public (e.g. they can be downloaded from CT logs). This only works for unexpired certificates; we serve 404s for older certs.
So yes, if you hand the certificate url from an Order object off to a different process, a simple GET should suffice to download the certificate and its issuance chain.
While that's Let's Encrypt's current implementation (and I'm sure it's pretty unlikely to be changed by them), I think that a client wanting to comply with the RFC 8555 spec (as may be implemented by other CAs) should only count on being able to send a POST-as-GET signed by the account which made the order.
So it should be possible also with POST-as-GET using any account.
My certificate is still downloadable after revoking it yesterday
By the way, what happens when a corresponding authorization expires, even if it was valid in the past? Is the third party account still considered to own the domain?
No. The account would need to perform another challenge to prove they are authorized for the domain.
Valid authorizations are currently cached for up to 30 days, but this is expected to change to as little as 7 hours.
Expired and revoked are very different things. We only 404 expired certs, not revoked ones (until they expire as well).
Is there a reason to not 404 revoked certs ?
Except in the case when the cert can be unrevoked (reason code certificateHold), the cert is no longer usable, as if it had expired
Is there a good enough reason to return 404 on revoked certs that have not expired yet? Implementing this increases complexity, so there needs to be a good reason for this.
It is no longer usable as a Publicly Trusted Certificate, but the Certificate and Order are still usable to the Subcriber for internal auditing and forensics.
CRL is also quite complex. Due to OCSP stapling and browser behaviors, a revoked certificate could still be valid to browsers for up to 10 days.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.