Chrome and Firefox cannot load site on HTTPS, Firefox throws PR_CONNECT_RESET_ERROR, but Internet Explorer and Edge can
I read related posts on this "PR_CONNECT_RESET_ERROR" error such as https://support.mozilla.org/en-US/questions/1281840 and followed their suggestions without luck.
-Not using DoH -Tried new profile, new FF installation, load site over HTTPS from multiple locations -No AV on workstation
I have a web app hosted on Azure Government which was recently patched on 03/02/2020 with FEB 2020 Windows OS patches and all of a sudden FF (and Chrome, Safari and Opera) cannot load the site over HTTPS, but they can over HTTP. Interestingly, IE and Edge can load the site on HTTP and HTTPS without issues.
Curl and OpenSSL can "load" the site over HTTPS with no issues.
Azure support mentioned the issue is on FF (and Chrome, Safari and Opera), so I'm here looking for assistance.
I used Browserling to test FF (and Chrome, Safari and Opera) with different versions including the latest version and get the same result, cannot load the HTTPS site.
When loading the site over HTTPS, but using the IP address instead of the hostname, FF throws a warning "SSL_ERROR_BAD_CERT_DOMAIN" as expected. After accepting risk and continue, FF throws PR_CONNECT_RESET_ERROR.
I do believe the issue is on the Azure web app, so I run Qualys SSL Server Test against the web app, see links below for the report images (cannot upload the PDF file), can you review and point out if there is any encryption ciphers supported by the server, but not supported by FF, so I can follow up with Azure on this?
Your assistance is greatly appreciated.
https://pasteboard.co/IYUtIt1.png https://pasteboard.co/IYUtVqS.png https://pasteboard.co/IYUDhvt.png https://pasteboard.co/IYUDrGw.png https://pasteboard.co/IYUDAH3.png
All Replies (3)
PR_CONNECT_RESET_ERROR generally indicates a RST from the server or a server/router/proxy along the way during the connection setup, but I think it also could indicate a RST sent for other reasons.
The SSLLabs test shows their Firefox and Chrome installations (or simulated installations) can connect, so that is promising.
Are you able to test from a different computer and/or a different network in case those are factors? Or perhaps that is what the Browserling test tells us.
Are you aware of any redirects after the initial connection?
Coincidentally, we had another report with this error where HTTP can connect but HTTPS cannot, but in that case Chrome can connect: https://support.mozilla.org/questions/1281840
Are you able to test from a different computer and/or a different network in case those are factors? Or perhaps that is what the Browserling test tells us.
Tested from different computers/locations. Plus, our client was the one who reported this issue, they are geographically distant from us. Browserling tests along with our own local (office/home) tests indicate the same behavior/issue.
Are you aware of any redirects after the initial connection?
No, under the Network tab, I only see a GET request with headers below, I removed the Host entry, but I can share the URL via email for further testing if needed.
Host: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1
Coincidentally, we had another report with this error where HTTP can connect but HTTPS cannot, but in that case Chrome can connect: https://support.mozilla.org/questions/1281840
Yes, I reviewed https://support.mozilla.org/en-US/questions/1281840, followed their suggestions, but no luck.
Please let me know if you need any additional information and/or any further testing I can run on my side.
I appreciate your prompt response on this.
If you have a tolerance for tedious detail, you could look at logs of connection setup to see whether they are unusual compared with successful connections.
https://developer.mozilla.org/docs/Mozilla/Debugging/HTTP_logging
Perhaps an external tool might be better for that?