Differences in policies regarding renewal process

[kzw]

I used to have automatic renewal process working when I relied on webserver challenge authentication process. What I meant is that I had a webserver configured so that renewal process on the webserver and letsencrypt server can communicate.

Recently I started using DNS challenge and the auto renewal process is not working anymore. I can get a new certificate issued after setting up required DNS records. I had originally assumed that once a required DNS record is set up and so long as I do not delete or modify the record, I do not need to make any further adjustment to DNS to renew the same certificate. This is also based on my experience with AWS issued certificate process where once a DNS challenge record is set up subsequent renewal requires no human intervention.

Please correct me if I am mistaken that renewal to certificates issued by DNS challenge record requires an update to the existing already working DNS record.

If this is the case, I believe it is less secure than relying on a fixed DNS record.

1. It forces the administrator to deploy DNS related credentials to the machine running renewal. Without this requirement to update DNS record upon renewal, admin can deploy DNS record the first time using semi manual process (eg. code reviewed terraform changes) and all subsequent renewal require no human intervention. In a modern devops organization, DNS records are controlled by infrastructure as code and code changes are subject to human reviewers. It is not trivial nor practical to automate human code review process.
2. If administrator is forced to deploy DNS related credentials (in my case the permission to change route53 API), these credentials have potential for compromise
3. With additional configuration complexity, administrator could make some mistake in DNS server automation and increase security vulnerability. For example, instead of relying on a minimal privilege, administrator could take the easy route of simplest and possibly maximal permission to the automation process.
4. With additional configuration complexity, administrator could opt not to rely on DNS challenge

If I have made a mistake in understanding how it works, please point out to me.

At this point, I have to decide whether to revert back to webserver challenge or dig into how I can fully automate DNS challenge renewal.

Thanks

k.z.

[tdelmas]

@kzw

Please correct me if I am mistaken that renewal to certificates issued by DNS challenge record requires an update to the existing already working DNS record.

Yes. The challenge change every time, you can't keep a static record. Same as other challenges.

If you are concerned about security you can delegate only _acme-challenge.<YOUR_DOMAIN>

[_az]

@kzw

This is also based on my experience with AWS issued certificate process where once a DNS challenge record is set up subsequent renewal requires no human intervention.

It's a bit of an apples to oranges comparison. With AWS, you are delegating your domain to their managed services (like ELB) and the certificate keypair cannot be exported.

Your points are fair and true, which is what (imo) makes HTTP and ALPN challenge types superior operationally.

Some people have invented a privilege minimization technique called alias mode, where you delegate _acme-challenge.example.com to a separate zone with separate credentials.

acme-dns is a pretty polished solution that implements that technique.

[tdelmas]

Also, from Why is there no static DNS verification? :

The Ten Blessed Methods (a fun name for the ten particular validation methods listed in section 3.2.2.4 of [certain newer versions of] the Baseline Requirements) require a “random value” or “request token” should be used in this sort of validation. In both cases the value or token is fresh each time, I can’t remember if 3.2.2.4 actually says exactly how long it can reasonably last but we can’t leave it for months at a time certainly.