On my local Apache environment I have a site that requires SSL for development, so I have been using a self signed certificate. The local site has worked fine in Firefox and Chrome until now, but after updating Firefox to version 59 today I can't get it to accept the security exception (on Chrome the self signed certificate continues to work).

Firefox gives me this additional info in the blocked page:

... uses an invalid security certificate. The certificate is not trusted because it is self-signed. Error code: SEC_ERROR_UNKNOWN_ISSUER

There is no option to allow the exception here as there used to be, but I went to the Firefox Preferences under Certificates, then in the "Server" tab I've added an exception for the local domain. The certificate is then listed in the correct local server name, details show my certificate settings of Issued by and Issued to being the same, with a valid timespan.

Anybody experiencing similar problems with FF 59 or might have a clue what to try to get the self signed certificate working again locally?

Edit: I don't see any mention of this in the FF 59 release notes but something in the new version causes all my local virtual hosts on *.dev domains to automatically try to establish a https connection (that is to say, all http requests for *.dev get automatically sent to the https URL). Maybe something about this behavior is also what is causing these problems for my actual https virtual hosts.

migrated from serverfault.com Mar 14 at 15:15

This question came from our site for system and network administrators.

  • My guess is that you now need a CA for a self-signed certificate because Firefox have been tightening requirements gradually over the last few releases. However, with Let's Encrypt there's no reason to use self-signed certificates any more. – Simon Greenwood Mar 14 at 11:21
  • I don't want to guess but I think @SimonGreenwood is right. But usually Firefox just sets the new options as default and allows you to edit the settings. Check your privacy settings. – Broco Mar 14 at 12:59
  • @Broco If anything it is in security settings, not privacy settings. As stated above, I have even added a Security Exception, but Firefox still insists on not being able to validate the certificate, because obviously the issuer is unknown. – kontur Mar 14 at 13:43
  • @kontur for me the link is about:preferences#privacy to set both privacy and security settings, that's why I said privacy. Consider posting it as a bug. – Broco Mar 14 at 14:20
  • .dev is a (somewhat) new gTLD owned by Google. See my other comment below and ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts – Patrick Mevzek Mar 15 at 3:19
up vote 9 down vote accepted

I still am not entirely clear on how this all fits together exactly, but as pointed out in this answer .dev domains are now official TLDs. As such, it seems that browsers force some kind of HSTS behavior and force https connections. For those TLDs it seems my self-signed certificate no longer was accepted in Firefox. Changing my virtual hosts to use .test solved the problem without having to change anything in my self-signed certificates at all.

It is worth noting that in Firefox also my non-SSL virtual hosts acted up since version 59 today, because the HSTS behavior seemed to force SSL on virtual hosts I had not set up as serving via SSL. On Chrome this still used to work, but either way it's safe to say moving away from the now officially used .dev TLD will resolve many headaches.

  • 1
    Yes, .dev is a valid TLD since some time so do NOT use it to name your internal resources. Same for any other name: do not use any name that you think noone else will use. Either use test names referenced in RFC2606 or just register a true domain name anywhere and use a subdomain like int.example.com or dev.example.com to suffix all your internal names. You will then never have collisions or problems (as long as your remember to renew the domain name each year!) – Patrick Mevzek Mar 15 at 3:18
  • 2
  • 1
    Thanks for the link. The timelines mentioned there don't quite line up, but maybe the author talked about development previews or the like. Given what I know now it is really hard to see why browser vendors wouldn't add some additional debugging info, in particular with regard to SSL error on .dev domains. Unless you know it's a TLD there is no chance you will infer this is the problem. – kontur Mar 15 at 8:50

There is an easy way around this.

  1. Go to about:config
  2. Search for "network.stricttransportsecurity.preloadlist".
  3. Set it to false.

WARNING: This will disable HSTS entirely. Take a look at the comments on this answer for some discussion about the downsides of this method. I personally think the benefit outweighs the risk, but you are responsible for your own security.

enter image description here

  • 1
    This is a very bad idea as this setting will apply to all websites you visit not just your own. You are lowering your security. – Patrick Mevzek Mar 15 at 13:03
  • I disagree. HSTS is relatively new. We've been just fine without it for the past 20 years, so saying that disabling it is very bad for security is exaggerated. Secondly, even if it IS a bad idea, there isn't really any other option if I want my development servers to continue working, that don't involve really lengthy changes to my development environment. – Andy Mercer Mar 15 at 13:27
  • So with the same reasoning we should not use anything invented in the last 20 years? That is just bogus argument. RFC on HSTS is 6 years ago. You are on purpose disabling security measures, which is never a good idea. The error is using wrong names, you should instead invest energy in solving this problem as it is the real one. Otherwise it will bite you again plus disabiling security settings will open you to other attacks. – Patrick Mevzek Mar 15 at 13:31
  • First, nothing I said implies that we shouldn't use things invented in the past 20 years. Second, .dev for a local environment isn't a "wrong name". It has been a typical practice for a LONG time. Only recently has .dev been added as a TLD. I'm not going to change my setup because ICANN decided to go for a money grab. – Andy Mercer Mar 15 at 13:39
  • 1
    Thanks for this fix, works great for me in Firefox 59.0.1 (and Firefox Dev Edition 60). Our current .dev projects will eventually be moved to another TLD suffix, but for now this helps not halt local development. – Jake Bathman Mar 19 at 20:30

I went for "Let's Encrypt"


Only valid for 3 months at a time, but the refresh can be automated.

As you can see in the remarks, there is a catch. Our development and test domains are called dev-www.example.com and test-www.example.com. We use the wildcard certificate from production.

  • 2
    Doesn't Let's encrypt rely on the server and domain being publicly available? I'm looking for options to use SSL on local virtual hosts. – kontur Mar 14 at 11:44
  • Yeah that doesn't work for people who are doing local development. – Andy Mercer Mar 15 at 12:16
  • the question is about LOCAL DEV – George Mar 15 at 16:24
  • @Pieter is that the same as "local development"? Because that is what we do. – Gerard H. Pille Mar 15 at 19:59
  • @GerardH.Pille yes it of course is. Do tell please. – George Mar 15 at 20:53

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.