Frequently, users ask about how to enable SSL on IIS and run it “for free” without doing any extra work. Since there is no such thing as a free lunch, I am going to try and explain why and what your options are for “free SSL”.
I would like to setup SSL for a public web site we have for our IT users (Admins and Engineers only). I do not want to have to buy SSL certs from a company and I PREFER NOT to deploy a PKI / Cert Server.
What is my next viable and easy solution for a FREE SSL Cert solution with the above requirements?
The solution depends on the number of IT users and whether you control all computers that run browsers against your public SSL-enabled website.
All SSL solutions for web servers require at least:
- A Root Certificate Authority certificate
- A Server Certificate signed by the Root CA. This is installed on the web server
- Client which trusts the Root CA of #2
If you do not have all elements (especially #3), then you can expect web browsers to pop up a security warning dialog about not trusting the server’s certificate.
Now, anyone can create their own Root CA certificate and create/sign a Server certificate with this Root CA. MS Cert Server, SelfSSL, OpenSSL, etc all allow you to do this because it is easy. In fact, from a security/trust perspective, generating identifiers like certificates and even signing identifiers are not difficult.
The major problem is establishing trust between unrelated clients and servers, and public key certificates use a third trusted party, the Root CA, to establish mutual trust. It is the establishment of this mutual trust that costs you money – it has nothing to do with IIS, Microsoft, or income – and if you can establish that mutual trust for lower cost, go right ahead because nothing stops you.
The SSL Conspiracy Theory…
Now, you may be wondering: “why is this guy talking about establishing mutual trust between unrelated client and servers and requiring money for it. All I want is SSL data encryption, period, between two network endpoints and I could care less about trust or identity of the endpoints. This must be some evil Microsoft conspiracy/plot to generate income for the Certificate Registrars, blah blah blah…”
Well, I am sorry, there is no such conspiracy plot. The SSL handshake is completely open and publicly defined by competent folks, and all the popular web servers and web browsers implement it. If you want to complain, go complain to the spec authors. We are just the messengers here. 🙂
Thus, the reason that paying for a Certificate for SSL usage is easy is because those Registrars all have their Root CA Certificate pre-loaded into the trusted root store of most OSes. All you need to do is install a signed certificate from them and you are set.
Part of the reason that you deploy PKI/Cert Server is to ensure that YOUR private Root CA Certificate gets installed on all clients and servers so that all you need to do is install a signed certificate from it and you are set.
Thus, if you do not want to pay nor do you want to deploy an infrastructure, you will have to figure out some way to securely distribute the Root CA Certificate used to sign all your other certificates to the trusted root store of all your servers and client computers that browse to your public SSL website. There are no other alternatives – this is how the SSL Solution works, and this is how you implement a free SSL Solution.
Clearly, the ease of this deployment depends vastly on the number of client/server machines and the amount of control you have over configuration of their trusted root store.
Also, notice that the issue of “Free SSL on IIS” actually has NOTHING to do with IIS. It is trivial to run SelfSSL to enable SSL on IIS. The issue of “SSL on IIS” usually originates from the IIS sysadmin, even though the actual deployment problem comes from the lack of mutual trust by the browser clients.
Usually, you are the sysadmin and have control over the servers, so the problem is really about controlling the number of clients. If you are in a university/corporation setting or some other sort of controlled environment, the IT department should have control of the clients to force install this Root CA Certificate… but at this point, realize that you are a hop-skip away from PKI. If you have NO control over the clients, then purchasing a SSL certification is pretty much the ONLY cost effective solution, unless you can think of a simple, secure, and non-infrastructure way to install Root CA Certificate onto uncontrolled client machines.
In other words, there is no free lunch. There is no free unfettered SSL solution for a large number of uncontrolled clients.
If the number of clients are small, or if the clients are controlled… then you can have free SSL. For example, I do this at home with SelfSSL to secure OWA access to my personal email because I control the server and the laptops/computers that will access my OWA (I do NOT believe in secure kiosks).
Some of you may remember the tremendous inconvenience and security popups caused by the Verisign fiasco in January 2004 when one of Verisign’s intermediate Root certificate expired. This instantly invalidated all server certificates in use that were signed by it, causing all browsers world-wide to popup security warnings when encountering such a server certificate. Basically, the amount of effort expended by Verisign customers around the world to re-issue signed Server Certificates with a valid Verisign Root certificate is a reasonable “upper-bound” to your effort, depending on the number of uncontrolled clients.