No access to *.dev sites

I’ve been having an odd issue for a couple of months. When accessing sites having a .dev domain (like most recently go.dev), I my browsers have given me warnings and as many had HSTS-headers, not allowed me to visit the site.

It seemed like a strange error, and I’ve tried to remember if I’ve set up some proxy or VPN connection, that could cause this issue. A few times I’ve asked others on the net if they had issues – which was not the case – and I’ve tried using a web proxy, and everything worked. Yet no matter which browser I used it didn’t work.

I did try to see if it might be a DNS issue (in the local /etc/hosts file) or anywhere else, but no luck.

Today the issue was finally solved. Examing the certificate by clicking the “Not secure” in the address bar, the certificate turned out to be a anything.dev certificate (as in “*.dev”), and that eventually provided the clue I needed.

Apparently at some point – long before the dot dev (.dev) domain existed as an actual valid domain namespace, I setup *.dev as a local development namespace – and created a self-signed certificate to allow HTTPS-based development environment for my local domains.

I had long since removed the /etc/hosts entry which sent all *.dev names to localhost but wasn’t aware for the self-signed certificate and it lingered on for years. As most modern sites now use HSTS headers, this caused an issue and I was finally able to identify the issue, launch “keychain access” on my iMac and delete the self-signed certificate which was used for all *.dev sites.

Using (Google) Calendar for domains

Here’s a little trick, which is has proven itself just as useful as it is easy. To most companies handling domains is critical task, as losing your domain name may have catastrophic consequences. Handling domains isn’t particularly hard, but there are some tasks, that may be time-critical to handle in due time – luckily Google Calendar provides an easy way to help make sure these tasks are handled.

(In this little tip, I’m using Google Calendar as the reference, but Outlook.com, Office365 or any other online calendaring system can probably do the same.)

Setup a new Google Calendar on an existing Google Account and call it “domains”.

Whenever a domain name is bought or renewed, make a new entry in the calendar at the expire time of the expiry date of the domain. Note the domain name in the subject of the calendar, and if you buy domains at various registrars note any details needed (but not confidential) in the description field.

Next step is to remove the default pop-up notification and add email notifications instead. Choose which warning horizons you’d like – i.e. 1 month, 1 week and 48 hours – and Google will let you know when the renewal is coming up.

Final step is to invite any other who needs to be notified of the domain expiry to the appointment, and make sure, that they notifications is also set up with the warning horizons they like.

… also applicable of certificates

The calendar notifications can also be utilized for SSL / TLS certificates. When buying or renewing certificates make an entry on their expiry date and set up notifications as described above. This way you should be able to ensure your users never see an expired certificate again.