Best practice TLSA RRs for CA-issued certs

Michael Grimm trashcan at ellael.org
Thu Dec 29 21:41:57 CET 2016


On 29 Dec 2016, at 20:47, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> On Dec 29, 2016, at 2:31 PM, Michael Grimm <trashcan at 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.html#a86444

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



More information about the dane-users mailing list