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).

  • 3
    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. Oct 22, 2010 at 20:56

3 Answers 3


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.

  • 4
    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.
    – MadHatter
    Oct 22, 2010 at 10:08
  • 2
    @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.
    – Rob Moir
    Oct 23, 2010 at 7:39
  • 2
    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.
    – MadHatter
    Oct 23, 2010 at 10:16
  • 1
    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.
    – Rob Moir
    Oct 23, 2010 at 11:26
  • 1
    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?)
    – hsym
    Oct 25, 2010 at 2:03

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.

  • 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) Mar 31, 2017 at 10:41

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.


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.

  • 1
    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.
    – MadHatter
    Oct 25, 2010 at 6:21
  • 2
    How many of your clients are going to do a full background check on your SSL provider? They'd really have to dig before they realized that they were doing business with a company that did business with an Israeli company. As MadHatter said, political instability has very little to do with whether or not your cert is valid. Once it's issued, it's valid until it expires, full stop. But it's cool if you want to pay some other registrar ridiculous money for something that's not technically complicated. SSL certs are one of the most ridiculous scams ever. Oct 25, 2010 at 19:11
  • 2
    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.
    – hsym
    Oct 26, 2010 at 0:32
  • 1
    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. Oct 26, 2010 at 7:37
  • 2
    "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' Dec 16, 2015 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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