Cerbot api available? gen_validation, check_validation

[BrendenDigital]

Integrating certbot DNS validation into complicated systems seems clumsy and brittle.

For example, one installation involves a custom docker container plus four bash scripts plus crontab...per host, across dozens of hosts in multiple colos.

The cumulative delays, required for DNS record propagation to caching resolvers, is ridiculous when spanning hundreds or even just dozens of domains, plus the likely multiple hosts. Adding to the ridiculous is the necessary dozens or hundreds of per-domain service reload/restarts, most done remotely via ssh cli and/or message queue. The delays and complexity are not caused by certbot, but they are definitely greatly compounded.

--manual-auth-hook script logic is confounded by multiple iterations per-domain. For example, this precludes using "sed" deletion where it would otherwise be most appropriate and necessitates another 'shell' script just to handle global deletions of "_acme-challenge" lines from DNS zone files.

It would help if certbot provided api-style verbs that are single-function specific, in this case, "gen_validation". Does it? Is there a tool that does? A second verb needed would be "check_validation".

Everything else is already necessarily being done by local scripts; all that's needed is for certbot to generate its validation codes (one or more per domain ok, but one or more returned from one call, per-domain) and then check those codes, as an independently callable process.

[sahsanu]

Hello @BrendenDigital,

@BrendenDigital

The cumulative delays, required for DNS record propagation to caching resolvers,

Why you need to wait for propagation to caching resolvers?, you only need new records being propagated to your authoritative DNS servers. Let's Encrypt doesn't ask to any resolver, it asks to your authoritative DNS servers directly.

@BrendenDigital

--manual-auth-hook script logic is confounded by multiple iterations per-domain. For example, this precludes using "sed" deletion where it would otherwise be most appropriate and necessitates another 'shell' script just to handle global deletions of "_acme-challenge" lines from DNS zone files.

Sorry but I didn't understand above problem.

@BrendenDigital

Everything else is already necessarily being done by local scripts; all that's needed is for certbot to generate its validation codes (one or more per domain ok, but one or more returned from one call, per-domain) and then check those codes, as an independently callable process.

You can do that inside your auth hook script. Since certbot 1.4.0 two new variables are passed to the auth and cleanup hook scripts:

• CERTBOT_REMAINING_CHALLENGES contains the number of challenges that remain after the current one (so it equals to 0 when the script is called for the last challenge)
• CERTBOT_ALL_DOMAINS contains a comma-separated list of all domains concerned by a challenge for the current certificate

So you can add the dns records for the domains in your cert in every call and check them only when CERTBOT_REMAINING_CHALLENGES is 0, or you can save all the domains and tokens and add the DNS records and perform the checks only when the last domain is presented, etc.

And you can do the same for cleanup hook script.

Cheers,
sahsanu

[BrendenDigital]

@sahsanu

So you can add the dns records for the domains in your cert in every call and check them only when CERTBOT_REMAINING_CHALLENGES is 0 , or you can save all the domains and tokens and add the DNS records and perform the checks only when the last domain is presented

Thank you for this.

Also, I found this useful (from the docs on challenge types):

" Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server.

[sahsanu]

A lot of people use acme-dns to resolve dns challenges (because their DNS provider doesn't provide an api, or there isn't a dns plugin available in the acme client they use or simply to centralize their challenges):

joohoi/acme-dns

[Osiris]

@BrendenDigital

Integrating certbot DNS validation into complicated systems seems clumsy and brittle.

Then maybe certbot isn't suitable for your situation. There are numerous other ACME clients out there, including just libraries. So you could build your own implementation to your liking.

[jvanasco]

If you're doing DNS-01 validation, "acme-dns" is the only sane option to get things accomplished. If you have 3rd party providers, there are security concerns and internal caching issues; if you control your own dns, things get messy fast.

For complex setups with dozens-to-hundreds of domains, acme-dns recently accepted a PR of mine - PR 243. This PR relaxes their API's validation to use RFC valid subdomains, instead of the original UUID. This lets you do something dangerous and absusive -- going into the backend data storage and editing the sudomain records to something of your own choosing. We've been using that for a while.

If you have a giant system, I wrote and maintain a centralized API driven ACME Client and Certificate Manager - Peter SSLers. This project is designed to consolidate Certificate Requests and Deployment across internal networks, and loading certs into Nginx/OpenResty dynamically.

[Osiris]

@jvanasco

if you control your own dns, things get messy fast

Howcome? What's wrong with RFC2136?

[jvanasco]

@Osiris

Howcome? What's wrong with RFC2136?

Technology wise, this is simple.
Doing this with a handful of domains, also simple.

When it comes to administration and production deployment of "spanning hundreds or even just dozens of domains" that are "across dozens of hosts in multiple colos", handling this via BIND and the main DNS records is a nightmare. You will have different systems competing for the same records and potentially/likely overwriting them - unless you start taking into account race conditions. You also have all these various servers with dangerous DNS credentials on them (e.g. the TSIG key with RFC2136, a vendor api key, or some internal system identifier if you're doing things with your own systems could all be compromised), which means you must put in place various additional safeguards. Then you also have to worry about internal DNS caching and whatever propagation systems that might be in place. The complexity to properly and safely deploy a multi-node or multi-domain setup via DNS-01 is 100x more work effort than the bare minimum required to simply implement it.

The acme-dns design eliminates most of the security concerns, the caching/propagation issues, and the potential race conditions (though you still have potential issues with duplicate certificate limits).

• List item

[BrendenDigital]

agree. looking seriously into acme-dns

thank you everyone for replies, input.

[rg305]

@jvanasco

You also have all these various servers with dangerous DNS credentials on them

Then you have not taken full advantage of DNS authentication delegation (via CNAME).
It seems implied at times in the instructions for acme-dns, but why not use it all the time every time?
You could easily send all requests to a much "safer" subdomain (or to a completely separate domain).
To a DNS zone that would not create a critical failure point to business operations if/when such a compromise is experienced.

Given:

• Most instructions are generally void of security concerns.
• Security is left for the implementer to exercise.
• Defying all logic and statistics (Math): The current average I.Q. is actually Below Average
• Common sense is no longer common.
• If it doesn't have any really good memes, it won't get much notice.
• Much like this laundry list of never to be read non-sense.
• Remember to floss daily.