Chrome to force .dev domains to HTTPS via preloaded HSTS

Mattias Geniar, Sunday, September 17, 2017

tl;dr: one of the next versions of Chrome is going to force all domains ending on .dev (and .foo) to be redirected to HTTPs via a preloaded HTTP Strict Transport Security (HSTS) header.

This very interesting commit just landed in Chromium:

Preload HSTS for the .dev gTLD.

This adds the following line to Chromium's preload lists;

{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },

It forces any domain on the .dev gTLD to be HTTPs.

Wait, there's a legit .dev gTLD?

Yes, unfortunately.

It's been bought by Google as one of their 100+ new gTLDs. What do they use it for? No clue. But it's going to cause a fair bit of confusion and pain to webdevelopers.

The .dev gTLD has nameservers and is basically like any other TLD out there, we as developers just happen to have chosen that name as a good placeholder for local development, too, overwriting the public DNS.

$ dig +trace dev. NS
dev.			172800	IN	NS
dev.			172800	IN	NS
dev.			172800	IN	NS
dev.			172800	IN	NS
dev.			172800	IN	NS

Google publishes some of their domains on there, too;

$ dig +trace A		3600	IN	A

So yes, it's a legit TLD.

Consequences of redirecting .dev to HTTPS

A lot of (web) developers use a local .dev TLD for their own development. Either by adding records to their /etc/hosts file or by using a system like Laravel Valet, which runs a dnsmasq service on your system to translate *.dev to

In those cases, if you browse to, you'll be redirect to, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can't dismiss self-signed certificates with HSTS, they need to be 'trusted' by your computer)

Such fun.

What should we do?

With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else.

There's an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have, but site.localhost. And everything at *.localhost would automatically translate to, without /etc/hosts or dnsmasq workarounds.

Alternatively, if you're looking for a quick "search and replace" alternative for existing setups, consider the .test gTLD, which is a reserved name by IETF for testing (or development) purposes.

I do hope the Chromium team reconsiders the preloaded HSTS as it's going to have rather big implications for local webdevelopment.

Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!


Hanno Sunday, September 17, 2017 at 12:03 (permalink)

A few comments from me.

First of all I think this is generally a good move. If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway.

But second I think using local host names should be considered a bad practice anyway, whether it’s reserved names like .test or arbitrary ones like .dev. The reason is that you can’t get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that’s messy and complicated.

Instead best practice IMHO is to have domains like (where is one of your normal domains) and get valid certificates for it. (In the case where you don’t want to expose your local hostnames you can also use and get a wildcard cert for * Although ultimately I’d say you just shouldn’t consider hostnames to be a secret.)


    Weldon Sunday, September 17, 2017 at 15:36 (permalink)

    @Hanno I think it’s silly to pay a CA for a development certificate. Even with the free services it’s silly; there’s literally nothing to be gained by having a third party “verify” your own identity to you. The right solution there is to implement an internal CA (which you should really be doing anyways) and install its signing certificate on your local browsers. Then you can secure anything you want locally, including just IP addresses.


      DevSecOps Jones Sunday, September 17, 2017 at 17:43 (permalink)

      There is no cost to LetsEncrypt certificates, and using these is Development is appropriate.
      The hosts need not be reachable from the internet, you can use DNS records to prove domain ownership.

      I would be recommending use of globally trusted, gratis certificates on dev from LE.
      The certificate issuance process should use different key material for prod,
      but should be configured in the same way.
      Ideally production and development instances of your site should be created using a similar process but with different data sets.


        Fernando Sunday, September 17, 2017 at 18:52 (permalink)

        You dont always want to expose your project names to public DNS or CT logs.
        also, Lets Encrypt API limits are so low , that using it in dev mode, would exhaust it in just 5 deploys.

        a better idea is to use something like hashicorp vault for CA management.


          Anmol Sunday, September 17, 2017 at 21:57 (permalink)

          The API limits are not that low? Just don’t recreate a new certificate every time you launch the app, reuse old ones.


        Weldon Monday, September 18, 2017 at 22:04 (permalink)

        There’s no financial cost to LetsEncrypt, but now you’re adding a trust dependency that you don’t have if you just run your own internal CA for internal PKI. It’s really surprising to me that apparently a lot of companies don’t do this; I had assumed it was universal.


leonixyz Sunday, September 17, 2017 at 12:09 (permalink)

another solution: change browser


    Michal Špaček Tuesday, September 19, 2017 at 19:56 (permalink)

    Which one? The same HSTS preload list is used for Chrome (and Chromium-based browsers), Firefox, IE/Edge, Safari and probably some more. Sooner or later all these will force HTTPS for .dev.


hintss Sunday, September 17, 2017 at 12:24 (permalink)

protip: you can type “badidea” at the https error screen to skip it, avoid using the mouse


    Emil Stahl Wednesday, September 20, 2017 at 00:35 (permalink)

    Yes. But you can’t skip HSTS. That is part of the whole idea 💡


      anon Wednesday, September 20, 2017 at 06:07 (permalink)

      You can, in fact, skip HSTS errors using the ‘badidea’ method in Chrome. Quick way to confirm is , which is an HSTS enabled test page provided by the test service. Clicking ‘Advanced’ gives you the normal text, but typing ‘badidea’ takes you to the page.

      What’s interesting, most of’s test URLs give you an actual webpage explaining why the SSL should or should not have worked. In this case, you just get an nginx error page, suggesting that perhaps even the folks at was not aware Chrome (or anyone else) provided an HSTS bypas.


WhyNoMas Sunday, September 17, 2017 at 18:11 (permalink)

Changing browser and recommending your clients to do so is the way to go. Chrome is now what IE used to be.


Kees Sunday, September 17, 2017 at 19:56 (permalink)

While I agree that this is not desirable, there is a specific TLD made for testing, .test (source:


Mike Schinkel Monday, September 18, 2017 at 04:15 (permalink)

Thanks for pointing this out.

As an aside,’s IP is not routable; see


Ryan Monday, September 18, 2017 at 05:54 (permalink)

Use .test or gtfo.


John McCormack Monday, September 18, 2017 at 12:57 (permalink)

Yeah… I’m using Chrome less and less, using Firefox more and more.


Loïc Lavoie Monday, September 18, 2017 at 19:08 (permalink)

You guys should remove the recommandation for .localhost as an alternative. Chrome and Safari force loopback on the locahost domain and any subdomain in it.

This means that any adresses ending with .localhost will force redirect to without querying DNS’s or your hosts file.


    Guillaume Sunday, September 24, 2017 at 19:11 (permalink)

    +1. I had this problem several month ago, and it’s totally blocking if you are using a virtual machine like Vagrant, with a specific local IP.

    I understand frustration from (not all) people who commented here, but using .dev could prevent you from scaling your project towards a centralized multisite with a variation on TLD. As Hanno said, IMHO best practice seems to be using https://dev.domain.tld for local dev of a live site, http://localhost%5B:PORT%5D/%5Bdomain/%5D or some specific IP redirected locally for a quick project development / code testing.


Zardoz Tuesday, September 19, 2017 at 10:13 (permalink)

1. Drop Chrome, in fact drop evil google generally
2. use with a * cert for testing


Ashley Sheridan Tuesday, September 19, 2017 at 23:08 (permalink)

To be fair, the .dev TLD was made available a long time ago, so any developer using it locally should have expected problems eventually. I hope everyone here has learnt a valuable lesson: never make assumptions about things you don’t have total control over.


vjanzen Wednesday, September 20, 2017 at 21:19 (permalink)

The IP is a name collision entry.


tim Thursday, September 21, 2017 at 00:07 (permalink)

I used use .local then found out about the clash with Bonjour. Then I switched to .server for my local servers (so far so good) and .dev for my local development (oh dear). But fortunately I use a dnsmasq server and can switch it out for something else. I name things as their full production domain plus .dev on the end, and that’s been fine for now. Many of the web apps I work with require a single domain name hard coded into a config file (such is life) so there will be one-time pain of updating those. I would support an official .localhost if it didn’t introduce untold security holes.


Fuck You Thursday, September 21, 2017 at 04:16 (permalink)

f**king stupid google, go f**king eat s**t. We are using .dev for develop domain in our company, and all of a suddent we can’t access our dev sites anymore, WTF. Bulls**t!!!!


Anh Tran Thursday, September 21, 2017 at 04:43 (permalink)

Don’t know what Google is up to, but this is not a smart step. Affecting all the developers in the world with a simple commit. A millions of working hours will be wasted.


ian Hobbs Friday, September 22, 2017 at 00:01 (permalink)

interesting…. I just always used .site domain


Google Stupid Friday, September 22, 2017 at 09:04 (permalink)

Google is evil. If they do that, let’s use


    wut Friday, September 22, 2017 at 15:49 (permalink)

    … Blisk is build on Chromium…


Matthias Monday, September 25, 2017 at 17:07 (permalink)

People. Just use the domain that’s actually reserved for testing. .test. You can, of course, easily get valid certificates for that. They just need to be in the local certificate store. Laravel Valet does that autimatically. Others do, too.


Leave a Reply

Your email address will not be published. Required fields are marked *