How to create a multihomed certificate with OpenSSL
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.comas the common name for my certificate. Note that this blithely abuses the way tinyca calls through to OpenSSL — it assumes that tinyca will concatenateCN=and the common name I enter and pass the result to OpenSSL. - Enter
web.company1.com, DNS:web.company2.comas the subject alternative name for my certificate; this likewise abuses tinyca, which prependsDNS: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:
| Compatible versions | Incompatible versions | |
|---|---|---|
| Safari | 1.2.4 | |
| OmniWeb | 5.0.1 | |
| Internet Explorer (Mac) | 5.2 | |
| Chimera | 0.2.8 | |
| Mozilla | 1.4 |
| Compatible versions | Incompatible versions | |
|---|---|---|
| Eudora (Mac OS X) | 6.2 | 6.1 and older |
| Mail (Mac OS X) | 1.3.9 |
Acknowledgments: This technique was suggested to me by Tim Dierks
I wonder if you’ve ever run into problems with a CN that’s too long? My openssl choked when I tried to list too many servers, apparently it wants a CN that is 64 characters or less.
But it seems that maybe browsers don’t care about the CN provided that the hostname is listed in one of the subjectAltNames.. or at least, MSIE7, FF2, and Safari3 don’t. In other words, I have a working multihomed certificate with a single CN.
Thought it might help others to know this, and maybe save you some work when you create new certificates.
Thanks, Chris. With my certs, I didn’t happen to run into the 64-character limit, but now I know what to do if I need to add more hostnames to my certs.
I do what you are doing and have a guy using Safari who is getting errors. Perhaps Safari tried to fix the potential exploits with the altnames but fixed it badly?
I include the web page link above.
Thanks for this tip! I’m hoping that I can use this with outlook so that people who access a machine by its different IP’s on different networks can all avoid being told ‘certificate name does not match the server’.