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.

kontur
  • 528
  • 1
  • 4
  • 13
  • 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 '18 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. –  Mar 14 '18 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 '18 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. –  Mar 14 '18 at 14:20
  • `.dev` is a (somewhat) new gTLD owned by Google. See my other comment below and https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ – Patrick Mevzek Mar 15 '18 at 03:19
  • 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 '19 at 20:16

5 Answers5

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.

Kelderic
  • 343
  • 1
  • 12
  • 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 '18 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 '18 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 '18 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. – Kelderic Mar 15 '18 at 13:39
  • 1
    A solution like this: https://security.stackexchange.com/a/154176 at least impact only one site, not all of them. – Patrick Mevzek Mar 15 '18 at 13:45
  • `.dev` is a wrong name, this is not something to debate over, just a fact. You should not just invent a name and hope there will be no collision. They will happen. So bad choice from the beginning, sorry. Typical choice does not make it good choice by default. And if you are against it then just maintain a local authoritative server for `.dev`. Which is again a wrong solution anyway but obviously I will stop arguing there as it is not fruitful since you do not understand the core problem you have. – Patrick Mevzek Mar 15 '18 at 13:47
  • "We've been just fine without it for the past 20 years," since HSTS is about enabling HTTPS by default to protect against downgrades and cookie hijacking, you are just saying that you are fine without HTTPS hence TLS since the past 20 years. I am scared to hear that from a developer. Anyway... – Patrick Mevzek Mar 15 '18 at 13:50
  • 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 '18 at 14:43
  • A collision is a collision is a collision. Yesterday, today, and tomorrow. Not understanding that the DNS is global and hence you should not just hijack a name you think no one else will use is a fatal flaw. An interesting shortcut maybe at the beginning to think starting faster, but obviously it bites you at some later point, as you have just discovered. So, as condescending as it may seem: next time in your professional career try to avoid doing explicit collisions. It will be good for you and for the Internet globally. – Patrick Mevzek Mar 15 '18 at 14:47
  • I think @AndyMercer is not alone in using .dev for local development. I just rolled back my FF to version 58, because I simply cannot be bothered right now to change all my local dev sites. –  Mar 15 '18 at 16:29
  • @Pieter the fact that a certain number of people make an error does not it convert automatically to a good practice... `.dev` exists since many years now, at some point people should start to notice: It is only with the changes on HSTS that people got impacted. It is unfortunate that such bad choice has been made indeed. Incindently this also shows that all examples on line and posts here should make sure to use names as referenced in RFC2606 as those are guaranteed to not create collisions in the future. **Any** other name can collide in the future, ICANN **will** open new gTLDs... – Patrick Mevzek Mar 16 '18 at 00:21
  • @PatrickMevzek > all examples on line and posts here should make sure to use names as referenced in RFC2606 as those are guaranteed to not create collisions in the future. That doesn't leave too much room to play with .test, .example, .invalid and .localhost I guess we will have to get more creative and do something like .localdev, which **might** be opened by ICANN, but hopefully that will be in the distant future :) –  Mar 16 '18 at 02:01
  • @Pieter please read my comment above: register any domain name in any TLD you wish and then you have for life (or for the duration you pay for it) a way to do any kind of internal naming you wish, because you have **secured** a name by registering it globally, instead of just choosing one arbitrarily and hoping that noone else will do the same... The names in the RFC will never be opened by ICANN. – Patrick Mevzek Mar 16 '18 at 02:14
  • 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 '18 at 20:30
  • Thanks for the answer. It might work but the negative implications of this solution seem to outweigh the positive. – kontur Mar 20 '18 at 14:35
  • No might about it. It Does work. As to the security concerns, it depends on your work flow and situation, which is why I say to read through these comments. – Kelderic Mar 20 '18 at 14:37
  • Whoah, the SSL certification mafia is getting elaborated. Thanks for the workaround. – cvsguimaraes Mar 30 '19 at 02:21
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.

kontur
  • 528
  • 1
  • 4
  • 13
  • 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 '18 at 03:18
  • 2
    See https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/ – Patrick Mevzek Mar 15 '18 at 03: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 '18 at 08: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 05 '22 at 01: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.

MarianD
  • 2,666
  • 1
  • 17
  • 26
Sean Aitken
  • 241
  • 2
  • 4
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.
Noam Manos
  • 1,804
  • 1
  • 20
  • 20
-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.

Gerard H. Pille
  • 1,346
  • 1
  • 8
  • 8
  • 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 '18 at 11:44
  • Yeah that doesn't work for people who are doing local development. – Kelderic Mar 15 '18 at 12:16
  • the question is about LOCAL DEV –  Mar 15 '18 at 16:24
  • @Pieter is that the same as "local development"? Because that is what we do. – Gerard H. Pille Mar 15 '18 at 19:59
  • @GerardH.Pille yes it of course is. Do tell please. –  Mar 15 '18 at 20:53
  • 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 '18 at 14:33
  • This perhaps? https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html Use your production URL with a prefix like "test-", "dev-". – Gerard H. Pille Mar 20 '18 at 22:03