Self-signed SSL cert works in IE & curl but no modern browsers

Question

I'm experiencing a somewhat perplexing issue with a self-signed SSL certificate that Windows recognizes as valid, but which no modern browsers will accept.

The certificate is present in the system certificate store (accessed via the Certificates snap-in in MMC), within both the Personal and Trusted Root Certification Authorities folders, and marked as valid.

Per the utility SSL Certificate Verifier, the certificate and certificate chain are valid.

Here is its output:

**************************************************************************
Processing 'localhost'
**************************************************************************
Scan started: 21-09-2020 13:43:33
Generating connection string...
Connection string is: https://localhost:14006/
Entering certificate validation callback function...
Server returned 1 certificates.
Entering server certificate chain validation function...
Leaf certificate issued to: E=REDACTED, CN=localhost, O=localhost, L=New York, S=NY, C=US
Found Subject Alternative Names extension in the certificate.
Fetching SAN values:
DNS Name=localhost
DNS Name=127.0.0.1
DNS Name=::1
IP Address=0000:0000:0000:0000:0000:0000:0000:0001
IP Address=127.0.0.1

Certificate chain successfully passed all checks.
Finished!
Scan ended: 21-09-2020 13:43:33

If I attempt to access the service using Internet Explorer or curl, I get the expected 200 result from the service.

However, if I try to access the service using Edge, Chrome, Opera, or Firefox, I get ERR_CONNECTION_RESET. Before adding the certificate to Firefox's certificate store, I got PR_CONNECT_RESET_ERROR but now that also throws ERR_CONNECTION_RESET.

There are no proxies or VPNs active on my system or anything else that would interfere with Windows' networking. I'm at a complete loss. What on earth is happening here and how do I go about fixing it?

Answer 1

I had exactly the same symptoms - IE and curl working. Chrome, Edge and Firefox not, all reporting ERR_CONNECTION_RESET.

Ultimately it was pinned down to a corrupt HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions key.

nmap reported a single cipher in use when it was broken:

| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A

Reloaded the key with a correct value:

| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A

The absence of the GCM ciphers is the likely cause, given Chromium was reporting them as obsolete five years ago.

Answer 2

I had a similar problem on chrome where it said

NET::ERR_CERT_COMMON_NAME_INVALID

, turns out the error was with the certificate itself.

Try the to create a certificate with the below link: SSL Certificate