SSL certificate for a public IP address?

Question

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.

Comments

[MastaJeet]

I would set up a domain name so that you don't have to remember the IP address when you are at a location where you don't have it bookmarked. Plus, when you change IPs it will be transparent.

[Tom O'Connor]

I'm not sure I'd accept Joe Public's CA, not unless it was underwritten by a big SSL broker.

[MadHatter]

For a specific application, why not? If it's minted by the application provider, and you don't trust him, you're screwed with respect to this application anyway, since he has the private SSL key and can decrypt things regardless. and if that worries them that much, he can just cut self-signed certificates for each of his buqtrack sites, and they can import them on an as-needed basis.

[Rob Moir]

@Tom - if you don't trust the person offering you the certificate in the example above then why would you even be doing business with them in the first place? Whether or not the SSL cert is issued by/with the support of/ a known CA is the least of your worries WRT trust if you're entrusting data to an 'online' app.

[MadHatter]

I presume the fear is that as there seems to be no way to install a CA as authoritative only for certain domains, once they install my CA root, I can certify online banking sites as easily as my own bug tracking application. If I can poison their DNS cache I can then perform a man-in-the-middle attack on their online banking. If this really worries them and they don't want to do use a custom browser for this project, then as I said above I could cut a self-signed certificate for each individual bugtracker, which the clients could install as needed.

[Tom O'Connor]

@Robert I've tried using self-signed certificates on customer-facing websites before. Every time I've had to give support calls explaining why they're having to accept unsigned certificates. After a while, the number of calls (and the man-hours to service them) becomes break-even in terms of cost against buying a trusted certificate. It's cheaper to buy a certificate that's trusted, than it is to explain to lots of people why they're having to do what they're having to do.

[Rob Moir]

Tom, I'd actually agree with that reason for wanting to use a 'trusted' cert. In fact I agree with it 100%. That wasn't how your original comment came across, however.

[hsym]

The bugtracker that we're using support multiple projects, so we don't have to set up multiple bugtrackers on one public IP.

[MadHatter]

I'd assumed that you wanted multiple NameVirtualHosts on a single IP address, hence the desire to support a certificate based on an IP address instead of a hostname. Are you saying that the only reason you want to use an IP-address-based certificate is to avoid publishing a single flaming domain name?

[hsym]

Flaming domain name? My native language is not English, so can you explain that? Also, my boss prefer to use a public IP, maybe he doesn't want the site to be found by search engine (can search engines find the site even though it doesn't have a domain name?)

[MadHatter]

N&D: sorry, that was me letting my frustration show. We've been working on this question for some time, and it turns out that the requirements are improperly understood. Your boss is wrong. Provided your nameservers don't allow zone file transfers by third parties, running your site under a domain name makes it no more likely that a search engine will find you. If he's that worried about confidentiality, make sure the front of the site (the bit you see before login) contains no identifying information, and use a dispsoable or meaningless domain name.

[MadHatter]

If the above comment isn't enough, could you please find out why the use of an IP address instead of a domain name is thought to be desirable? I think I've explained clearly enough why you can't link an SSL certificate to an IP address, so to help more we need to understand what the real problem is.

[MadHatter]

I don't think I understand that, either. A properly-issued SSL certificate is an identifiying token all by itself; the certifying authority doesn't provide any service after the issue. My site is secured on a RapidSSL certificate, but if they went bust tomorrow my certificate would be just as effective as it is now.

[hsym]

Sorry this question has been dragging for so long and you're quite a patient guy to help me with this one. I've just explained to my boss that it should be more proper to use a domain name. I'm thinking of doing something like this: get a domain name (example.com/bugtracker), set the firewall to allow everyone to access example.com while blocking everyone else except the clients' company IP addresses to access example.com/bugtracker.

[MadHatter]

If you have confidence that you can do that with your firewall (since you're not restricting access to an IP service, like TCP port 80, but to some part of an application), and if you're sure that your clients can exhaustively list their IP addresses (this can be harder than you think, if any of them have teleworkers), then that should work! Note that for a domain name you could also use a subdomain of your existing company domain, eg bugtracker.company.com, or to avoid giving anything away in the URL, something unrelated like monet.company.com .

[hsym]

Hey, all it takes is just one client to blow it off. Sorry since I'm not very clear from the beginning. My country doesn't allow its people to do business with Israel. That's all.

[Paul McMillan]

Yes, that would have been a more useful thing to say. SSL certs are needlessly expensive, but on the scale of doing business, the cost is almost nothing.

[Ryan Bolger]

"Once it's issued, it's valid until it expires, full stop". Unless it contains revocation info, gets revoked, and the client enforces revocation checking. And a CA going under would probably be forced to revoke all their certs. Just sayin'

[Hagen von Eitzen]

Notably, " a dedicated server hosted with a web hosting company" will hardly have a RIP enty of its own, but rather the surrounding net will have a RIPE entry (about the hosting company)

[dave_thompson_085]

As of early 2017, StartCom was sold to WoSign who were caught cheating and are now distrusted by major browsers; OTOH LetsEncrypt is gratis (and quite open/transparent, FWTW). See serverfault.com/questions/172560/…