3 ms·
I see how what I said may have been confusing, but I meant that the ACME server does not generate a certificate for each user. They have their own cert for vali
by bisby 10y ago
I see how what I said may have been confusing, but I meant that the ACME server does not generate a certificate for each user.
They have their own cert for validating their service (not generated per user). And the user/client generates the certificate. The server isn't (necessarily?) generating the keys, the client is.
- tialaramex 10y agoThe ACME server absolutely does generate the end entity certificates for their subscribers (e.g. a certificate on your web server). Code which does this is part of Boulder, the Let's Encrypt implementation of an ACME server so you can go see for yourself (obviously their production system config is not on display but it's the same code) You are correct that Let's Encrypt don't generate the subscriber's key pair. This is (or should be) true for every public CA offering Web PKI certificates today. The subscriber puts their public key in a Certificate Signing Request, and signs it with the corresponding private key. Let's Encrypt receives the CSR, verifies that it is correctly signed, establishes that the requesting Let's Encrypt user account is authorised for all the DNS names listed in the CSR, and other parameters are acceptable, then it creates a signed certificate for those names, with the public key from the CSR. [Edited to add: If you use Certbot or similar to just issue a certificate all the CSR creation and signing is done for you. But it still happens, and Let's Encrypt are still the ones actually making and signing the certificate] It is essential that Let's Encrypt create the certificate. Under the current Baseline Requirements they're obliged to ensure that the serial number is unpredictable yet unique across all their issued certificates. The only practical way to achieve these goals is for them to create the certificate from scratch and sign it. The situation where a tbsCertificate (the certificate document before it is signed) is transmitted anywhere is unusual. The only example I can think of recently was where Symantec were arranging SHA-1 exception certificates and Google's process deliberately involved showing everybody the tbsCertificate before it was signed so that we (the community) could examine it and ask for anything unusual to be explained. If you go back and look at those discussions you'll see it was me who first asked for the weird OU value in certificates for TSYS to be explained or removed -- they were subsequently removed before the certificates were issued.
- bisby 10y agoThanks, Thats good to know. I was operating under the assumption that the key pair associated with the cert and the cert were essentially the same.