The burdens of SSL certificate maintenance to a website admin are, I’m guessing here, universal. Even after the process of acquiring one is complete, the installation and configuration can be somewhat daunting. And if this were a one-time deal, it’s be far more tolerable, but as the certificates regularly expire, it’s a constant hassle. So I’ve bounced between certificate authorities as my own circumstances, as well as those of the industry, have changed.
I began this site with with a company called StartSSL. At the time, I found them efficient, affordable (as in–free), and with an easy to use website. My user ID was assigned via browser certificate (as opposed to the username/password method), and on their dashboard I could mint on-demand website and email certificates with standard WHOIS-based domain name validation.
But when I went to renew one day, I found the site to no longer be functioning properly. The basic operations to which I was accustomed had vanished, and my attempts at minting new certificates resulted in incompatible file types. I searched for info, but as the service was free, it was hard to come by. Further research revealed that they had been acquired, and shortly thereafter made the tech news for their new parent company’s bad security practices (and secret acquisition). Ultimately, they got themselves blacklisted by browser vendors and once my certificates expired, I would not be able to use StartSSL as a CA.
By this time, however, the EFF’s certificate project had launched and was gaining traction. The service, Let’s Encrypt, boasted hassle-free and automatic domain-validated SSL certificates. The best part was that my server’s manufacturer released an update which integrated the process into their stock software. With just a few selections, I could request a certificate, then be issued one with no further input on my part to install it. And even better, the service would reissue automatically prior to the certificate’s expiration (which was limited to 90 days, but that’s not a bother when they reissue on their own). I made the switch.
Then I received an email. The domain validation system used (a variant of the HTTP file-based verification method–more on this in a bit), was being sunsetted due to security vulnerabilities. I checked with my server manufacturer’s forums, but couldn’t find any information on how to change the default verification method. So with 30 days of lead time, I looked into finding a new certificate issuer.
I would have thought that because of the EFF’s efforts, certificates would have become very affordable. And they are, but you have to dig, because the majority of advertised products are intended for business and/or ecommerce use. Securing a certificate for a personal non-business home-based server proved to be somewhat trying, but I did eventually find such a line of products: COMODO’s PositiveSSL certificates.
These certificates are domain-validated only, meaning to acquire one you only have to prove you control the domain. This is the only type I’ve ever used, as their application is rather low-risk, this being a blog. Their price point is due to the ability to automate the process, and while it offers the same level of encryption as any industry-standard certificate, it’s a very basic level of authentication. Here’s Wikipedia’s explanation (https://en.wikipedia.org/wiki/Domain-validated_certificate):
“The sole criterion for a domain validated certificate is proof of control over whois records, DNS records file, email or web hosting account of a domain. Typically control over a domain is determined using one of the following:[3]
- Response to email sent to the email contact in the domain’s whois details
- Response to email sent to a well-known administrative contact in the domain, e.g. (admin@, postmaster@, etc.)
- Publishing a DNS TXT record
- Publishing a nonce provided by an automated certificate issuing system
A domain validated certificate is distinct from an Extended Validation Certificate in that this is the only requirement for issuing the certificate. In particular, domain validated certificates do not assure that any particular legal entity is connected to the certificate, even if the domain name may imply a particular legal entity controls the domain.”
But alas, with COMODO, this was my first encounter with a certificate-signing request. With StartSSL, the service generated the public/private key and installed it into my browser, which then required me to export the file and import it into my server. I’m assuming that’s okay, but it is placing a lot of trust in the certificate issuer, as in theory they’d have/had access to the private key. A certificate-signing request, on the other hand, eliminates that security hole.
The process is as follows: the server creates a certificate/private key pair, wherein the certificate is signed by the private key (standard procedure). The certificate is then exported, which in turn is uploaded to the CA. After validation, the CA then signs the certificate with their own certificate’s private key (the intermediate certificate), and then provides that now-signed certificate alongside the signing intermediate certificate. Both are uploaded to the server, along with the original private key. The three files now supply encryption and identity validation (via the certificate chain path through the intermediate certificate).
It sounds complicated, but from the user end it’s mostly automatic. The burden lies in the validation process.
As stated above, domain validation is merely the process of confirming that the requestor actually controls the domain to which they’re requesting a signed certificate. And, as Wikipedia explained above, COMODO chose to do this in one of 3 ways:
- The CA queries the requestor’s domain WHOIS record–the ICANN-required information supplied along with the original domain registration. Specifically, the registered email address. The problem for me was that, because of the amount of spam email I received as a result of keeping that information public, I had to purchase a WHOIS-masking service that prevented my registered email address from being visible. As a result, the CA had no way to query my email, and therefore no email by which to contact me.
- This led me to method 2: the CA generates an ASCII nonce and tells me to paste it into a text file in the /.well-known directory. This directory is, in theory, only write-accessible to the server’s admin, and is also publicly visible. Logic follows that I, the admin of the server to which the domain name is pointed, would not be able to make this file unless I had full control of both the domain and the server (which I do). I created the file and was in turn sent a link to download the now-signed certificate. (Note: the /.well-known is not a mountable directory by default. This required me to save a file directly to the directory via the server’s integrated text editor, although I’m sure a more advanced user could perform a simple SSH command).
- Had this second method not worked, the third method of verification involves creating a TXT record with my domain registrar. It is, more or less, the equivalent of option #2, but at the domain registrar’s level instead of the server’s. Being able to add any domain record here proves de facto that the individual controls the domain. Fortunately, I didn’t have to go quite this far, but it’s nice to know the option is available in the event of server/network problems.
Uploading the certificate files was pretty straightforward after that, and a quick setting change switched it over. I’ve kept my Let’s Encrypt certificate just to see what will happen with the renewal, but if that fails and it expires, I’ll still be good now with a 2-year COMODO one. Hopefully when renewal time comes up for that, I’ll have this article available to remind me how I did it. And…if anyone else besides myself ever discovers this article and finds it useful, that’s cool too.
–Simon