Best practice TLSA RRs for CA-issued certs
[ This assumes you are willing to trust your issuer CA to not misissue certificates for your domain, and include the CA certificate in your server chain file. ]
One approach to making sure that DANE TLSA records are less likely to fail that should work well for sites using CA-issued certificates is to publish both "3 1 1" and "2 1 1" TLSA records:
mx.example. IN TLSA 3 1 1 <digest of server public key> mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>
* The "3 1 1" record protects against "expiration" accidents, and unexpected changes in the issuer's public key (if new certificate chain deployment is automated).
* The "2 1 1" record protects against key rotation errors should a a new server private key be deployed without updating the TLSA RRs. Provided the new certificate is issued by the same CA is unexpired, ... the "2 1 1" record will match.
With a bit of monitoring to ensure that both records match, simultaneous failure of both is much less likely.
This even makes it possible to avoid pre-deployment DNS TLSA records updates when rotating certificates, provided at least one of the issuer public key or the server public key is unchanged in the new chain.
In particular, this is the best practice with Let's Encrypt issued SMTP server certificates, as explained in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certific...
On 14 Apr 2016, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
I know, that's an old mail :-) But I have saved it for the time I will be ready to deploy LE certificates. That time has come.
One approach to making sure that DANE TLSA records are less likely to fail that should work well for sites using CA-issued certificates is to publish both "3 1 1" and "2 1 1" TLSA records:
mx.example. IN TLSA 3 1 1 <digest of server public key> mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>
[…]
In particular, this is the best practice with Let's Encrypt issued SMTP server certificates, as explained in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certific...
First of all I do have to admit that I am lacking knowledge when it comes to certificates, in general. Sofar, I got along with selfsigned certificates that I did generate with the help of all those numerous howtos one can find. It worked.
If I do remember correctly, and if I do understand your conclusions in other mails correctly, long lasting selfsigned certificates plus periodically rotated TLSAs are still a good basis to run a secured mailserver at port 25. (FYI: I am using opendnssec for rotating every 3 month.)
After having read this best practice document, I am still hesitant to deploy a LE certificate to my mailserver's domain, because I do not understand all the implications, yet.
Thus I would like to raise some newbie questions regarding the following project:
domain: example.org mailserver: mx.example.org with TLSA 3 1 1 IMAP server: mail.example.org webserver: www.example.org
#) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. #) .. and forget about the issues mentioned above?
#) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead?
Excuses in advance if this are silly questions, but as I mentioned above, I am lacking skills w.r.t. certificates.
Thanks un advance and regards, Michael
On Dec 29, 2016, at 2:31 PM, Michael Grimm trashcan@ellael.org wrote:
In particular, this is the best practice with Let's Encrypt issued SMTP server certificates, as explained in:
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certific...
First of all I do have to admit that I am lacking knowledge when it comes to certificates, in general. Sofar, I got along with selfsigned certificates that I did generate with the help of all those numerous howtos one can find. It worked.
See also: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436....
If I do remember correctly, and if I do understand your conclusions in other mails correctly, long lasting selfsigned certificates plus periodically rotated TLSAs are still a good basis to run a secured mailserver at port 25. (FYI: I am using opendnssec for rotating every 3 month.)
Yes, you're mostly better off self-signed on port 25.
After having read this best practice document, I am still hesitant to deploy a LE certificate to my mailserver's domain, because I do not understand all the implications, yet.
LE means automatic rotation of the cert (by default with a new key) approximately every 90 days. That can mean that you also need to implement unattended rotation of your TLSA records, but I think it is simpler to use a stable key-pair, which is rotated less frequently, and interactively. Using a "3 1 1" + "2 1 1" combination simplifies the rotation procedure.
Thus I would like to raise some newbie questions regarding the following project:
domain: example.org mailserver: mx.example.org with TLSA 3 1 1 IMAP server: mail.example.org webserver: www.example.org
#) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver ..
Certainly if you use different hostnames "mx.example.com", ... "www.example.com" as above.
#) .. and simultaneously *keep* my selfsigned certificate for the the mailserver ..
Of course.
#) .. and forget about the issues mentioned above?
Yes. Though you may need an LE certificate for the submission service, depending on which clients are doing that. (Mobile phones tend to be difficult to configure for pinned non-CA trust).
#) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead?
Hostnames under a common domain should be fine. Mind you, I've no experience actually using LE (at present), but I can't imagine that it would be difficult to obtain separate certificates for various names under a common domain.
On 29 Dec 2016, at 20:47, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Dec 29, 2016, at 2:31 PM, Michael Grimm trashcan@ellael.org wrote:
First of all I do have to admit that I am lacking knowledge when it comes to certificates, in general. Sofar, I got along with selfsigned certificates that I did generate with the help of all those numerous howtos one can find. It worked.
See also: http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436....
Thanks for that link.
If I do remember correctly, and if I do understand your conclusions in other mails correctly, long lasting selfsigned certificates plus periodically rotated TLSAs are still a good basis to run a secured mailserver at port 25. (FYI: I am using opendnssec for rotating every 3 month.)
Yes, you're mostly better off self-signed on port 25.
Ok. Then I will stick to that for the time being.
After having read this best practice document, I am still hesitant to deploy a LE certificate to my mailserver's domain, because I do not understand all the implications, yet.
LE means automatic rotation of the cert (by default with a new key) approximately every 90 days. That can mean that you also need to implement unattended rotation of your TLSA records, but I think it is simpler to use a stable key-pair, which is rotated less frequently, and interactively. Using a "3 1 1" + "2 1 1" combination simplifies the rotation procedure.
Ok. But that will come to human intervention. And that is something I do want to avoid. Although I am only hosting a handful users, my services sometimes do need to run unattended for some weeks (being abroad job-related, vacations, and such). Thus, I have been looking for a solution that works automatically like opendnssec. But that is not available for the combination of DANE and LE certificates.
Thus I would like to raise some newbie questions regarding the following project:
domain: example.org mailserver: mx.example.org with TLSA 3 1 1 IMAP server: mail.example.org webserver: www.example.org
#) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver ..
Certainly if you use different hostnames "mx.example.com", ... "www.example.com" as above.
#) .. and simultaneously *keep* my selfsigned certificate for the the mailserver ..
Of course.
Perfect.
#) .. and forget about the issues mentioned above?
Yes. Though you may need an LE certificate for the submission service, depending on which clients are doing that. (Mobile phones tend to be difficult to configure for pinned non-CA trust).
Ouch! Thanks, but I completely overlooked that issue.
Well, I do have to dig into postfix' documentation more thoroughly than I during the last minutes. All my users and myself are using Apple's Mail.app (bench and mobile), and myself roundcube once in a while. Those clients work well in this regard, until today.
That said, and still tending to avoid LE on port 25, I will look for a solution that allows me to use a LE certificate for submission and a selfsigned certificate for port 25 services. As I am running FreeBSD and every service (group) runs in it's distinct jail, the following possible solutions come into my mind (untested):
#) two instances of postfix on different domain names, one for 25 and one for 587 #) looking for a functionality in postfix that allows for different certificates for 25 and 587
#) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead?
Hostnames under a common domain should be fine.
Perfect. Thanks for your valuable feedback. I will go for distinct LE certificates for hostnames (mail, www) and stick with selfsigned certificates for port 25. And then I will look for a solution of separating 25 and 587 services. But that is presumably rather OT for this ML.
Thanks and with kind regards, Michael
On Dec 29, 2016, at 3:41 PM, Michael Grimm trashcan@ellael.org wrote:
Using a "3 1 1" + "2 1 1" combination simplifies the rotation procedure.
Ok. But that will come to human intervention. And that is something I do want to avoid. Although I am only hosting a handful users, my services sometimes do need to run unattended for some weeks (being abroad job-related, vacations, and such). Thus, I have been looking for a solution that works automatically like opendnssec. But that is not available for the combination of DANE and LE certificates.
The human intervention is not constrained to happen at any particular time at which you may be unavailable. Rather your certificate continues to be *automatically* renewed with the same underlying key-pair indefinitely.
At such time as you *choose* to perform key rotation, you run a suitable script to generate new keys, obtain a new cert, deploy it, update the DNS "TLSA 3 1 1" record and check that everything is in order. Then you can let the automated tools take it from there for some indefinite new period.
#) .. and forget about the issues mentioned above?
Yes. Though you may need an LE certificate for the submission service, depending on which clients are doing that. (Mobile phones tend to be difficult to configure for pinned non-CA trust).
Ouch! Thanks, but I completely overlooked that issue.
Well, I do have to dig into postfix' documentation more thoroughly than I during the last minutes. All my users and myself are using Apple's Mail.app (bench and mobile), and myself roundcube once in a while. Those clients work well in this regard, until today.
The "smtpd_tls_cert_file" and "smtpd_tls_key_file" settings can take overrides in the master.cf submission entry.
#) looking for a functionality in postfix that allows for different certificates for 25 and 587
No need for a second instance just for separate submission certs. The folks at https://mailinabox.email/ have automated LE certificate management and key rotation. In my survey I see repeated successful TLSA record and certificate rollovers for domains running that stack. I continue to be impressed by their attention to detail.
The mailinabox MX hosts represent 526 out of of ~2300 MX hosts with working TLSA records, so their stack is a noticeably large fraction of the deployed base (by server count, the hosting providers of course dominate by domain count).
On 29 Dec 2016, at 22:01, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Dec 29, 2016, at 3:41 PM, Michael Grimm trashcan@ellael.org wrote:
Ok. But that will come to human intervention.
The human intervention is not constrained to happen at any particular time at which you may be unavailable. Rather your certificate continues to be *automatically* renewed with the same underlying key-pair indefinitely.
At such time as you *choose* to perform key rotation, you run a suitable script to generate new keys, obtain a new cert, deploy it, update the DNS "TLSA 3 1 1" record and check that everything is in order. Then you can let the automated tools take it from there for some indefinite new period.
Oh! I do have do admit then, that I didn't understand that approach by combining two different TLSA "types". I believed, that I wouldn't have the "supervision" about *when* to intervene manually. As I mentioned before, I am having difficulties in understanding the complete picture regarding this process.
But, your and Patrick's feedback will let me start investigating the process of automatic LE certificate and DNSSEC/TLSA renewals in a test jail. I believe that I will understand it better by doing :-)
Well, I do have to dig into postfix' documentation more thoroughly than I during the last minutes. All my users and myself are using Apple's Mail.app (bench and mobile), and myself roundcube once in a while. Those clients work well in this regard, until today.
The "smtpd_tls_cert_file" and "smtpd_tls_key_file" settings can take overrides in the master.cf submission entry.
I knew that you knew it :-) Thanks. I will test that.
#) looking for a functionality in postfix that allows for different certificates for 25 and 587
No need for a second instance just for separate submission certs.
Again. Thanks for your feedback. I will test this.
The folks at https://mailinabox.email/ have automated LE certificate management and key rotation. In my survey I see repeated successful TLSA record and certificate rollovers for domains running that stack. I continue to be impressed by their attention to detail.
The mailinabox MX hosts represent 526 out of of ~2300 MX hosts with working TLSA records, so their stack is a noticeably large fraction of the deployed base (by server count, the hosting providers of course dominate by domain count).
Ok, it *can* be done (by professionals :-) ).
Thanks and with kind regards, Michael
On Dec 29, 2016, at 4:24 PM, Michael Grimm trashcan@ellael.org wrote:
The folks at https://mailinabox.email/ have automated LE certificate management and key rotation. In my survey I see repeated successful TLSA record and certificate rollovers for domains running that stack. I continue to be impressed by their attention to detail.
The mailinabox MX hosts represent 526 out of of ~2300 MX hosts with working TLSA records, so their stack is a noticeably large fraction of the deployed base (by server count, the hosting providers of course dominate by domain count).
Ok, it *can* be done (by professionals :-) ).
Perhaps "dedicated volunteers" is a more apt description. You might find that using their software is simpler than "do it yourself" (DIY). If all you want is a low-effort working mailserver for a personal domain, check out the mailinabox.email option.
On 29 Dec 2016, at 22:29, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Dec 29, 2016, at 4:24 PM, Michael Grimm trashcan@ellael.org wrote:
The folks at https://mailinabox.email/ have automated LE certificate management and key rotation.
Ok, it *can* be done (by professionals :-) ).
Perhaps "dedicated volunteers" is a more apt description. You might find that using their software is simpler than "do it yourself" (DIY). If all you want is a low-effort working mailserver for a personal domain, check out the mailinabox.email option.
No, no, this is my hobby, and I will not let go :-) I am confident that I will get LE certificates running.
I only had had the fear that mailing might break while being abroad, because manual intervention might have been missed during such a period in time.
Thanks and regards, Michael
On Dec 29, 2016, at 4:47 PM, Michael Grimm trashcan@ellael.org wrote:
I only had had the fear that mailing might break while being abroad, because manual intervention might have been missed during such a period in time.
A reasonable concern, a large fraction of LE users botch the cert renewal interaction with TLSA one or more times before they eventually figure out how to do it right.
If you:
* Configure LE cert renewal to NOT replace your key, just issue a new certificate for the *same* key as before:
https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
* Publish a "3 1 1" TLSA record for the stable public key.
Then LE certificate renewal require no DNS changes, and can proceed in an automated manner via their tools.
From time to time, you might decide that your key has been lying around on your server too long, and may now be compromised. Then you create a new key-pair and do LE renewal with that key instead. You then can either go with the process outlined in:
http://tools.ietf.org/html/rfc7671#section-8.1
Or, if you trust LE to not issue certificates for your domain to strangers (the verification process for DV certificates is not especially strong), you can use the "3 1 1 + 2 1 1" approach to simplify the deployment process.
On 29 Dec 2016, at 22:56, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
If you:
- Configure LE cert renewal to NOT replace your key, just issue a new certificate for the *same* key as before:
https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
- Publish a "3 1 1" TLSA record for the stable public key.
Then LE certificate renewal require no DNS changes, and can proceed in an automated manner via their tools.
Thank you for your clarification that *no DNS changes are required*, ..
From time to time, you might decide that your key has been lying around on your server too long, and may now be compromised. Then you create a new key-pair and do LE renewal with that key instead. You then can either go with the process outlined in:
.. *unless* I manually go for a new key. Perfect. That is a procedure I can live with, and I will follow that approach, then.
I'd like to thank you both for your help in understanding what will be the upcoming steps when implementing LE certificates.
With kind regards and a Happy New Year, Michael
Quoting Michael Grimm trashcan@ellael.org:
On 14 Apr 2016, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
I know, that's an old mail :-) But I have saved it for the time I will be ready to deploy LE certificates. That time has come.
One approach to making sure that DANE TLSA records are less likely to fail that should work well for sites using CA-issued certificates is to publish both "3 1 1" and "2 1 1" TLSA records:
mx.example. IN TLSA 3 1 1 <digest of server public key> mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>
[…]
#) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. #) .. and forget about the issues mentioned above?
#) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead?
You can get multiple certificates, I have several myself in a single domain, and so this same thing.
I am using an LE certificate for my DANE TLSA records, and I do have the auto-rotation script update the TLSA entry. While this is as simple as it sounds, dnssec makes it more complicated.
You have to remember your dns ttl and and dnssec rrsig ttl and rrsig expiration for the given entry. I have switched to using dns slave servers and in my implementation that means dnssec rrsig values are signed valid for a week, so I don't push out the new certificate from LE, till two weeks after I added the TLSA dns record, to be safe.
The only issue I have had with selfsigned certs is that some mailservers will not send you email if you use one, since the sender has turned on certificate verification, and it will not fail back to non-encrypted to send email. This is mainly a misconfig on their part, but it matters if you want email from them. This has been very minimal impact, but I have seen it a few times.
On 29 Dec 2016, at 20:56, Patrick Domack patrickdk@patrickdk.com wrote
Quoting Michael Grimm trashcan@ellael.org:
#) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. #) .. and forget about the issues mentioned above?
#) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead?
You can get multiple certificates, I have several myself in a single domain, and so this same thing.
Thanks for your feedback. Then I will gor for that.
I am using an LE certificate for my DANE TLSA records, and I do have the auto-rotation script update the TLSA entry. While this is as simple as it sounds, dnssec makes it more complicated.
You have to remember your dns ttl and and dnssec rrsig ttl and rrsig expiration for the given entry. I have switched to using dns slave servers and in my implementation that means dnssec rrsig values are signed valid for a week, so I don't push out the new certificate from LE, till two weeks after I added the TLSA dns record, to be safe.
See my answers to Viktor. I am very hesitant when it comes to human intervention. Thus, I will avoid it.
The only issue I have had with selfsigned certs is that some mailservers will not send you email if you use one, since the sender has turned on certificate verification, and it will not fail back to non-encrypted to send email. This is mainly a misconfig on their part, but it matters if you want email from them. This has been very minimal impact, but I have seen it a few times.
I haven't run into that issue, yet, luckily. If that will happen to my users, I will have to take the burden and apply LE certificates for port 25 as well. But until that time, I will avoid human intervention into a process where two autorotation tools go for "incompatible" tasks :-) Or is there one single tool dealing with DNSSEC, TLSA rotation, and LE upgrades on the market?
Thank you for your valuable input and with kind regards, Michael
Quoting Michael Grimm trashcan@ellael.org:
On 29 Dec 2016, at 20:56, Patrick Domack patrickdk@patrickdk.com wrote
Quoting Michael Grimm trashcan@ellael.org:
#) Would it be possible to get *two* distinct LE certificates, one for the IMAP and one for the webserver .. #) .. and simultaneously *keep* my selfsigned certificate for the the mailserver .. #) .. and forget about the issues mentioned above?
#) Or should I strictly separate my mailserver from the rest by means of distinct domains, instead?
You can get multiple certificates, I have several myself in a single domain, and so this same thing.
Thanks for your feedback. Then I will gor for that.
I am using an LE certificate for my DANE TLSA records, and I do have the auto-rotation script update the TLSA entry. While this is as simple as it sounds, dnssec makes it more complicated.
You have to remember your dns ttl and and dnssec rrsig ttl and rrsig expiration for the given entry. I have switched to using dns slave servers and in my implementation that means dnssec rrsig values are signed valid for a week, so I don't push out the new certificate from LE, till two weeks after I added the TLSA dns record, to be safe.
See my answers to Viktor. I am very hesitant when it comes to human intervention. Thus, I will avoid it.
The only issue I have had with selfsigned certs is that some mailservers will not send you email if you use one, since the sender has turned on certificate verification, and it will not fail back to non-encrypted to send email. This is mainly a misconfig on their part, but it matters if you want email from them. This has been very minimal impact, but I have seen it a few times.
I haven't run into that issue, yet, luckily. If that will happen to my users, I will have to take the burden and apply LE certificates for port 25 as well. But until that time, I will avoid human intervention into a process where two autorotation tools go for "incompatible" tasks :-) Or is there one single tool dealing with DNSSEC, TLSA rotation, and LE upgrades on the market?
You just add it as part of your certificate update script.
Just like you would have it bind a call to update like apache for certificate pinning, you have it call nsupdate to add the new tlsa record into your dns server.
On 29 Dec 2016, at 21:56, Patrick Domack patrickdk@patrickdk.com wrote:
Quoting Michael Grimm trashcan@ellael.org:
But until that time, I will avoid human intervention into a process where two autorotation tools go for "incompatible" tasks :-) Or is there one single tool dealing with DNSSEC, TLSA rotation, and LE upgrades on the market?
You just add it as part of your certificate update script.
Just like you would have it bind a call to update like apache for certificate pinning, you have it call nsupdate to add the new tlsa record into your dns server.
Well, that sound much better than assumed. But I will test it in a test jail, first.
Thank you, again, and with kind regards, Michael
participants (3)
-
Michael Grimm -
Patrick Domack -
Viktor Dukhovni