3 ms·
> Another thing is, let's say I use some other CA for my certs, and I don't want LetsEncrypt issuing any. I can't really stop them, can I? You absolutely can.
by pfg 9y ago
> Another thing is, let's say I use some other CA for my certs, and I don't want LetsEncrypt issuing any. I can't really stop them, can I?
You absolutely can. Let's Encrypt was one of the first CAs to support CAA (and, IIRC, they supported it when they first launched). CAA is a DNS record that lets you specify which CAs are permitted to issue certificates for your domain.
> And finally, say I wanted to use LetsEncrypt, but I wanted to manage the keys myself, and require only private key X could be used to sign Y, and manage it myself. They don't really let me set those requirements at the CA level - it's all on my own host + network security.
I'm not quite sure what you're saying here. Do you want the ability to issue certificates under your own (constrained) intermediate certificate? That's unfortunately not possible under the current Baseline Requirements unless you get audited as a CA.
If you just want to use your own private key, that's of course possible (in fact, there's no way for Let's Encrypt to generate a key for you). Or is it that you want to limit limit issuance for domain X to key Y? What other CA allows you to do that? And how would you prevent some other CA from issuing a certificate for a different key, even if Let's Encrypt would support such a feature? With that in mind, it becomes clear that in the end it's up to your host and network security again, even with such an agreement in place.
- peterwwillis 9y agoI wasn't aware of CAA, that's a nice development. > Do you want the ability to issue certificates under your own (constrained) intermediate certificate? Look at it this way: currently, if you can send network traffic from some IP space, you can create valid domain certs. This is the equivalent of using a hosts file with a list of IPs to authenticate an ssh connection. Yes, I think an intermediary key, and not simply some arbitrary control of a network, should be required to generate a cert. It seems like CAA, or some extension thereof, could help this become a reality.
- pfg 9y agoI'm not sure I understand your suggestion. How does the intermediary key improve the domain validation process? There's an CAA extension in the works that will allow you to bind domains to ACME accounts (which are protected by your account key). Let's Encrypt has plans to support it. Is that what you're looking for?
- peterwwillis 9y agoAn example: 1. Webserver requests cert for xyz.com. 1.1. Generates private key 1.2. Generates csr 1.2. Sends csr to ICA. 2. ICA requests cert for xyz.com. 2.1. ICA generates private key 2.2. Signs Webserver's csr with private key 2.3. Sends signed csr to CA 3. CA issues certificate 3.1. CA looks up CCA record for xyz.com 3.1.1. CCA contains ICA's key fingerprint 3.2. CA verifies signature of Webserver's csr with ICA's key fingerprint 3.3. CA verifies Webserver controls domain xyz.com. 3.4. CA issues cert At no time could a bad actor simply compromise the webserver and issue a new cert for xyz.com, because it would need the ICA to approve it (and that could require user intervention). Thus, network access alone would not be enough to generate certs. Maybe this is the extension they're making?