Proposal: Easier way to renew certificates


#1

I would like to propose an easier way to renew certificates, that I believe would be sufficiently secure. In short: couldn’t certificates be renewed (in certain common cases) without redoing HTTP or DNS validation?

Why

Setting up automatic renewal for certificates is a bit of a chore that may get complicated, because you need to interface certbot with your HTTP or DNS server so that it can automatically update a piece of text. With the method I propose, certbot could be completely independent, a “fire and forget” solution just producing new certificates when needed. Then you wouldn’t need to add certbot-specific configuration to your webserver at all, or to interface certbot with your DNS server or cloud DNS service.

How

When requesting a brand new certificate, the user could get the validation challenge from certbot, and manually copy-paste it into a static file on the web server or into a DNS record. This is already possible, but annoying to have to repeat every couple of months for renewals.

When requesting a renewal of an existing LE certificate, the LE server could issue it if the following conditions are true:

  1. The previous (latest) LE certificate issued for that domain hasn’t expired.
  2. The renewal request is signed with the private key of that previous certificate, thus proving that the client is in possession of the certificate.
  3. The API key of the client is the same that was used to get the previous certificate.
  4. The validation token on the web server or in DNS is still the same as last time.
  5. Possibly more conditions you can think of.

I’m under the impression that step 2 isn’t currently utilized in the renewal process, so maybe it would be enough to replace the full validation. Step 4 would make it easy for the new owner of a domain to prevent the old owner from renewing certificates for the domain.

Risks

It’s possible that I have missed something crucial, but please consider it. I think the only new attacker that this would be vulnerable to, is someone who has read access to the current certificate and certbot API keys, but no write access to the web server or DNS records. Even then, using the current certificate’s private key, they could already impersonate the site when they can MITM someone. As soon as they requested a renewed certificate for themselves, the domain’s real owner wouldn’t be able to renew normally any more. Certbot could even check this in its daily run and alert the owner.

Motivation

I have used HTTP validation on some websites, and while it’s not too complicated, I always have to “cheat off my previous work” to get the nginx configuration right. More annoyingly, we’re using DNS validation for a system at work that’s not accessible from the public internet, and we haven’t had time to automate that yet.

Also, when I was explaining to someone how to use Let’s Encrypt, I realised the process could be much easier if you just did a manual verification once for the first certificate, and wouldn’t have to trouble yourself after that. I’m sure that a large number of users could go on for years with just one initial manual validation - until they reinstall their server or do something else to upset the status quo.


#2

Hi @Rennex,

A very recent thread that’s relevant to this is

where we briefly discuss the industry rules related to DV certificates. In general, the procedure that you describe isn’t one that the existing rules permit for revalidation and so Let’s Encrypt currently wouldn’t be allowed to rely on it for that purpose.

As discussed in the other thread, there is an interpretation where Let’s Encrypt could avoid sending new challenges at all for some period of time as long as the substantive information contained in the certificate hasn’t changed. There are various reasons why we don’t want to do that; one of them is an attack described in a recent research paper where someone registers a domain name, gets a certificate, and then deliberately allows the domain to expire so that someone else will start using it. At that point, the attacker possesses a valid certificate for the new domain registrant’s domain and could perform MITM attacks against it.

I think the method that you described isn’t vulnerable to that particular attack because you’re effectively suggesting repeating the authorization step with the old data, which the attacker in the researchers’ scenario would not be able to do after letting the domain name expire. Still, repeating the authorization step with the old data isn’t permitted by our interpretation of the existing Baseline Requirements.

In order to allow this, we would need to seek a change to the Baseline Requirements rules, which is possible to do (you could also join the CA/Browser Forum yourself as an individual and propose the method on their mailing list, although it couldn’t be voted on until a CA or browser had formally introduced it as a ballot). But I also think that Let’s Encrypt is overall very committed to the idea of automated renewal and, for example, making a minor edit to the current language to explicitly allow your method might imply that the renewals-without-reauthorization could only be performed for 825 days, after which a revalidation would be required. Let’s Encrypt wouldn’t favor that situation because it would cause many people’s websites to break unexpectedly at that point. We’ve been looking for solutions where people who get Let’s Encrypt certificates can get the certificates renewed automatically without human intervention on the same machine as long as the machine continues operating.

So overall, I think Let’s Encrypt people would advocate for fixing the automated renewal process promptly at the outset, even if that requires more effort, rather than putting in place some kind of renewal that works for a while and then stops working later.

A nice example of what’s possible in terms of a more convenient experience is Caddy

https://caddyserver.com/

where the Let’s Encrypt certificate request is built in as a basic functionality of the web browser and doesn’t need to be configured by the user at all.


#3

Thanks for the quick reply! I wasn’t aware of industry rules placing these kinds of time limits on the authorization. I guess that pretty much kills the idea.

And I agree, easy-to-use tools remove the need for tricks like this. Caddy sure looks handy, but then switching to it from already familiar servers is also a chore. :slight_smile:


#4

This post was flagged by the community and is temporarily hidden.