Validation - Existing Certificates


#1

So this is part 1, I have an upcoming part 2 which will be related to EV certificates and a further part 3 related to other forms of communication but wanted to get this base request discussed first and then build upon that.

My proposal / request is for existing certificates to be usable during the domain validation portion. Essentially by providing proof of possession of another valid certificate (Either by this CA or another) for the domain / subdomains in question (Note: Not sending the private key !) I believe it should be possible to get a new certificate produced. The only additional constraint over existing validation methods is that this new certificate should be valid for no-longer than the existing certificate is.

This is useful in a few scenarios:

  1. I have an example.com (90 days) certificate and want to add or update various sub domians without using the normal verification methods.

  2. I have an example.com (3 year) certificate which is never used by the web servers directly but want to create new leaf certificates with a short expiry (90 days) for key rotation purposes. (Or the normal verification methods are not suitable for my setup and therefore want to do this portion with a longer certificate.)

  3. I have servers behind a load balancer (Heroku ?), therefore the normal verification methods are unsuitable and I need to perform the verification step on an external server or out of band.

4) Part 2 will include a proposal / request to perform OV using the same method with no additional cost to LE.

5) Part 3 will include a proposal / request to perform OV using part 2, but for certificates covering additional forms of communication. (I understand that there may need to be a change of the LE ToS for this, but that will be discussed in a future thread)

There is an additional security consideration which is what happens if the existing certificate is revoked, or the other CA closes down and is no-longer trusted. I believe that certificates should have an additional (Optional) field which contains the hash of public key of the existing certificate and a signature of the new public key signed using the existing certificate - If this additional field is present, the browser will also check the chain of the existing certificate which implies that this chain needs to also be included.

Thoughts / ideas / comments ?


#2

Point 2: Some commercial certificate vendors offer a managed certificate solution much like what you’re talking about. I know Symantec does, one of my past clients used such a thing from them. This generally requires more infrastructure than Let’s Encrypt currently manages.

Point 3: This may be mitigated when DNS-based verification is implemented. Normally if there is load balancing, the back-end servers can sync files (and therefore the challenge contents) or the LB may be able to offer content at the created well-known endpoint location, but DNS verification would take that out of the picture.

Point 4: This will be interesting to see as OV generally requires positive contact with the requester.

What you are describing sounds a lot like HTTP Public Key Pinning combined with having a backup certificate.