Hello,
Why does ACME use CSRs, rather than having the client submit the relevant details as part of the API?
It would seem a lot simpler—and just as useful?—to submit a public key and domain names directly.
Thank you!
Well, I don't know the details of the design (though maybe some of it was on public mailing lists that someone could dig up), but I can speculate. Presumably, the people working on the first clients found it simpler to use existing systems that used the CSR format when creating a key, and since it was an existing standard format it made sense to just use that rather than try to make their own competing public key certificate request format.
It also does allow for some level of "extensions" to the protocol, where one can request must_staple, and potentially more things in the future, in a similar way to how other CAs might want to accept those requests.
5 Likes
I remember it was to somewhat confirm client did have control of private key part of cert requested:
otherwise you can put about any public key over API:
like eve taking down any site by ask a cert A with same public key with target site - revoke A as key compromised as owner - server process to revoke all certs with same (insisted compromised) public key, bringing down target site
although LE patched to you need sign a cert with its private key , that was the reason to use csr - and CSR as there are embedded thing that through out CSR so LE can be used on them.
4 Likes
CSRs are signed by the private key, thus cryptographically proving you actually own/have the private key corresponding to the public key. It's just a common method among CAs I believe. Even though LE doesn't even use/extracts much info from the CSR other than some extensions ("must staple"). The hostnames are already communicated using the order object, so no CSR required for that 
It's just a commonly used cryptographically sound method.
4 Likes
Does the CA somehow verify that the private that signs the CSR is the “right” one? Without that, nothing seems gained other than (maybe?) verifying that the public key derived from a “real”, functional private.
I get that, in crypto/security-related stuff it’s generally better, absent disqualifiers, to follow established patterns. I’m just wondering if there is a more “functional” reason for the CSR.
Yes, the CSR is "self-signed", so the CA can verify the signature using the public key from the CSR itself.
See the Boulder code at:
4 Likes
@Osiris All that does, though, is verify that the public key’s private is the one that signed the CSR. That doesn’t mean that that private is anything “special”, right?
Other than nobody else should have it or access to it if the owner of the private key is using good and proper security measures.
1 Like
What would be "special" about the private key anyway? It just proves the sender of the CSR also has controle over the corresponding private key, nothing less, nothing more.
3 Likes
That was my thought too: the CSR’s inclusion of a signature only proves to the CA that some private key out there matches the submitted public key, which isn’t useful information. Thus, it seems ACME could, in theory, forgo CSRs in favour of a simpler client workflow.
It’s probably not worth actually implementing that alternate workflow anymore given how much ecosystem exists around status quo, of course.
2 Likes
Yes. Possession of the private key is not required by any of the SSL technical specs or the CA/B forum. It pulls a lot of weight serving as a failsafe in most workflows.
Beyond that, I think there is a robust ecosystem of Hardware Security Modules that support signing a CSR. I'm not sure if ISRG is utilizing one, but I wouldn't be surprised if that was a factor in deployment decisions.
I also believe it was @petercooperjr who found an alternative flow like this implemented a few months ago. IIRC, it was either digicert or sectigo who were testing a commercial service that would re-issue an existing certificate on their network once it was near expiry.
3 Likes
Not directly, but there are some requirements in the BR regarding the private key in 6.1.1.3. However, I think most of them are determined using the public key. And thus proof of the corresponding private key might indirectly be "necessary".
Anyway, there's absolutely no reason to sign a CSR for which a private key does not exist. So if I were to be a CA, I'd most certainly would like to have some proof of existance of the corresponding private key.
3 Likes
That's a good point, though I suspect that Boulder doesn't send the CSR from the user directly for signing, but if they do use CSRs for their HSMs they create their own based on the public key.
I think you're thinking of this thread on Mozilla's policy list, which is an interesting read (to me at least), and yes I've linked to it before but I'm not personally involved with it or its discovery.
3 Likes
They don't as stated a few times on the forum already: signing user CSRs directly is one of the biggest reasons of certificate mis-issuance.
How they would generate a CSR for their HSM without the corresponding private key: I dunno. One could probably look at the Boulder code to see that tho.
3 Likes
Again, possession or control of the Private Key is not required for a CA to issue a SSL Certificate. The BR requirements for a subscriber's Private Key are essentially limited to knowledge of (i) the key being compromised or (ii) the key being likely to be compromised. There are some additional restrictions on Public Key sizes and validation.
The BR requires:
- proof of control over the domain
- technical requirements on the public key
- security measures around the private key
A CA can, and several have, issue certificates without utilizing a CSR or Private Key. Subscribers and CAs do not have to prove control over a Private Key, they must simply attest the key's security complies with the BR.
Reference the discussion starting here (it was @petercooperjr):
I'm not sure if they do or not, but ISRG staff noted that most HSMs support signing a CSR. I know I'm making some assumptions here, but IMHO the knowledge HSMs being capable of this would likely have influenced design decisions to potentially support that in the future (if not initially).
Yes. I eventually found your post and linked to it above. You were the person who discovered that discussion and shared it with this community, and I wanted to credit you for that.
3 Likes
Thanks. There is also some talk in that thread about the original discussion here, from one of the original Certbot engineers that they considered not using CSRs but ended up going with it:
4 Likes
Yes, CSRs are signed by the private key which corresponds to the public key embedded in the CSR (and which will then be embedded in the final certificate as well).
Yes, Let's Encrypt verifies that the signature on the CSR is valid.
But, this does not prove that the client/applicant controls that private key. CSRs do not have any time-sensitive data in them, particularly not a random value supplied by the CA. Therefore, you can just download a CSR that's sitting around in someone's GitHub repo and submit it to a CA. The signature on that CSR will still be valid, even though you don't control the private key and didn't create that signature yourself.
Anyway, at the end of the day, the reason ACME uses a CSR is twofold:
- CSRs are a well-established format for transporting a public key and a list of domain names.
- The Baseline Requirements say that CAs MUST obtain a "certificate request" from the applicant; the ACME authors conservatively interpreted this as "must obtain a CSR" to be on the safe side.
12 Likes
I also said in the other thread something that's sort of a variant of your reason #1: I thought I recalled some of our colleagues (probably on the Mozilla side) hearing from prospective users who had embedded devices that were hard-coded to generate X.509 CSRs, and would apparently not be willing or able to import private keys that weren't generated on the devices (but where those devices themselves wouldn't be able to run ACME clients).
One could also argue that generating the key on the device where it will be used is the most secure option (though manifestly not the most automation-friendly option if the device can't speak ACME). By generating the key where it will be used, fewer devices, storage media, and file transfer methods are required to be trusted with access to private keys.
So it can also be seen as a backwards-compatibility measure for various devices that do use TLS but that are hard to update, can't run much software, aren't directly connected to the Internet, and so on.
9 Likes
You mean, any smartcard or HSM-generated private key?
That's smart, actually.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.