NET::ERR_CERT_AUTHORITY_INVALID – Fix Self-Signed CA in Windows

certificate-authorityhttpsopensslssl-certificatewindows

I created a (self-signed) root certificate and signed a web server certificate using a system I developed in Java (the web certificate is used in Apache 2.4.41).

The certificates work without issues in Linux and Mac (tested in different Webkit browsers and Firefox). The certificate and the server setup scores A+ using testssl.sh.

The CA certificate is correctly installed without any warning, but not accepted (still showing the red-triangle warning and the NET::ERR_CERT_AUTHORITY_INVALID error) in Windows (tested with 2 Windows 10 devices, one which is a fresh install). Tested in Chrome, Edge and Firefox.

I have tried many things:

installing them using certlm.msc, certutil.exe, through settings or by double-clicking the files
either Local or User scope
regenerating the root certificate with different settings
changing Apache settings
restarting browsers and the computers
stopping antivirus software

I have read related questions in this site (none seems to fix it) and I have look into other websites for solutions, but without success.

This is a fake CA certificate generated by the same system (with the same settings, except the key length here is 1024 to reduce the size of this post):

Key and Certificate:

CA Summary

Version: 3
         SerialNumber: 6873848332899071428
             IssuerDN: CN=Fake Authority,C=US,ST=CA,L=LA,O=Example LTD,OU=None,[email protected]
           Start Date: Thu Nov 11 06:06:53 JST 2021
           Final Date: Fri Nov 11 00:00:00 JST 2022
            SubjectDN: CN=Fake Authority,C=US,ST=CA,L=LA,O=Example LTD,OU=None,[email protected]
           Public Key: RSA Public Key [b8:07:ef:1f:8e:91:c0:ab:12:db:38:3f:76:e7:0a:7f:21:9d:fe:49],[56:66:d1:a4]
        modulus: 983fc7e042334c460e2682a9ce61fbcdf0ae367f1d5c5a67b1872bb83fb1c6b87ef175290b800eac7e8837de8713696798428e602c8018169086dc13431dfc2eacad24564b8fc47a800f4601492b693948d0b42f54082340ca734c52ef2f4246a7283c5594b7b9dc51ebb04591a60cc61b362a9c6a68230967e720f441ee4815
public exponent: 10001

  Signature Algorithm: SHA256WITHRSA
            Signature: 610d8fbef7d049ef56b46ea9789e01e766c6d4cc
                       ec53e8c4f71738a1611fbde924a633a467875b93
                       cf6005578066c4b175f7dc41f14fc91284f6fb9b
                       62b77dc6e7a6500184e7567232a25631ac05471b
                       57755d5ee9ad4e4c7d6a2a4b3ad686f0b51b9104
                       ec1ea145b82ab3928022c1dd58665ca55e609895
                       869bc90b1ce2fcc2
       Extensions: 
                       critical(true) BasicConstraints: isCa(true)
                       critical(true) KeyUsage: 0x6
                       critical(false) 2.5.29.14 value = DER

Server Certificate

Cert Summary

Version: 3
         SerialNumber: 6648705147606043571
             IssuerDN: CN=Fake Authority,C=US,ST=CA,L=LA,O=Example LTD,OU=None,[email protected]
           Start Date: Thu Nov 11 06:08:37 JST 2021
           Final Date: Fri Nov 11 00:00:00 JST 2022
            SubjectDN: CN=fake.example.com,C=US,ST=CA,L=LA,O=Example LTD,OU=None,[email protected]
           Public Key: RSA Public Key [2e:cd:8e:16:02:6f:b3:27:16:01:21:cb:1a:2b:9b:27:18:71:86:87],[56:66:d1:a4]
        modulus: 8cccc3f04931d04dac6eaed7e71455572d79c33a4a251b68ae0381fb2a43eb8b3676e2f968142537e77c2c4f661527dca4230f98e7cbd7a84c3c42396138731131eb5679a10c1f9eb6ba16a46fc4be280ad037b49987dbf0ed317b3b0882220fec59c95ef3b8fd1134a736d6783341cc43eb3e00e5f48c32c35805b4f305e4d215c038732f69aaa70b736823de3f8e842812572d682a5486ba2f92698322b247b9fa6552d31d26baa4ce1ad47f328792c95304b7931c01c780d757e392636226d996a558deb2e7b3d3480c8375f7d722027269a9296fa7ae5230b254305169da458ad3f4bc8274e8e354237063013584782a21803e664fce3691405c3d1bc99d
public exponent: 10001

  Signature Algorithm: SHA256WITHRSA
            Signature: 88dd18b477a5ba113a2145a18a2d2a87e520dfff
                       f8340bdb76ae9da8c7ca68063b803253c7b519fa
                       6df302eb122cab39e30d86529e2d9810c7fa6012
                       e2be299ba3dad80b5f04fc8e6ee4ab2abc86becd
                       ee5565de54ecef3ee3ef1469ff91fd17b881d7fb
                       789de3d3688fe1df3029ebdf51f0fc55cb9d771f
                       66ad6aa5b8211929
       Extensions: 
                       critical(true) BasicConstraints: isCa(false)
                       critical(false) 2.5.29.35 value = Sequence
    Tagged [0] IMPLICIT 
        DER Octet String[20] 

                       critical(true) KeyUsage: 0xa8
                       critical(false) 2.5.29.17 value = Sequence
    Tagged [1] IMPLICIT 
        DER Octet String[16] 
    Tagged [2] IMPLICIT 
        DER Octet String[16] 
    Tagged [2] IMPLICIT 
        DER Octet String[20] 

                       critical(false) 2.5.29.14 value = DER

What is wrong with my setup?

Best Answer

There are two issues with the certificates posted in the question:

Both certificates are using one shared key. As a certificate should bind a key to its owner (Subject) it really doesn't make sense to use one key for two subjects.
As a consequence of the above, the Subject Key Identifier and Authority Key Identifier hashes are the same across both certificates.

Note that you also have a rather complex Authority Key Identifier in the end-entity certificate. It is usual to just have the hash in here, copied directly from the Subject Key Identifier of the issuing CA's certificate. That is, leave out the Directory and Serial entries. What you have may work, but why risk it?

SNI-Hole

You've fallen into a SNI hole.

SNI is server name indication. This allows you have multiple different hostnames living on the same shared IP. And if you don't actually indicate a servername to a SNI enabled server, then you get back the default certificate. (This is the "SNI hole" part.)

And OpenSSL will not supply a servername to the TLS server unless you tell it to. Use the -servername parameter for that.

$ echo '' | openssl s_client -showcerts -connect www.unival-logistics.com:443  -servername www.unival-logistics.com 2>/dev/null | grep -Ei 'subject|issuer|return'
subject=/C=US/OU=Domain Control Validated/CN=www.unival-logistics.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - SHA256 - G2
    Verify return code: 20 (unable to get local issuer certificate)

If you leave that out, then you get the default certificate for that host. And here that is a self-signed certificate. (And I don't think it should be there either. Makes no sense to deliver a self-signed cert.)

 $ echo '' | openssl s_client -showcerts -connect www.unival-logistics.com:443  2>/dev/null | grep -Ei 'subject|issuer|return'
 subject=/O=americanfuturegate.com/CN=*.americanfuturegate.com/emailAddress=REDACTED1@example.com
 issuer=/O=americanfuturegate.com/CN=*.americanfuturegate.com/emailAddress=REDACTED1@example.com
     Verify return code: 18 (self signed certificate)

Check that installation

Side note: I urge you to disable SSL3. (SSL Labs report here.)

Key and Certificate:

CA Summary

Server Certificate

Cert Summary

Best Answer

Related Solutions

Windows – How to find what process is holding a file open in Windows

Ssl certificate self signed instead of valid

SNI-Hole

Check that installation

Related Topic