{"id":443,"date":"2018-06-11T18:28:26","date_gmt":"2018-06-11T07:28:26","guid":{"rendered":"http:\/\/scipilot.org\/blog\/?p=443"},"modified":"2018-06-28T19:32:25","modified_gmt":"2018-06-28T08:32:25","slug":"local-development-certificates-done-properly","status":"publish","type":"post","link":"https:\/\/scipilot.org\/blog\/2018\/06\/11\/local-development-certificates-done-properly\/","title":{"rendered":"Local development certificates done properly"},"content":{"rendered":"

Yesterday I finally lost my patience with the developer’s eternal problem of having to skip the untrusted self-signed certificate interstitial warning screens, and so I decided to solve it properly<\/em>. The problem has got worse recently due to a combination of changes in the world and my projects:<\/p>\n

    \n
  1. Containerisation – in Docker containers “localhost” is no longer useful as a service hostname as every service has their own localhost! So I have migrated towards using local host names, .local or .dev patterns etc.<\/li>\n
  2. Chrome has long made special exceptions to “localhost” to allows invalid certificates which ease development pains. This is now lost due to 1).<\/li>\n
  3. Chrome doesn’t resolve .localhost domain extensions which are spoofed in a container’s \/etc\/host file. I recently hit this problem at work, while migrating Selenium tests to Docker. So again we had to migrate our test domains to something.local instead of .localhost.<\/li>\n
  4. Chrome since about v60-ish now requires a subject alternative name (SAN) in a certificate and won’t respect a fallback to a local canonical name.<\/li>\n
  5. Whenever my local Node.js application crashes with an exception, Chrome forgets the fact I’ve whitelisted the certificate. It took me a while to realise this was happening, but I now see it’s 100% correlated. This has led to a gradual fear of crashes (probably a good thing).<\/li>\n<\/ol>\n

    Being RSI conscious and generally lazy, having to click three more things each dev-cycle is a major pain. Also the fact that Browsersync stops working every time too makes it even more work to resume – involving double-clicking the failed GET in the network tab, and accepting the same warning message in a temporary browser window.<\/p>\n

    After reading the Chrome team’s official vision<\/a>, and with my recent experience in setting up a personal CA for a business to allow them to use client-certificates for authenticating remote staff, I decided the best, most permanent solution is to use a personal CA added to the trust root of the local host, which signs the local cert – instead of self-signing.<\/p>\n

    While the process is actually easy to perform, I found as usual the historical complexities of the OpenSSL command line options and configuration files, plus the lack of a single article on this specific approach, meant I had to fiddle around for a while to get it right.<\/p>\n

    Things that made it tricky:<\/p>\n