SSL certificates with unknown domain name

Question

We're having an issue with securing an intranet / internet website with SSL where we can't know the qualified domain name in advance.

Basically, I'm trying to make a program that will be installed on a webserver outside my direct control, to be accessable over intra- or internet. In either case I want it to be secure via SSL (https). To do this, I would like to include and install a SSL certificate on the target machine. My installer is fully prepackaged and should not require any particular during- or postinstall intervention from my end. Problem is, I can't know ahead of time the target machine's name or domain name, so as far as I can tell the SSL connection will be returning warnings (or worse?) when accessed, since the certificate I include will (must) have a different name on it.

I really want to avoid those warnings, but I still want to keep it secure. Is there any way to install a SSL connection without certificate warnings without the domain name known ahead of time?

Thanks for any help you folks can give.

Answer 1

What you want to do is not possible. Here's why.

A certificate will include a set of names (Common Name, possibly along with Subject Alternative Names, possibly including wildcard names).

The client's web browser will do the following:

1. The user wanted to visit "https://myapp.mydomain.com/blog/posts/1".
2. The request is via SSL and the domain name in the request is "myapp.mydomain.com".
3. Get the certificate from the Web server.
4. Ensure that at least one of the names in the certificate is exactly equal to, or wildcard-matches, the domain name in the request.
5. Display the page.

Therefore, you need a certificate with the exact domain name (or a wildcard matching the exact domain name) by which the application will be used. And the certificate needs to be available at the same time as, or later than, the time when the exact domain name of the website becomes known, and cannot be made available any earlier.

You seem to be under the misapprehension that somehow a certificate can "create" or "install" an SSL connection. That is false. The Web server - Apache, IIS, Nginx, LigHTTPD, or whichever one you happen to use - is the program that knows how to every aspect of SSL connectivity. The certificate is just a file that the Web server sends to the client, without even opening or using in any way.

Additionally, the author of a webapp to be distributed is not responsible for creating or distributing certificates, and should not be under the misapprehension that he is responsible. Only the website maintainer should be responsible for obtaining a certificate for his website. As another person remarked, in your installation process or perhaps in a post-installation process, you may ask the person installing the webapp for a certificate. But that is the best you can do.

Answer 2

The best you can do is to buy a wildcard SSL certificate - but wait, it's not what you think. You still need to know the second-level domain (the TLD being ".com") ahead of time. You can effectively ask for a cert that covers *.foo.com - then any site, a.foo.com, b.foo.com will be covered. Of course, these certs are more expensive that FQDN certs because you are doing the buggers out of some extra coin.

-Oisin