An SSL certificate is a means to bind a cryptographic key to company’s details. When used properly, it ensures web customers that the site they are visiting does, in fact, belong to you. SSL certificates also helps to enable secure http (HTTPS) on your website, thereby securing transactions of various sorts. For most businesses, these SSL certificates are purchased from companies like Verisign, Symantec, and Network Solutions. Such SSL certificates can be had for as little $37.99/year (from SSLCertificate). Once you’ve purchased your certificate for your domain (one per), you then save the certificate in the correct location (based on your web server software) and make your web server aware of the newly placed certificate. One of the biggest frustrations with paying for an SSL certificate is that they expire; when they do, it can be a real pain to renew them on your server (depending on the server software platform).
Purchasing an SSL certificate isn’t the only means of acquiring such a file. For those not in the know, there is always the self-signed certificate. What is this? Simply put, the self-signed SSL certificate is created in house, by using tools like openssl. These self-signed certificates are great for certain purposes and not so great for others.
Recently I ran into an issue when attempting to set up a private Docker repository. In order to set up a private repository, Docker depends upon SSL certificates. Naturally, seeing as how the repository was going to be private, I assumed a self-signed certificate would work just fine. So I opened up a terminal window on the server to house the registry and created self-signed certificates. The Docker registry refused to accept the certificates. In the end, the only way to connect to the docker registry was to use a certificate issued by a Certificate Authority. This came as quite the surprise to me. I was using open source software, to create a private service, and so I assumed it would be possible. After all, I can easily use that same self-signed certificate in Apache and get HTTPS working like a champ.
However, even when doing that, the biggest issue with self-signed certificates rears its ugly head. What is that issue? Trust. When using self-signed certificates to enable HTTPS on your web server, any user visiting that site will have to okay and exception in their browser. Why is this? Because the browser doesn’t fully trust the certificate. Why? Because the browser (and the user for that matter) has no way of knowing if that certificate was, in fact, issued by you.
Man in the middle
This is where a man-in-the-middle attack comes in. Say, for instance, you run a business that sells soap and your business is doing really well. You sell your soapy products online and have enabled HTTPS on your server to protect your customers (and you). But one day something strange happens and you find orders of your soapy products have stopped or you start getting complaints about data theft. What could have happened is that someone has placed themselves (and their own server) in between you and your customers. That nefarious ne’er do well has (most likely) created a self-signed SSL certificate with your information to try and trick users into thinking their server is your server.
That’s the big danger of self-signed certificates — that anyone can create one with anyone’s information. Don’t panic; it’s not like you have to include your social security number in your certificates. In fact, for a self-signed certificate, the only information you have to include is:
- State
- City
- Company name
- Department
- Your name
- Email address
- Password
If you were so inclined, you could create a self-signed certificate for any company, filling in the above information. And as far as email address and password are concerned, you could use any email address (it doesn’t even have to belong to the domain associated with the company) and the password is only unique to that certificate (so you create it as you create the certificate).
The answer
With all of that said, when is it okay to make use of self-signed certificates? The answer is quite simple on the surface; underneath is a different story. The simple part is this: self-signed certificates are good to go for testing purposes and for internal LAN-only services. Both of those instances, however, can only be brought to fruition if the server software will accept a self-signed certificate. The good news is that self-signed certificates are free to create, so you would only be out a bit of time if it turns out your server software will not function with a self-signed certificate.
The next layer to the caveat cake is a bit more challenging. If you opt to go the self-signed route for your internal servers, you must ensure your issuing certificate authority server is secure — really secure. Not only does the CA server need to be secured from nefarious network traffic, you need to make sure it is housed in a location that doesn’t lend access to just anyone. You do not want to allow every employee access to that CA server. Why? If your CA root certificate were to find its way into the hands of the wrong people, things could go downhill quickly for those internal LAN-only services.
As to public-facing servers? I would never suggest using self-signed certificates. Why? Even if you go about your day-to-day business and never suffer an attack of any sorts, in today’s world you must put forth a very trustworthy front. Because there is so much competition out there, the slightest security misstep could be catastrophic to your company. To that end, it very much behooves you to pay the piper for a trusted SSL certificate.
Is there a better solution?
I’ve always held on to the idea that there could be a better, more secure, solution for this. Say, for example, you had the option to make a one-time purchase of a cryptographic key, one that would be forever locked to your company. That key could then be used to create whatever certificates you needed. Any SSL certificate (or ssh encryption key, or whatever your need) created with that particular cryptographic key would be considered trusted. You pay one time for a key that will serve all your needs (even serve subdomains). You could even make available the public portion of that key so anyone who wants to be absolutely certain any site claiming to be you is actually you. Of course, that solution has problems as well. First and foremost, it would require a possible retooling of the SSL (and other) subsystems to allow for the creation of certificates based on an external cryptographic key. Second, it would require the education of those making use of such a system. Administrators would have to learn the ropes of creating new SSL keys based on a purchased cryptographic key. Finally, that purchased cryptographic key would have to be well-secured (otherwise, should it get out into the public, all bets are off).
What do you think? Is there a better solution than the one we currently use? And where do you feel self-signed certificates can be trusted?
