Letsencrypt & TLSA - automation
Attached is a bash script that I am developing to automate the generation of TLSA records from Letsencrypt certificates.
the script is called from the certbot renew hook, it can also be run stand alone - Certbot_TLSAgen path-to-certificate "space separated list of domains included in cert"
It seems to work, but would some kind sole take a look and where I have or are about to screw up.
Any suggestions as to how to get the output into my DNS (Bind9) preferably without using nsupdate. I am not keen on nsupdate as it makes a mess of the zone files, which I use as documentation for my DNS.
Has anybody heard of a electronic "one time pad" system.
TIA
JohnA
On 02/19/2017 07:20 PM, John Allen wrote:
Any suggestions as to how to get the output into my DNS (Bind9) preferably without using nsupdate.
For what it's worth, my method to insert TLSA records into my zone files is to use some M4 macros.
The idea is to "fetch" the digests from the zone file when signing it, instead of "pushing" the digests to the zone file when renewing the certificates.
So, my zone file contains something like that:
---8<--- m4_define(SPKI_DGST, `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ openssl rsa -pubin -outform DER | \ openssl dgst -sha256 -binary | \ openssl enc -base64)')
_443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert) _25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert) --->8---
(Actually the macro definition is in a separate file which is included in the zone file. But you get the idea.)
The file is then processed by `m4 -P` and the resulting zone file is signed by dnssec-signzone.
(The manual for GNU M4 contains a warning that M4 can be "fairly addictive" and that its users tend to use it everywhere; I'm afraid that's true.)
Damien
On Feb 19, 2017, at 2:02 PM, Damien Goutte-Gattat dgouttegattat@incenp.org wrote:
---8<--- m4_define(SPKI_DGST, `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ openssl rsa -pubin -outform DER | \ openssl dgst -sha256 -binary | \ openssl enc -base64)')
_443._tcp.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/web/cert) _25._tcp.mail.example.com. IN TLSA 3 1 1 SPKI_DGST(/path/to/mail/cert) --->8---
Are you sure that base64 works in this context??? The presentation format for TLSA records is hex encoded. I use:
hexdump -ve '/1 "%02X"'
where you're using "openssl enc -base64"
(The manual for GNU M4 contains a warning that M4 can be "fairly addictive" and that its users tend to use it everywhere; I'm afraid that's true.)
Long ago I too was an m4 addict, but then I kicked the habit... :-)
That said, this implementation looks sensible.
On 02/19/2017 08:23 PM, Viktor Dukhovni wrote:
Are you sure that base64 works in this context??? The presentation format for TLSA records is hex encoded.
Oups. I re-wrote the macro in my message from memory instead of pasting it from my actual script, and of course I messed up.
(Coincidentally, I spent the last few hours writing an introduction to HTTP Public-Key Pinning, which does use base64 encoding.)
My real macro is:
m4_define(SPKI_DGST, `m4_esyscmd(openssl x509 -in $1 -pubkey -noout | \ openssl rsa -pubin -outform DER | \ openssl dgst -sha256 | cut -d" " -f2)')
Sorry about that,
Damien
How do you intend to deal with the DNS caching issues? I.e, that you need to renew the SSL cert and then publish it in the DNS for at least one TTL before actually putting the cert in to production.
Mike
* on the Sun, Feb 19, 2017 at 01:20:52PM -0500, John Allen wrote:
Attached is a bash script that I am developing to automate the generation of TLSA records from Letsencrypt certificates.
the script is called from the certbot renew hook, it can also be run stand alone - Certbot_TLSAgen path-to-certificate "space separated list of domains included in cert"
It seems to work, but would some kind sole take a look and where I have or are about to screw up.
Any suggestions as to how to get the output into my DNS (Bind9) preferably without using nsupdate. I am not keen on nsupdate as it makes a mess of the zone files, which I use as documentation for my DNS.
Has anybody heard of a electronic "one time pad" system.
I am not sure, I have used INCLUDE statements in my zone files in the past. But some people don't like them.
My thinking is that immediately after a cert update I would include two files current and current -1 (probably using symlinks), after the TTL period has past/expired I would remove current -1. Removing it might mean that I update its symlink to point to an "empty" file. not literal empty but only contains a comment(s)??
Another way, one that to me this feels extremely clumsy and as a result I am not too keen on. Might be to have two copies of the zone file, a working zone file and an operation zone file. The operational zone is created by concatenation of the working file + the current TLSA file + the expiring TLSA file during the TTL period.
Still have not worked out how to update the SOA sequence number, bearing in mind that the the Bind zone file is somewhat free form.
JohnA
On Feb 20, 2017, at 2:25 AM, Mike Cardwell dane@lists.grepular.com wrote:
How do you intend to deal with the DNS caching issues? I.e, that you need to renew the SSL cert and then publish it in the DNS for at least one TTL before actually putting the cert in to production.
Indeed this is the key issue. The certificate provided by Let's Encrypt should not be deployed as the live certificate used by the MTA until the DNS TLSA records have been in place for at least a couple of TTLs.
Keep in that "TTL" here means not just the TTL for the RRset, but also the refresh time of the zone by any slave servers, since until they obtain fresh data they may be serving stale records with the full data TTL.
The simplest approach is to not point your MTA directly at the LE certs, but instead to update the copy used by the MTA once the LE cert and its TLSA digest have been in place sufficiently long...
This is complicated, which is why I recommend the "3 1 1" + "2 1 1" approach with a stable public key described in:
http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436....
and also in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certific...
On 2017-02-20 at 22:38 -0500, Viktor Dukhovni wrote:
Indeed this is the key issue. The certificate provided by Let's Encrypt should not be deployed as the live certificate used by the MTA until the DNS TLSA records have been in place for at least a couple of TTLs.
This is why I just use DANE on the CA certs, with a spare CA entry, so that I don't need to coordinate grace periods around updating DNS on each renewal.
For exim.org, it's just LE. I ended up dropping down to just X3 and X4.
For my own domains, it's LE and my private CAs.
For HPKP where there is a little more room inside the TCP stream and I set longer TTLs, I include a commercial CA too; if everything goes to hell and I end up paying for some certs for a year, I at least have an exit plan. I can add to DNS as-and-when needed.
-Phil
On Feb 20, 2017, at 11:38 PM, Phil Pennock dane-users-phil@spodhuis.org wrote:
This is why I just use DANE on the CA certs, with a spare CA entry, so that I don't need to coordinate grace periods around updating DNS on each renewal.
For exim.org, it's just LE. I ended up dropping down to just X3 and X4.
For my own domains, it's LE and my private CAs.
Thanks for that note.
If one is willing to issue leaf certs from a private CA, that's by far the most robust option for port 25, where having a public trusted CA in the chain is not particularly useful.
By all means, use LE on ports 587/465 for submission from mass-market MUAs, but MTAs will either be opportunistic unauthenticated, or verify private EE/private TA certs.
I'll probably add some code to Postfix 3.3 to make it easy to create a TA key/cert + EE key/cert issued by said TA. And code to roll these as described in the various messages I keep posting links to.
Updating the DNS will require a user-provided hook.
participants (5)
-
Damien Goutte-Gattat -
John Allen -
Mike Cardwell -
Phil Pennock -
Viktor Dukhovni