On Sat, Dec 05, 2015 at 04:23:16PM -0800, Jacob Hoffman-Andrews wrote:
> On 12/04/2015 11:54 AM, Viktor Dukhovni wrote:
> > Can anyone using LE automated rotation check whether the key stays the
> > same or not?
>
> It is up to the user. The official client will generate new keys for
> each issuance by default, but you can provide a CSR for an existing key
> using the --csr flag.
May I ask for your help in providing configuration guidance to LE
users who also plan to publish DANE TLSA records. I'm seeing a
steady trickle of new domains with 90 day LE certificates and TLSA
"3 0 1" records which will surely break in 90 days or less when
the certificate is replaced.
These users really must use "3 1 1" and avail themselves of that
"--csr" option (with a CSR generated for the same key that matches
the TLSA record).
Alternatively, they could use "2 1 1" records that specify the
issuer public key, or with a bit of help from LE, automate
generation of "2 0 1" records that designate the LE trust-anchor
certificate:
On Sun, Dec 06, 2015 at 12:55:29AM +0000, Viktor Dukhovni wrote:
>
> I might note that the 11 distinct certificates are associated with 12
> distinct MX hosts, for which the TLSA record types are:
>
> 8 3 0 1 - Breaks with automated key rotation sans DNS update
> 1 3 0 2 - Breaks with automated key rotation sans DNS update
> 2 3 1 1 - Works if certificate rotation leaves the key unchanged
> 1 2 0 1 - Works provided issuer certificate is unchanged.
>
> The "2 0 1" site published a TLSA record for the LE intermediate
> issuer CA, not the ultimate root CA. That seems to have a 5 year
> lifetime, but it is not clear how often a new intermediate will be
> fielded. That user will have to watch out for that:
>
> Subject = CN=Let's Encrypt Authority X1,O=Let's Encrypt,C=US
> Issuer = CN=DST Root CA X3,O=Digital Signature Trust Co.
> Not before = 2015-10-19T22:33:36Z
> Not after = 2020-10-19T22:33:36Z
It may be helpful for the LE tools to be able to spit out either
the "3 1 1" record for the server's stable public key, or the
DANE-TA(2) TLSA RRs that match the current (and planned for the
next cycle!) LE issuer. At present, this would be some sensible
subset of:
;; subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
;; issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
;; notBefore=Oct 19 22:33:36 2015 GMT
;; notAfter=Oct 19 22:33:36 2020 GMT
;;
_25._tcp.example.com. IN TLSA 2 0 1
7FDCE3BF4103C2684B3ADBB5792884BD45C75094C217788863950346F79C90A3
_25._tcp.example.com. IN TLSA 2 1 1
60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18
_25._tcp.example.com. IN TLSA 2 0 2
95BED189BF575A88E7935F5967154F74908D3C32662C3F0B66AF8522A6AF22653FD693A39EFE3639F5134466C46A16EBB7E849890FDE84324DE645FFE7E892B1
_25._tcp.example.com. IN TLSA 2 1 2
774FAD8C9A6AFC2BDB44FABA8390D213AE592FB0D56C5DFAB152284E334D7CD6ABD05799236E7AA6266EDF81907C60404C57EE54C10A3A82FCC2A9146629B140
If "planned", but not yet "active" CA certs are provided to server
operators sufficiently far in advance, they'll be able to publish
the relevant TLSA RRset in their DNS before automatic updates yield
a certificate that is issued by the new CA cert.
https://tools.ietf.org/html/rfc7671#section-5.2
https://tools.ietf.org/html/rfc7671#section-8.1
--
Viktor.
