Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a test server that I'm trying to change over to HTTPS/SSL, and it has both an internal IP and an external IP. We have to use self-signed certificates for this particular server. There was one time in the past that I did some R&D on RTMPS with Flash, and so I still had a list of steps lying around to create a self-signed certificate for the internal IP, and to place it in the trusted store on client machines.

That being said, I need to get this working simultaneously for both the internal and external IPs. When I try to use the same steps to produce and trust a certificate for the external IP, the server keeps trying to fool around with the internal IP's certifcate, even when the client using the external IP. This apparently has something to do with it going through HTTP headers and getting the certificate for the default site. So even if the external IP's certificate is trusted, the client machine keeps generating a security warning when browsing to the site on the external IP.

Completely casting my previous notes on how to do this with the internal IP aside, how can this be handled simulatenously for both an internal and an external IP? How can you use self-signed certificates for both IPs, with neither generating a security warning in the client's browser?

Note that this is not a duplicate. I understand there's information out there about Subject Alternate Names, wildcard certificates, etc. However:

  1. Much of it is for Apache; I'm using IIS 7.

  2. Much of it is for Linux; I'm using Windows.

  3. It also tends to deal with domain names, which seem to be necessary for wildcard certificates; I'm using IPs only.

  4. Some of what's left at this point expects me to have options in IIS or in Windows that are not universally available.

  5. What few pieces may be left are a little over my head, and the steps they use expect some pre-existing knowledge that's just not there. In other words, they skip steps, jump to advanced topics, etc.

What is a clear list of steps to get this done, assuming that the server is IIS 7 / Windows Server 2008 R2, and that the client machines are using Windows 7 (sometimes Windows Embedded Standard) and different versions of IE? The clients are accessing the pages, web services, and such through the IP addresses, and I have been using OpenSSL (though I'm open to other options). Thank you.

share|improve this question
IIS and Apache use the exact same certs, just different file formats (DER and PEM respectively). Linux and Windows makes absolutely no difference. Using IPs is a bad idea, as you're finding out, as everything is expecting you to use domain names. Options that are not universally available? – Chris S Aug 27 '14 at 13:02
Through the IP address. – Panzercrisis Aug 27 '14 at 13:05
up vote 4 down vote accepted

See Massimo's Answer for the Right way to do it.

Otherwise you can add IPs to the certificate's SAN by creating a configuration file with the following (plus any other options you want):

[ v3_ca ]
subjectAltName = IP:

Or if you have a bunch of IPs....

[ v3_ca ]
subjectAltName = @alt_names

IP.1 =
IP.2 =
IP.3 =

Then issue the normal OpenSSL command to create the certificate with the following additions:

-extfile configuration_file_mentioned_above.cnf -extensions v3_ca

Note: the above line typically starts with openssl x509 -req if you're having trouble.

The simplest valid configuration file would be something like this (I saved this as example.cfg):

distinguished_name = req_distinguished_name
x509_extensions = v3_ca

[ req_distinguished_name ]
commonName = TypeCommonNameHere

subjectAltName = @alt_names

IP.1 =
IP.2 =
IP.3 =

Then run:

openssl req -x509 -nodes -days 3653 -newkey rsa:2048 -keyout example.key -out example.pem -config example.cfg

It will ask for the Common Name for the cert and write out example.key and example.pem with the private and public keys (respectively). Also, you have to put the IPs in the configuration file, but can not put the common name in there (you could, but you still need to type it in when OpenSSL prompts for it).

Also, this example uses a whole configuration file, where the original answer above assumes you already had a configuration file and were augmenting it with the SAN information from an extension configuration file (this is probably just more confusing, but the reason I didn't use the arguments given in the original Answer)

share|improve this answer
Thanks. It looks like my supervisor is still wanting me to go ahead and try to use IP addresses, if possible. Before the Labor Day weekend, I really tried to apply this approach, and I was having trouble getting it to work. I eventually scrapped my previous method for generating a self-signed certificate and tried to use other tutorials, including…,, etc. for the certificate, and .. – Panzercrisis Sep 2 '14 at 14:51
...… for utilizing a config file (I know the last one is for a specific system, but I tried to take the more general aspects from it and apply them); I also tried to look a little bit more into an overall view of what SSL is, etc. Especially if it could be applied to the steps in one the first two tutorials mentioned, what are the steps to integrate this into creating and using the certificate? – Panzercrisis Sep 2 '14 at 14:51
There's more than one way to skin a self-signed cert with OpenSSL... So I posted the simplest and easiest in my Answer. – Chris S Sep 2 '14 at 15:26
Awesome, thanks! I did run into one little platform snag with IE though, so I had to change IP.x to DNS.x to fool IE into thinking the IP was DNS. Somebody else had run into the same problem earlier and started a short thread about it:… – Panzercrisis Sep 2 '14 at 19:34
Thanks for the update and link. Sounds about par for the course for IE. – Chris S Sep 2 '14 at 19:40

You really shouldn't be using IP addresses in a SSL certificate; you should setup a proper DNS infrastructure such that you have f.e. pointing to the internal IP address, and pointing to the external one; then you'll have to put both names as Subject Alternative Names in the certificate, and it will work flawlessly.

That said, you can use IP addresses as SANs; but how exactly this can be done depends both on the tool you are using to request the certificate, and on the certification authority that will be issuing it.

In both cases, you should use a single certificate with two SANs; using two certificates doesn't make sense and wouldn't even work, because you can't bind two different certificates to the same web site.

share|improve this answer
Even for a test server, you shouldn't use IPs? – Panzercrisis Aug 27 '14 at 13:45
SSL is simply not designed to work with IP addresses. It can be forced into accepting them, but it's an ugly kludge, can fail in several ways and it's ultimately much more complex to get it to work than just adding one or two records to your DNS (or to your hosts files). – Massimo Aug 27 '14 at 13:50

If you have two addresses IP or name-based, you need two certs and two https definitions. On Apache httpd this would be two vhost-sections.

share|improve this answer
No, you'll need a single certificate with two SANs. Your approach can work both in IIS (using two web sites with different IP bindings and serving the same content) and in Apache (using two vHosts with similar settings), but is just as painful and useless in both of them. – Massimo Aug 27 '14 at 13:20
@Massimo Interesting. But why are two certificates "painful"? I feel no such pain ;-) - And we have scenarios where we have to do this. – Nils Aug 27 '14 at 19:53
The certificates themselves are not painful. But configuring a web server in that way is needlessly complicated, to say the least. – Massimo Aug 28 '14 at 12:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.