26

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.

Improve this question
6
  • 1
    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, 2018 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, 2018 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, 2018 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, 2018 at 14:20
  • 2
    @SimonGreenwood There's plenty of reasons to not use let's encrypt on a local connection. One would be not wanting to set up let's encrpyt.
    – Jon
    Sep 20, 2019 at 20:16

5 Answers 5

Reset to default
20

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

Edit 2020: We've now had a .dev TLD for multiple years. It's time to move away from using .dev as a local URL. This workaround still works, but you are robbing yourself of increased security.

Improve this answer
17
  • 6
    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, 2018 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.
    – Kelderic
    Mar 15, 2018 at 13:27
  • 1
    A solution like this: security.stackexchange.com/a/154176 at least impact only one site, not all of them.
    – Patrick Mevzek
    Mar 15, 2018 at 13:45
  • 1
    As condescending as I know this is going to sound, as you get older, you'll realize that things like "best practice" and "wrong" are flexible and change over time. What people consider to be "wrong" right now, wasn't considered wrong for many years, and may not be again in the future. As to this specific discussion, we'll just have to agree to disagree.
    – Kelderic
    Mar 15, 2018 at 14:43
  • 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, 2018 at 20:30
16

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.

Improve this answer
4
  • 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, 2018 at 3:18
  • 2
    See ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts
    – Patrick Mevzek
    Mar 15, 2018 at 3:20
  • 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, 2018 at 8:50
  • It kind of makes sense for a brand new public-internet TLD managed by Google. Browser vendors are pushing to require SSL and there's no excuse for a brand new domains not to support it.
    – Alex Jasmin
    Apr 5, 2022 at 1:29
14

Setting security.enterprise_roots.enabled to true on the about:config page solved this for me and allowed my self-signed certificate to work during development.

There's a bit of discussion around the merits of this being on by default here:
Set security.enterprise_roots.enabled to true by default.

Although the intent of this flag is to allow Firefox to use the machine-wide CA root store as a valid source for certificate authorities, this fixed the situation for my own use case where I have a self-signed multi-domain certificate that I use locally for testing (subjectAltName's). Even after I added the cert to the Firefox certificate list, it wasn't until I turned this on that it allowed the local site to load.

Improve this answer
0
0

Had the same problem on basilisk Web Browser. I tried to change Network Proxy settings, or to modify "network.stricttransportsecurity.preloadlist" or "security.enterprise_roots.enabled" flags... but it did not resolve the missing button to add certificate for the blocked web-site. Only this made it through:

  1. Go to about:support.
  2. Click Open Directory of your Browser profile.
  3. Close Browser completely.
  4. Edit file " SiteSecurityServiceState.txt " in the above directory.
  5. Find and remove the entire line which contain the blocked HSTS site.
  6. Save the file, and reopen your Browser on that site.
Improve this answer
-3

I went for "Let's Encrypt"

https://letsencrypt.org/

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.

Improve this answer
7
  • 6
    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, 2018 at 11:44
  • Yeah that doesn't work for people who are doing local development.
    – Kelderic
    Mar 15, 2018 at 12:16
  • the question is about LOCAL DEV
    – user276684
    Mar 15, 2018 at 16:24
  • @Pieter is that the same as "local development"? Because that is what we do.
    – Gerard H. Pille
    Mar 15, 2018 at 19:59
  • 1
    @GerardH.Pille You can only generate Let's encrypt certificates if the server is accessible from the internet. For my local development, this is not the case, so it's not viable. Please advise if there is something I am missing.
    – kontur
    Mar 20, 2018 at 14:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .