On Wed, Feb 11, 2015 at 12:59:01PM +0100, Frank Fiene wrote:
This should work for pop3s and imaps, too, shouldn?t it? What is about pop3 and imap with TLS, the same?
For a shared key for multiple services that use distinct protocols:
_dane.mail.example.com. IN TLSA 3 1 1 <sha256 SPKI digest> _25._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _110._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _143._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _587._tcp.mail.example.com. IN CNAME _dane.mail.example.com. _993._tcp.mail.example.com. IN CNAME _dane.mail.example.com.
This only makes sense if you need the certificate to be from a public CA trusted by some SMTP/IMAP/POP clients. For port 25, you should just go with a distinct self-signed key. Not sharing keys avoids simultaneously breaking all the services that share that key when a mistake is made during key rotation.
To generate the "3 1 1" SPKI digest:
printf '_dane.%s. IN TLSA 3 1 1 %s\n' \ mail.example.com \ $(openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')
* Never make the mistake of using a certificate digest with a "3 1 1" TLSA record or an SPKI (i.e. SubjectPublicKeyInfo or, in other words, the public key algorithm id, parameters and key bits) digest with a "3 0 1" TLSA record.
* Never make the mistake of installing a new key or certificate without following the TLSA record update process described in:
http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1 http://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4