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
--
Viktor.
