SSL certificate for a public IP address?

I just tried buying a Comodo Positive SSL but it was rejected due to not supporting a public IP address, but instead they only support a domain name.

Does anyone know any SSL certificate provider that supports public IP address instead of a domain name?

My company has a dedicated server hosted with a web hosting company, which is used for running a bugtracker for multiple projects (for multiple clients). Since it's only used for a bugtracker, we don't need a domain name (our clients access it by typing the public IP in their browser).

Solution 1:

I think you can do this, but not the way you're trying to do it.

An SSL certificate is a statement binding a public encryption key to an X.500 structure which includes a CN, or Common Name, element; a signed certificate is one such where the binding is verifiably certified by a third-party certification authority, using the a public key already known to end-users (that stack of Certification Authority (CA) certificates living inside your browser).

When you visit an SSL-secured web site with a browser, the signed CN is made known to the browser. What the browser chooses to do with it is up to the browser. The browsers I'm aware of compare it to the host name requested, and error if it's different (or if that certified binding doesn't stand up to analysis, eg the signing certificate is not known to the browser or the binding is out-of-date, but that's a different issue). There's nothing that in principle stops you from getting a publicly-signed certificate where the CN is an IP address not a FQDN (fully-qualified domain name) [1], but that won't magically make the browser compare the CN with the IP address, instead of with the requested hostname.

I suspect the simplest way to solve your problem is to start your own CA, which is easy to do, and there are many public tutorials about; one is here. Once your end-users import your CA into their browsers, all certificates you mint will be accepted as authoritative.

You may then have a second problem in that you want to run a lot of NameVirtualHost sites on a single IP address. This has historically been insuperable, since (unlike TLS) SSL negotiation happens before anything else on a connection; that is, the CN embedded in your certificate is made known to, and used by, the client before the client is able to say what host they're trying to connect to.

Recently, a protocol extension called SNI (Server Name Indication) seems to have been introduced, which allows client and server to indicate that they'd like to do some host name stuff before the SSL certificate is presented, allowing the right one of a set of certificates to be given by the server. Apparently this requires apache 2.2.10, a sufficiently recent version of OpenSSL, and (importantly) client-side support.

So if I had to do what you're trying to do, I'd be looking at minting my own CA certificate, telling my end-users that they have to use browsers that support SNI and import my CA root certificate, and cutting and signing my own SSL certificates for each bugtrack site.

[1] OK, you may not have found anyone who'll do it, but that's an implementation detail. What I'm trying to show here is that even if you did, it wouldn't solve your problem.

Solution 2:

There is one Root Certificate Authority I know of that is pre-populated with all major browsers and issues SSL certificates on public IP addresses: take a look at GlobalSign. They read out RIPE information to validate your certificate request, so you might want to check first that the RIPE entry is issued on the correct name.

In regards to the feedback this entry has gotten:

Yes, it's preferable to buy a domain name and issue a SSL certificate on that CN. It's also less expensive than the GlobalSign option above.

But, there are cases where SSL certificates with an public IP as the CN are useful. Many internet providers and governments block unwanted sites based on DNS infrastructure. If you are offering some kind of site that is likely to be blocked, for instance for political reasons, it's a good option to have this site accessible through its public IP address. At the same time, you will want to encrypt traffic for those users and you don't want your non-tech users to go through the hassle of clicking through security exception warnings of their browser (because the CN of the certificate doesn't match the actual one entered). Making them install your very own Root CA is even more of an hassle and not realistic.

Solution 3:

Go ahead and buy the domain name. They're cheap, don't be cheaper than that. You only need one. Maybe even just set up bugtracker.yourcompany.com.

Then for each bugtracker, set up a subdomain for that name. Get an SSL cert for each of those subdomains. Since you seem particularly cost averse, the company you want to do business with is called StartSSL.

http://www.startssl.com/

The reason you want to use them is because (in addition to being trusted by the major browsers) their certificates don't cost an arm and a leg. The most basic sort of cert is really, honestly, no-shit free. They verify your identity, then let you issue as many as you need. If you want fancier certs (that normally cost several hundred bucks), you're looking at around $50 for 2 years to support SSL for multiple domains on a single IP.

They're super cheap for what you get. They issue real certs, trusted by your clients browsers, and not 90-day trials like other places do.