How to create a multihomed certificate with OpenSSL

Code and wisdom in this article have not been kept up-to-date. Use them at your own peril.

Problem: When I create virtual hosts for my secure web server, my web browser tells me the server certificate is invalid

Background: When connecting to secure web servers, web browsers perform various checks on the certificate presented by the server. One such check is that the host name in the certificate has to match the host name in the URL that the server is connecting to.

Data such as the URL being accessed must be secure, and therefore security negotiation, including certificate checks, is performed before the browser sends any other data to the server.

This means that the server has to give the browser a certificate before the server itself knows which URL the browser will access. So, if https://web.company1.com and https://web.company2.com are served by the server, one of them usually causes the browser to complain — if the server returns the certificate for web.company1.com, then accessing web.company2.com generates a complaint, or vice versa.

TLS includes a renegotiation mechanism that could be used by browsers to address this problem. Unfortunately, no browser seems to do this right now.

Common solutions to this problem are:

  • Ignore the problem. This is a bad solution because it trains users to click away an important security warning.

  • Run different servers on different IP addresses. This solution is workable, but somewhat troublesome to maintain. Most server operating systems make running a single server instance very easy, but running multiple instances is often beyond the realm of what the built-in administrative tools support; as a result, the server administrator often has to meddle with the server and the OS on a rather low level.

Solution: One possible solution to this problem is to use a certificate which specifies multiple hostnames. In the above example, the certificate contains both web.company1.com and web.company2.com, and therefore browsers don’t complain when accessing either.

This solution makes maintaining a secure virtual hosts as easy as maintaining insecure virtual hosts. The downside of this solution is that creating the certificate with multiple names can be painful. Then again, creating certificates is often painful regardless.

A certificate with multpile names has two special parts: the distinguished name (DN) and the subject alternative name (altName).

Normally, the DN of a web server certificate is of the form /C=Country​/ST=State​/L=Town​/O=Organization​/CN=web.company.com. For a certificate with multiple names, the DN should be /C=Country​/ST=State​/L=Town​/O=Organization​/CN=web.company1.com​/CN=web.company2.com.

Certificates often don’t have an altName, or if they do, it contains the contact addres for the server. However, a certificate with multiple names should contain both host names in its altName, for example: DNS:web.company1.com, DNS:web.company2.com. The contact address, if desirable, can be added to the hostnames.

The precise way to create a certificate like this depends on the tool you are using to create your certificates. I used tinyca, an X Windows Certificate Authority application, and there I had to:

  • In server certificate settings (Preferences > OpenSSL Configuration), change “Subject alternative name” to “Ask User” and select “DNS Name”.

  • Enter web.company1.com/CN=web.company2.com as the common name for my certificate. Note that this blithely abuses the way tinyca calls through to OpenSSL — it assumes that tinyca will concatenate CN= and the common name I enter and pass the result to OpenSSL.

  • Enter web.company1.com, DNS:web.company2.com as the subject alternative name for my certificate; this likewise abuses tinyca, which prepends DNS: to what I enter before calling OpenSSL.

The end result of these machinations is that I have a certificate that OpenSSL is happy with and that works in many browsers I tested, but not all of them. This is what OpenSSL thinks of it:

Certificate:

    Data:
        [...]
        Subject: C=US, ST=Massachusetts, L=Somerville, O=Voice of a Star, OU=Server Operations, CN=web.voiceofastar.net, CN=web.periodic-kingdom.org
        X509v3 extensions:
        [...]
            X509v3 Subject Alternative Name:
            DNS:web.voiceofastar.net, DNS:web.periodic-kingdom.org

This technique is in no way limited to web browsers and servers, of course. If you want to have a secure mail server with two host names, the exact same solution applies.

Caveat: I have not tested this with a wide variety of clients, so I cannot vouch for the portability of this technique, but I will happily add your results to these tables:

Web browser compatibility with multihomed certificates
Browser Compatible versions Incompatible versions
Safari 1.2.4
OmniWeb 5.0.1
Internet Explorer (Mac) 5.2
Chimera 0.2.8
Mozilla 1.4
Mail program compatibility with multihomed certificates
Browser Compatible versions Incompatible versions
Eudora (Mac OS X) 6.2 6.1 and older
Mail (OS X) 1.3.9

Acknowledgments: This technique was suggested to me by Tim Dierks

Filed under:
 0 Comments0 CommentComment
Contact