Because I don’t follow security advisories religiously, & check my site certs only when I think I need to (i.e. a little time before they expire), I missed the near unanimous decision to distrust StartCom as a Certificate Authority. Instead, I found out by attempting to show a friend my evolution simulator. My recently updated Android Firefox browser showed me a certificate warning despite the fact that my cert should have been good until 2020. Aiiee! Since I was at the 2017 Bosch Hackathon, I was a little busy to do anything about it until later. What a keen site maintainer I am (not).
Referring to my earlier experiences on this topic, I see that Eric Mill is a much better man than I, and has already been advising people against using StartCom certs since last year.
I chose to use Let’s Encrypt to generate my new certs. My hosting provider, 34sp.com, provides integrated Let’s Encrypt support, but this would not cover all the subdomains I wanted out of the box. I also do not have direct ssh access to my box, opting for a cheaper shared server. Instead, I installed certbot,
|
|
$ sudo apt-get install certbot -t jessie-backports |
and used it to request a cert including all my subdomains.
|
|
$ sudo certbot certonly --manual --preferred-challenges dns -d robwilliamson.com -d www.robwilliamson.com -d blog.robwilliamson.com <and extra subdomains> --config-dir ./config --logs-dir ./logs --work-dir ./work |
Because certbot needs to verify my ownership of each subdomain, & some subdomains I wanted a cert for don’t have a server behind them, I used DNS TXT entries.
DNS TXT entries don’t update immediately, so I used MXToolBox’s outstanding DNS text lookup tool. This meant I could tell certbot to verify my DNS TXT for a given domain only after that value had been successfully published.
In the future, I should be able to renew this cert by simply running:
All that was left was a simple matter of uploading the cert using the site management tools & I’m your uncle, or something. Please don’t call me Bob.
Addendum
This part is likely only of interest to me.
The DNS TXT entries confuse subnet resolution. Prefixing them prevents this confusion, but I’m sure there must be a better way to do this. I’ll have to remember to remove the prefix the next time I want to update my cert.
A better way to do this
As I mentioned, there has to be a better way to do this. My DNS records contains an asterisk (*) term for the base hostname. Adding an explicit subdomain name, like _acme-challenge.blog, means that the “blog” part of that subdomain becomes explicit. There’s no explicit definition of the address of blog, so the DNS behaviour is to return unresolved. I solved this by explicitly pointing blog to my server address. This at least means that I don’t have to do anything silly, like breaking my DNS for every subdomain next time I want to renew my cert.
A better better way to do this
Instead of adding an address resolution record, I can add a canonical name record (CNAME) for blog, resolving to the root domain, which can then be resolved to the server address.
This is better because it’s easier for me or others to update the server address then. Hooray. Probably anyone who knew anything about DNS could have figured this out way quicker than I have. Hey-ho. It works.
Like this:
Like Loading...
