Creating the right Certificates for STARTTLS use in SMTP

Recently I have been playing  around with STARTTLS, SMTP & Enforcement of STARTTLS policy. This has led me to make several suggestions for evolutions on the way the sendmail open source MTA should handle this enforcement – I will address this in a future post in a few weeks.  For this article I want to address some other observations.

One of the observations I made during my work on this subject was how difficult it can be to setup an enforceable policy when controlling STARTTLS SMTP connections. One of the reasons for this is that the certificates which are being used need to be carefully designed to allow correct identification of the hostnames.

Certificates used for TLS connections adhere to the X.509 standard and they are identified by a Subject and an Issuer using a X.500 notation. For example the certificate hosted on my personal mail server has following data:

• Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA
• Subject: description=286542-g0Fq7m73HbBwiIkc, C=GB, ST=Greater London, L=London, O=Christophe Wolfhugel, OU=StartCom Verified Certificate Member, CN=k.wolfhugel.eu/emailAddress=postmaster@wolfhugel.eu

The Issuer identifies the authority which did deliver my certificate, and in the above example I got mine from an intermediate authority run by a company called StartCom. The Subject identifies my SMTP server, and you may recognize that an Internet hostname is present in the CN field. This is the canonical hostname of my mail server.

Should my mailserver only be used and known under this single name, k.wolfhugel.eu, everything would be easy but this is not the case: my MX record as published in the DNS is relay.wolfhugel.eu. So unless my certificate also shows this name, validation and verification might be more difficult (i.e. would need manual configuration).

Fortunately the certificates are able to handle X509v3 Extensions and one of particular interest to us: the Subject Alternative Names which can be displayed for my server’s certificate as:

X509v3 Subject Alternative Name:
DNS:k.wolfhugel.eu, DNS:wolfhugel.eu, DNS:relay.wolfhugel.eu


RFC-6125 which is quite long and complex gives very detailed explanations on how this should be used, but for messaging users I would summarize this as:

• When you create certificates being used for Email ensure that all valid names which are used (canonical hostname, names appearing in MX records, names appearing in SMTP banners or HELO/EHLO negotiation) are included as DNS values in the X509v3 Subject Alternative Names extension
• It is still advised to have a valid and recognized value (i.e. a hostname) in the CN field of the Subject of your certificate, but RFC-6125 states that if Subject Alternative Names are present, applications should use only these names for identifying the remote party
• It is best that the hostname indicated as the CN is also present as a DNS Subject Alternative Name

So, for example, if your domain name is domain.eu and your MX record mx.domain.eu goes to a load balancer and then two hosts called s1.domain.eu and s2.domain.eu the content of your certificates would be adequate if being:

• for s1: CN=s1.domain.eu, Subject Alternative Names: DNS:mx.domain.eu DNS:s1.domain.eu
• for s2: CN=s2.domain.eu, Subject Alternative Names: DNS:mx.domain.eu DNS:s2.domain.eu

This simple recommendation will make life easier for anyone who wishes to enforce TLS security during SMTP transactions.

In conclusion, don’t forget your Subject Alternative Names when creating certificates which are being used for STARTTLS SMTP traffic.