What name is used in a TLS certificate?

Products

• Messaging Gateway
• Messaging Gateway for Service Providers
• Messaging Gateway Hardware

Issue/Introduction

You need to create a TLS certificate for use in the Messaging Gateway, either for web browsing (HTTPS) or email (SMTP). What name do you use?

Resolution

What name is used in a TLS certificate?

When creating a TLS certificate for a receiving server, the value that needs to exist in the Subject Alternative Name (SAN) or Common Name (CN) field of the certifiate is any Fully Qualified Domain Name (FQDN) or IP that is used to connect to the server.

An example, using a web browser

For example, if you opened a browser (client) and used the URL https://www.example.com/, then the process would use DNS to resolve an IP for the FQDN www.example.com (server) and your system would connect to that IP and start the HTTPS (TLS) handshake. During the handshake, your browser would request the TLS certificate from the receiving server and validate that the name used in the entered URL is listed in the certificate's SAN (or CN) fields. If a match is found, then the certificate validation passes, otherwise this would not be considered a valid server for the entered URL.

It is important to note that the receiving server's hostname does not affect the above process. The TLS certificate validation process only confirms that the entered name (in the URL) validates as a name authorized in the certificate.

How this works in the Simple Mail Transfer Protocol (SMTP)

For SMTP, there is no way to enter a URL to specify where the sending mail server (client) connects to. In general, the SMTP process determines the receiving mail server name as follows:

1. The recipient address is used to determine what domain name to resolve.
2. The sending mail server (client) then resolves the receiving server (server) FQDN by lookup of the DNS MX record for the recipient email address domain.
   • If an MX record for the recipient domain does not exist, then the sending mail server (client) uses the recipient email address domain directly as the FQDN.
3. The sending mail server (client) then resolves the IP address to connect to using the FQDN resolved in the previous step and connects to that IP.
4. As in the browser example above, the TLS handshake proceeds and the derived FQDN is validated against the certificate.
5. If the derived FQDN is found in the certificate, the TLS validation passes and the SMTP handshake continues.

Conclusion

In summary, the name that needs to exist in the certificate SAN or common name is the FQDN that is resolved from the recipient email address, typically through an MX record lookup in DNS. The recipient mail server host name or other related network names are not relevant to this process. In this way, several servers that are associated with an MX record can all use the same certificate data.