Geek Answers Handbook

SSL certificates with unknown domain name

We have a problem with securing the intranet / Internet website with SSL, where we cannot know the domain name in advance.

Basically, I am trying to create a program that will be installed on a web server outside of my direct control, for access via the Internet or through the Internet. In any case, I want it to be secure over SSL (https). To do this, I would like to enable and install the SSL certificate on the target machine. My installer is completely unpacked and should not require any specific intervention during or after installation from my end. The problem is that I can’t know in advance the name or domain of the target machine name, since I can say that the SSL connection will return warnings (or worse?) Upon access, since the certificate that I include must (must) have a different one name on it.

I really want to avoid these warnings, but I still want to keep it safe. Is there any way to establish an SSL connection without certificate warnings without a domain name is known ahead of time?

Thanks for any help you can give people.

+4
source share
5 answers

What you want to do is impossible. That's why.

The certificate will contain a set of names (Common Name, possibly together with alternative object names, including wildcard names).

The client web browser will do the following:

  • The user wanted to visit " https://myapp.mydomain.com/blog/posts/1 ".
  • The request is made via SSL, and the domain name in the request is "myapp.mydomain.com".
  • Get a certificate from a web server.
  • Make sure that at least one of the certificate names matches the domain name in the request or matches the wildcard.
  • Display page.

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

You seem to underestimate that somehow the certificate can "create" or "establish" an SSL connection. This is not true. The web server — Apache, IIS, Nginx, LigHTTPD, or whatever you use — is a program that knows how every aspect of an SSL connection is. A certificate is just a file that a web server sends to a client without even opening and using it.

In addition, the author of Webapp, which will be distributed, is not responsible for the creation or distribution of certificates and should not be under the misunderstanding that he is responsible. Only the website owner should be responsible for obtaining the certificate for their website. As another person noted, during the installation process, or perhaps in the process after installation, you can ask the person installing the webapp for the certificate. But this is the best you can do.

+9
source

Each of these sites must have its own SSL certificate. Why not ask the user to provide a certificate file during installation?

+1
source

The best you can do is buy an SSL substitution certificate, but wait, this is not what you think. You still need to know the second level domain (TLD being ".com") ahead of time. You can effectively request a certificate that covers * .foo.com - then any site will be considered, a.foo.com, b.foo.com. Of course, these certificates are more expensive than the FQDN, because you make pederans from any additional coin.

-Oisin

+1
source

In most cases (if not all), the SSL certificate is associated with a web server (apache, IIS, etc.) and is not part of your application. This is for the web server administrator to install the certificate, and not for you as the author of the program.

If your installer has the ability to change the configuration of the web server and you want it to use a self-signed certificate, you can script to create a certificate that allows you to enter a domain name, However, I feel that it is really not available to you. In addition, a self-signed certificate usually triggers certificate warnings.

0
source

If you understood correctly, perhaps now there may be a solution to your problem. However, this solution will not help you if you do not have control over what SSL certificates will be served from the web server on which your program is installed (as mentioned by someone else). If your program itself contains a web server, you will not have this problem.

If you start with a reliable https website, you can do cross-domain TLS (SSL) XmlHttpRequests on the web servers running your application. This has been made possible through the open source Forge project. The project uses a TLS implementation written in JavaScript and a small Flash swf to handle cross-domain requests. Your program will need to support the XML Flash policy file, which provides access to the trusted web site for the web server on which the application is running.

Your program will also need to create a self-signed SSL certificate and upload it to a trusted website. From there, each program certificate can be included as trusted through the JavaScript TLS implementation. In addition, you can force your program to upload your CA signing certificate, which you create using a common or alternative name suitable for your use (this should not be a domain name). You can then use JavaScript to trust the CA certificate and look for the correct name for each certificate.

More on the Forge project on github:

http://github.com/digitalbazaar/forge/blob/master/README

Links to blog posts at the end contain more detailed information on how this works.

0
source

More articles:


All Articles