Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[John]

You might find this useful 
https://github.com/zzz2002/Certbot_TLSAgen_Hook I wrote it to address a 
similar problem.


if there is a problem with it let me know and I will try to fix it.  i 
had intended to add other update mechanisms, but i have not had time to 
get working on them.


John A


On 6/30/2017 8:06 PM, /dev/rob0 wrote:

On Wed, Apr 20, 2016 at 01:19:29PM -0500, I wrote:

On Wed, Apr 20, 2016 at 03:53:24PM +, Viktor Dukhovni wrote:

[ LE certificate expired, DANE notification received ]


My temporary fix was to remove the TLSA records, sorry.  I cannot
risk losing mail as my poor brain tries to digest all this. :)

14 months later I got back to this. :)


I'm going to consider my options here before I replace the TLSA
records.  I am thinking I only want my LE cert on submission (so
that MUAs will be able to verify it) and to replace my port 25 cert
with one from my own private CA.

And this is what I have done, initially on domain nodns4.us, but
several other zones are signed and will be using TLSA records.

Thanks again for all your work on DANE and Postfix.

Thanks also to P@rick and the sys4.de gang for the validation site.

Question: I noticed my domain in a drop-down list there.  Is the
validation site maintaining a list of DANE-enabled and former DANE
zones?  IOW, should I drop a note to Victor when adding more zones,
or is the validation site taking care of that?



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[/dev/rob0]

On Wed, Apr 20, 2016 at 01:19:29PM -0500, I wrote:
> On Wed, Apr 20, 2016 at 03:53:24PM +, Viktor Dukhovni wrote:

[ LE certificate expired, DANE notification received ]

> My temporary fix was to remove the TLSA records, sorry.  I cannot 
> risk losing mail as my poor brain tries to digest all this. :)

14 months later I got back to this. :)

> I'm going to consider my options here before I replace the TLSA 
> records.  I am thinking I only want my LE cert on submission (so 
> that MUAs will be able to verify it) and to replace my port 25 cert 
> with one from my own private CA.

And this is what I have done, initially on domain nodns4.us, but 
several other zones are signed and will be using TLSA records.

Thanks again for all your work on DANE and Postfix.

Thanks also to P@rick and the sys4.de gang for the validation site.

Question: I noticed my domain in a drop-down list there.  Is the 
validation site maintaining a list of DANE-enabled and former DANE 
zones?  IOW, should I drop a note to Victor when adding more zones, 
or is the validation site taking care of that?
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[/dev/rob0]

On Wed, Apr 20, 2016 at 03:53:24PM +, Viktor Dukhovni wrote:
> If any of this encourages some readers of this list to deploy
> DNSSEC+DANE, I urge you to make sure that:
> 
> * You have publically discoverable email contact addresses
>   either via "whois", or the "mrname" of DNS SOA record.

RNAME, that is, per RFC 1035; and yes, thank you for the alerts when 
our LE cert expired.  My RNAME was in a different (non-TLSA) zone, 
which also helps someone contact you when your TLSA RRsets do not 
agree with the certificate chain.

My temporary fix was to remove the TLSA records, sorry.  I cannot 
risk losing mail as my poor brain tries to digest all this. :)

> * You monitor your servers, making sure that their TLSA
>   records match the deployed certificate chain and that
>   with usage DANE-TA(2) the server certificate hostname
>   matches the TLSA base domain" of the TLSA record and
>   is not expired.
> 
> * When using a public CA for your certs, consider publishing
>   both a "2 1 1" TLSA record matching the issuing CA public
>   key and a "3 1 1" record matching your server public key.
>   Make sure to include the CA certificate in your server
>   certificate chain file.
> 
> * When not using a public CA for your certs, consider publishing
>   both a "2 0 1" TLSA record matching the public key of a private
>   issuing CA that you create for this purpose, as well as the
>   "3 1 1" record matching your server public key.  Make
>   sure to include the CA certificate in your server certificate
>   chain file.  See
> 
> https://www.ietf.org/mail-archive/web/uta/current/msg01498.html
> 
>   for the rationale.  This approach makes it easier to do key
>   rotation and reduces the risk of authentication failure.

I'm going to consider my options here before I replace the TLSA 
records.  I am thinking I only want my LE cert on submission (so that 
MUAs will be able to verify it) and to replace my port 25 cert with 
one from my own private CA.

ISTM that one of the main benefits of DANE is to reduce reliance on 
public CA services, so I might as well take advantage of that.

> Enough on this topic for a while I think.  I'll post another update
> in October, unless something dramatic happens before then.

Again, your efforts are appreciated.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Danny Horne]

On 19/04/2016 4:19 pm, Dirk Stöcker wrote:
> In case you do not know:
>
> There are two other options for free domain verified certificates:
>
> https://www.startssl.com/ - per cert: 1 domain, 1 year
> https://buy.wosign.com/free/?lan=en - per cert: up to 5 domains, 1-3
> years
>
> Ciao

Thanks for the links Dirk, I've decided to go for the wosign
certificates.  I had been using StartSSL, but for at least a week their
certificate management pages were unavailable (404) and since my
certificates were expiring soon I had to look at alternatives.



signature.asc
Description: OpenPGP digital signature

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

On Tue, Apr 19, 2016 at 04:23:08PM +, Viktor Dukhovni wrote:

> > >In my survey of 12000 DANE TLSA-enabled domains 545 are using LE
> > >certificates.
> > 
> > Is this compared to the ~9600 in December last year? That would be 25%
> > increase in your survey?
> 
> Yes, but some of that is due to new methods to find candidate
> domains, not just more domains found with the same methods.

For example, yesterday I decided to try a new way to find candidate
domains, and that scan is now about 30% done.  I've found 1052 new
DANE TLSA domains, the vast majority of which are hosted by the
usual 3 suspects:

 804 transip.nl
 123 udmedia.de
  35 nederhost.net

This scan will also double my corpus of identified domains that
have DNSSEC for both the domain and at least of the primary MX
hosts (if the domain has MX records).  That number will rise from
~130,000 to ~260,000.  While the total DANE domain count will then
be around 15000.

A more interesting number from December that grows independently
of my prowess at finding largely obscure hosted domains, is the
number of domains that appear on Google's email transparency report
(are actually observed by Gmail to send or receive a non-negligible
quantity of email).

That number was 25 in October at the MAAWG conference, 30 in
December, and is 50 today.   It will soon be 53, because yesterday
the gmx.{de,net,com} domains got DNSSEC signed, quite likely so as
to publish TLSA records in a matter of days if this matches the
recent observations with web.de.

Another interesting metric, (for which I don't have numbers from
December) is that the MX hosts of the ~12000 domains lie in ~1640
distinct delegated domains.  The current survey expansion (at ~30%
progress) has found 7 more.  This metric measures deployment of
DANE by server operators not domain owners, and so counts the top
3 hosting providers as as just 3 deployments, not 7100.

If any of this encourages some readers of this list to deploy
DNSSEC+DANE, I urge you to make sure that:

* You have publically discoverable email contact addresses
  either via "whois", or the "mrname" of DNS SOA record.

* You monitor your servers, making sure that their TLSA
  records match the deployed certificate chain and that
  with usage DANE-TA(2) the server certificate hostname
  matches the TLSA base domain" of the TLSA record and
  is not expired.

* When using a public CA for your certs, consider publishing
  both a "2 1 1" TLSA record matching the issuing CA public
  key and a "3 1 1" record matching your server public key.
  Make sure to include the CA certificate in your server
  certificate chain file.

* When not using a public CA for your certs, consider publishing
  both a "2 0 1" TLSA record matching the public key of a private
  issuing CA that you create for this purpose, as well as the
  "3 1 1" record matching your server public key.  Make
  sure to include the CA certificate in your server certificate
  chain file.  See

  https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

  for the rationale.  This approach makes it easier to do key
  rotation and reduces the risk of authentication failure.

Enough on this topic for a while I think.  I'll post another update
in October, unless something dramatic happens before then.

-- 
Viktor.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

On Tue, Apr 19, 2016 at 05:19:50PM +0200, Dirk Stöcker wrote:

> >In my survey of 12000 DANE TLSA-enabled domains 545 are using LE
> >certificates.
> 
> Is this compared to the ~9600 in December last year? That would be 25%
> increase in your survey?

Yes, but some of that is due to new methods to find candidate
domains, not just more domains found with the same methods.

> >>I'm considering moving to LE but would like some feedback (last post on
> >>this thread was four months ago so early adopters should have
> >>experienced a renewal by now)
> 
> In case you do not know:
> 
> There are two other options for free domain verified certificates:
> 
> https://www.startssl.com/ - per cert: 1 domain, 1 year
> https://buy.wosign.com/free/?lan=en - per cert: up to 5 domains, 1-3 years

https://www.ietf.org/mail-archive/web/uta/current/msg01487.html

Top 10 issuers of certs for DANE MX hosts:

 172 ; Issuer = CN=StartCom Class 1 Primary Intermediate Server 
CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
 166 ; Issuer = CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO 
CA Limited,L=Salford,ST=Greater Manchester,C=GB
 165 ; Issuer = CN=Let's Encrypt Authority X1,O=Let's Encrypt,C=US
  91 ; Issuer = CN=StartCom Class 2 Primary Intermediate Server 
CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
  90 ; Issuer = CN=Gandi Standard SSL CA 2,O=Gandi,L=Paris,ST=Paris,C=FR
  81 ; Issuer = CN=StartCom Class 1 DV Server CA,OU=StartCom Certification 
Authority,O=StartCom Ltd.,C=IL
  63 ; Issuer = CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
  62 ; Issuer = CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
  38 ; Issuer = CN=WoSign CA Free SSL Certificate G2,O=WoSign CA 
Limited,C=CN
  33 ; Issuer = CN=CAcert Class 3 Root,OU=http://www.CAcert.org,O=CAcert 
Inc.

( Note some of the MX hosts support many hundreds of domains, the above 
counts
  the issuer just once for each issued certificate, not once per domain 
served. )

-- 
Viktor.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Dirk Stöcker]

On Tue, 19 Apr 2016, Viktor Dukhovni wrote:


On Tue, Apr 19, 2016 at 02:51:58PM +0100, Danny Horne wrote:


Can anyone follow up on this?  In other words, are any of you using
Let's Encrypt certificates with any of the TLSA options written about?


In my survey of 12000 DANE TLSA-enabled domains 545 are using LE
certificates.


Is this compared to the ~9600 in December last year? That would be 25% 
increase in your survey?



I'm considering moving to LE but would like some feedback (last post on
this thread was four months ago so early adopters should have
experienced a renewal by now)


In case you do not know:

There are two other options for free domain verified certificates:

https://www.startssl.com/ - per cert: 1 domain, 1 year
https://buy.wosign.com/free/?lan=en - per cert: up to 5 domains, 1-3 years

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

On Tue, Apr 19, 2016 at 02:51:58PM +0100, Danny Horne wrote:

> Can anyone follow up on this?  In other words, are any of you using
> Let's Encrypt certificates with any of the TLSA options written about?

In my survey of 12000 DANE TLSA-enabled domains 545 are using LE
certificates.

The most complete how-to style write up is at:


https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

> I'm considering moving to LE but would like some feedback (last post on
> this thread was four months ago so early adopters should have
> experienced a renewal by now)

See also:

https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

and consider publishing both "2 1 1" and "3 1 1" records, and
monitoring both to make sure both match your chain.

Also make sure your "whois" or DNS SOA email contact address is
correct and read by the postmaster.  Something might go wrong,
and it is important to be reachable by email.

-- 
Viktor.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Danny Horne]

On 19/04/2016 3:51 pm, Philip McGaw wrote:
> See my attempt. 
>
> https://skippy.org.uk/lets-encrypt-postfix-and-dovecot/
>
> Sent from my iPhone
>
>
Are you using TLSA records though?  That was what I really wanted
feedback on



signature.asc
Description: OpenPGP digital signature

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Philip McGaw]

See my attempt. 

https://skippy.org.uk/lets-encrypt-postfix-and-dovecot/

Sent from my iPhone

> On 19 Apr 2016, at 14:51, Danny Horne  wrote:
> 
> Can anyone follow up on this?  In other words, are any of you using
> Let's Encrypt certificates with any of the TLSA options written about?
> 
> I'm considering moving to LE but would like some feedback (last post on
> this thread was four months ago so early adopters should have
> experienced a renewal by now)
> 
> On 14/12/2015 10:03 pm, Viktor Dukhovni wrote:
>>> On Dec 14, 2015, at 2:57 PM, Jacob Hoffman-Andrews  wrote:
>>> 
 On 12/14/2015 11:23 AM, Viktor Dukhovni wrote:
 May I ask for your help in providing configuration guidance to LE
 users who also plan to publish DANE TLSA records.
>>> I'd be happy to help, but am a little constrained on time. If you've got
>>> time, would you mind posting a quick explanation at
>>> https://community.letsencrypt.org/c/server-config of why "3 0 1" records
>>> are risky with LE certificates, and the alternatives? I think the email
>>> below is a good start, and if you prefer not to create an account on our
>>> forums I could repost it with permission. I'll then pin the post for
>>> some time to make people see it.
>> Thanks.
>> 
>> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
> 
> 

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Danny Horne]

Can anyone follow up on this?  In other words, are any of you using
Let's Encrypt certificates with any of the TLSA options written about?

I'm considering moving to LE but would like some feedback (last post on
this thread was four months ago so early adopters should have
experienced a renewal by now)

On 14/12/2015 10:03 pm, Viktor Dukhovni wrote:
>> On Dec 14, 2015, at 2:57 PM, Jacob Hoffman-Andrews  wrote:
>>
>> On 12/14/2015 11:23 AM, Viktor Dukhovni wrote:
>>> May I ask for your help in providing configuration guidance to LE
>>> users who also plan to publish DANE TLSA records.
>> I'd be happy to help, but am a little constrained on time. If you've got
>> time, would you mind posting a quick explanation at
>> https://community.letsencrypt.org/c/server-config of why "3 0 1" records
>> are risky with LE certificates, and the alternatives? I think the email
>> below is a good start, and if you prefer not to create an account on our
>> forums I could repost it with permission. I'll then pin the post for
>> some time to make people see it.
> Thanks.
>
> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
>




signature.asc
Description: OpenPGP digital signature

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Jacob Hoffman-Andrews]

On 12/14/2015 11:23 AM, Viktor Dukhovni wrote:
> May I ask for your help in providing configuration guidance to LE
> users who also plan to publish DANE TLSA records.

I'd be happy to help, but am a little constrained on time. If you've got
time, would you mind posting a quick explanation at
https://community.letsencrypt.org/c/server-config of why "3 0 1" records
are risky with LE certificates, and the alternatives? I think the email
below is a good start, and if you prefer not to create an account on our
forums I could repost it with permission. I'll then pin the post for
some time to make people see it.

Thanks,
Jacob

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

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 +, 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.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

> On Dec 14, 2015, at 2:57 PM, Jacob Hoffman-Andrews  wrote:
> 
> On 12/14/2015 11:23 AM, Viktor Dukhovni wrote:
>> May I ask for your help in providing configuration guidance to LE
>> users who also plan to publish DANE TLSA records.
> 
> I'd be happy to help, but am a little constrained on time. If you've got
> time, would you mind posting a quick explanation at
> https://community.letsencrypt.org/c/server-config of why "3 0 1" records
> are risky with LE certificates, and the alternatives? I think the email
> below is a good start, and if you prefer not to create an account on our
> forums I could repost it with permission. I'll then pin the post for
> some time to make people see it.

Thanks.

https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

-- 
Viktor.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Jacob Hoffman-Andrews]

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.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

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.

Thanks for the follow-up.  It might be useful to provide an option
for users of the official client to keep the key unchanged, and
advise DANE users to use that option as part of automated certificate
rollover.  

They would then periodically (at their convenience) generate new
keys and publish corresponding TLSA records before deploying new
certificates for those keys.  At that point automated renewal can
proceed as before.

My DANE SMTP survey has so far found 19 domains with 11 distinct
LE certificates, whose expiration dates are:

   2 ; Expiration = 2016-02-01T10:02:00Z
   1 ; Expiration = 2016-02-02T14:15:00Z
   1 ; Expiration = 2016-02-02T14:29:00Z
   1 ; Expiration = 2016-02-08T15:58:00Z
   4 ; Expiration = 2016-02-08T19:45:00Z
   2 ; Expiration = 2016-02-14T20:07:00Z
   3 ; Expiration = 2016-02-18T11:48:00Z
   2 ; Expiration = 2016-02-22T03:22:00Z
   1 ; Expiration = 2016-02-22T05:57:00Z
   1 ; Expiration = 2016-02-28T00:02:00Z
   1 ; Expiration = 2016-03-02T21:45:00Z

IIRC automated renewal attempts kick in after 60 days with 90 days
total, so I'll not see how well the combination of LE certificate
renewal with DANE TLSA records works for these users until the
beginning of January.

Some sort of advice for the early adopters would be useful I think.

-- 
Viktor.

Re: Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

On Sun, Dec 06, 2015 at 12:38:21AM +, Viktor Dukhovni wrote:

> My DANE SMTP survey has so far found 19 domains with 11 distinct
> LE certificates, whose expiration dates are:
> 
>2 ; Expiration = 2016-02-01T10:02:00Z
>1 ; Expiration = 2016-02-02T14:15:00Z
>1 ; Expiration = 2016-02-02T14:29:00Z
>1 ; Expiration = 2016-02-08T15:58:00Z
>4 ; Expiration = 2016-02-08T19:45:00Z
>2 ; Expiration = 2016-02-14T20:07:00Z
>3 ; Expiration = 2016-02-18T11:48:00Z
>2 ; Expiration = 2016-02-22T03:22:00Z
>1 ; Expiration = 2016-02-22T05:57:00Z
>1 ; Expiration = 2016-02-28T00:02:00Z
>1 ; Expiration = 2016-03-02T21:45:00Z
> 
> IIRC automated renewal attempts kick in after 60 days with 90 days
> total, so I'll not see how well the combination of LE certificate
> renewal with DANE TLSA records works for these users until the
> beginning of January.

I might note that the 11 distinct certificates are associated with 12
distinct MX hosts, for which the TLSA record types are:

   83 0 1   - Breaks with automated key rotation sans DNS update
   13 0 2   - Breaks with automated key rotation sans DNS update
   23 1 1   - Works if certificate rotation leaves the key unchanged
   12 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

-- 
Viktor.

Let's Encrypt certificates for port 25 SMTP and DANE TLSA

[Viktor Dukhovni]

[ FYI, based on text from a recent post to the dane-us...@sys4.de list ]

> Something else to keep in mind with the Let's Encrypt certificates is
> that they have a 90-day lifetime with the automatic renewal process
> starting at sixty days.

Automated replacement might make them entirely unfit for DANE-EE(3).
That is, assuming the automation neglects the necessary DNS update
precondition.

One of the most important features of DANE-EE(3) is that certificates
DO NOT EXPIRE with DANE-EE(3).  You replace it when you are ready
to do it, not when the certificate goes up in smoke.  The expiration
is in the RRSIG end time, not in the certificate.

If you lose that with Let's Encrypt (LE), DO NOT switch to LE.
For port 25 SMTP it'll do more harm than good.  By all means use
LE certificates for port 587 (by configuring different certs for
the MTA and MSA):

  master.cf:
submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_tls_cert_file=$mua_tls_cert_file
  -o smtpd_tls_key_file=$mua_tls_key_file

  main.cf:
mua_tls_cert_file = ... let's encrypt certificate chain + key file name ...

On port 25, go with self-signed certificates "expiring" in the
distant future (20 or more years from now).  One DANE domain whose
administrator "got the memo" has a certificate good for a 1000
years:

Inception = 2014-07-27T14:59:59Z
Expiration = 3013-11-27T14:59:59Z

One way LE for port 25 with DANE can work is if renewal retains
the same private key, and the TLSA records are "3 1 1", making
certificate replacement a non-event, as the key stays the same.

An alternative, is to publish "2 0 1" records for the LE root CA
(which MUST then appear in the server's chain) or "2 1 1" records
for the LE intermediate CA (which must appear in the server's chain,
but that's more typically true anyway).  The reason that I am
suggesting "2 1 1" for intermediates, is that these are often
re-issued with the same key and tend to have lifetimes shorter than
the issuing root.

Using "3 0 1" TLSA records with LE 90 day certificates that are
rotated automatically, sounds like a recipe for disaster, unless
deployment of the new certificate can be delayed (after it is
obtained) and the required DNS updates automated, with the certificate
deployed only once the DNS records have been fielded sufficiently
long.

> Using a Let's Encrypt certificate with DANE TLSA will require an alert
> sysadmin.
> 
> https://community.letsencrypt.org/t/maximum-and-minimum-certificate-lifetimes/264/9

This does not discuss whether a new key is used for each renewal.
Can anyone using LE automated rotation check whether the key stays
the same or not?

-- 
Viktor.