2 ms·
I 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
by peterwwillis 9y ago
I 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?