![I-Firefox logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
Intranet site no longer works with Mozilla Firefox
We have an intranet site behind an Active Directory Federation Services (AD FS) - after updating the SSL certificate, the website will no longer allow Firefox clients to log in.
They will be prompted to sign in (with a default sign in prompt, not even the website login prompt), even if you enter the correct user/password it will continue to prompt you. The new cert works with Edge, Safari, and Chrome - I've enabled the following settings in about:Config network.automatic-ntlm-auth.trusted-uris, network.negotiate-auth.delegation-uris, network.negotiate-auth.trusted-uris, and set signon.autologin.proxy to be true - but the issue still persists.
Has anyone seen this/been able to figure this out? I've seen a few other posts, but no resolutions. Does Firefox not support Certificate Signature Algorithm SHA-384 With RSA Encryption? This is the only difference I can see between the 2 certificates; the original is SHA-256 With RSA Encryption.
Thank you!
All Replies (8)
Is it basic authentication prompt, as on attached screenshot?
You can open the about:config page and filter for sha384 to see which cipher suites are supported.
@TyDraniu - Yes, that is the authentication prompt we are seeing, but only when using Windows Authentication - other types of authentication seem to work fine with Firefox.
@cor-el - Thank you, it looks like all the settings in about:config with sha384 are set to "true".
This is not about prefs being true, but about the cipher suites supported by Firefox. If you website server only supports cipher suites that Firefox doesn't support then there is a problem.
You can check your browser.
You can check the server.
@cor-el - Thank you for your notes on that, if Firefox in general wasn't working with the new certificate I would think this applies to my situation. But it seems to only be causing issues when using Windows authentication methods. Thank you for answering though!
You have entered the site's host name in the value for the various "trusted-uris" preferences? As an example of the format, imagine 3 servers:
network.automatic-ntlm-auth.trusted-uris => intranet,accounting.company.local,10.10.50.50
@jscher2000 - Thank you for your response! Yes, I have all .domain.local and added the IP address as well just to make sure and it is still generating a generic authentication box with failed logon events on the AD FS server.
@pauliexnay good day. We are seeing the same behavior after updating to a SHA384 Certificate. In testing setting ExtendedProtectionTokenCheck to NO instead of Allow on the ADFS server leads to login working with Windows Firefox. Of course, that is not a recommended setting for a Production ADFS implementation.
Returning to a SHA256 certificate resolves the issue. And it only affects Windows Firefox client.