xca icon indicating copy to clipboard operation
xca copied to clipboard
verified publisher icon chris2511

NET::ERR_CERT_INVALID in Browsers on Windows 10 for Certificate Chain exported from XCA

Open rhaley-starfish opened this issue 5 years ago • 5 comments

Hi,

I've attempted to set up a Root CA and a TLS server certificate generated with XCA on a Windows 10 workstation. The certificates were exported and "installed" on Windows Server 2016 instance in Azure. The certificate will primarily be used between IIS and an iOS app, but I need to be able to access the website from any computer.

The following are the steps I took to create the certificates:

  1. Created Root Certificate using default CA template. -> private.root.ca
  2. Created a TLS_Server certificate and signed it using the Root CA. -> dev.client-name.net
  3. Exported Root Cert as PEM (crt)
  4. Exported Server Cert as PKCS#12 (p12)

Next, I "installed" the certificate in the Windows Server Host:

  1. Imported PKCS package into Windows Server (Website host) using certlm (Certificates - Local Machine)

  2. right click Top of Tree (Certificates - Local Computer) -> Find Certificates Contains: private.root.ca Look In Field: Issued By RESULT: Finds 2 certs: Trusted Root Certification Authorities-> Certificates lists private.root.ca Web Hosting -> dev.client-name.net

  3. IIS Setup Sites -> (mywebsite)

    In the Actions pane - Actions: Bindings... Select Bindings for https (port 443) -> Edit

    • Select certificate in SSL Certificates.
    • Restart IIS

After all this was done, I installed the root certificate in my local Windows 10 PC. I was unable to use the website afterwards:

  • Edge - Error Number: 0.
  • Chrome - NET::ERR_CERT_INVALID
    • Error Message from Chrome: "All the intended purposes of this certificate could not be verified".
    • Error Description in Chrome: dev.client-name.net normally uses encryption to protect your information. When Google Chrome tried to connect to dev.client-name.net this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be dev.client-name.net, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
  • LibreSSL (v2.9.0) 
C:\Users\rhaley> openssl s_client -showcerts -connect dev.client-name.net:443
CONNECTED(00000280)
depth=0 C = US, ST = Washington, L = Seattle, O = client-name, OU = Digital Services, CN = dev.client-name.net, emailAddress = [email protected]
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = Washington, L = Seattle, O = client-name, OU = Digital Services, CN = dev.client-name.net, emailAddress = [email protected]
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Washington/L=Seattle/O=client-name/OU=Digital Services/CN=dev.client-name.net/[email protected]   
   i:/C=US/ST=Washington/L=Seattle/O=client-name/OU=Digital Services/CN=private.root.ca/[email protected]
 
 -----BEGIN CERTIFICATE-----
MIIFbDCCA1SgAwIBAgIILqduNarAzDYwDQYJKoZIhvcNAQELBQAwgaMxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdTZWF0dGxlMRAw
DgYDVQQKEwdJbm1lZGl4MRkwFwYDVQQLExBEaWdpdGFsIFNlcnZpY2VzMRgwFgYD
VQQDEw9wcml2YXRlLnJvb3QuY2ExJjAkBgkqhkiG9w0BCQEWF3N0ZXZlbi5kYWx5
QGlubWVkaXguY29tMB4XDTIwMDMxMjE5MDcwMFoXDTIxMDMxMjE5MDcwMFowgaMx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdTZWF0
dGxlMRAwDgYDVQQKEwdJbm1lZGl4MRkwFwYDVQQLExBEaWdpdGFsIFNlcnZpY2Vz
MRgwFgYDVQQDEw9kZXYuaW5tZWRpeC5uZXQxJjAkBgkqhkiG9w0BCQEWF3N0ZXZl
bi5kYWx5QGlubWVkaXguY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAtmMrs1jf7WkS3ZVdYQCqPk8PN1z2i+YUgYVbeo7YPqrNyuGhHtw6ZHF/N3Z9
2umyHvbUiI1BKSymuEepufbVv9a3+GlBnEDO90fpGIZVMh7mqu2TmC9rtTK9h3Q0
PasXSA/U2xCd+IYkD4udVfX/KIzw6yH2B5Fqzwq8TQDN5ku/qcprnM7N12c/qBlQ
N7OKrOcv9YQ1zxz1/8BKy4TCCKD9Wr+vM6vCA9mzLXru9qNOafp41ifjad9YscM2
nMUJtN/XHKLg85HxBrcn8hpbw+yJXAktFyBS9+ClaFCjCYkjD/PJleVVKf5IDZjs
CPg0h/CGQp/6LR3/ISuseCYpbwIDAQABo4GhMIGeMAwGA1UdEwEB/wQCMAAwHQYD
VR0OBBYEFBdff5kVrwy2xyqwQxspUvuMHw/oMAsGA1UdDwQEAwID6DATBgNVHSUE
DDAKBggrBgEFBQcDATAaBgNVHREEEzARgg9kZXYuaW5tZWRpeC5uZXQwEQYJYIZI
AYb4QgEBBAQDAgZAMB4GCWCGSAGG+EIBDQQRFg94Y2EgY2VydGlmaWNhdGUwDQYJ
KoZIhvcNAQELBQADggIBAGvLTxjrR91eRISFuli6lIxKI5Yh+CIYIDC1ZNMzZQgx
oogHV+/LEgvWDpkm7vJPAsZxGUCjpi38PsJ8JnWIEHJ89FFXOCI8ljMAwcmXIVGu
/UjI49uOIg+wzOFCI035OzYun3RIhHVIzFRLwvPOKIGI9AgK/9Pabi1vVqUo8vr3
NE9L3heThMaLKhY+sFVqjLngj10VZyjXJnayzXxW6fAwNrid18+tfMBSu5U/SLZF
PnboiUn/twXGjCmFBgTZ6tmZFnp2STo3U1/cHzL3XcayPMTYEtqeM40lESXp3slf
1Z4COPa28GKse2/3/HPakrqa3xMHwmfrImBWB8+9RQ9FZo+Jh1AF8IUeff+4KblL
NWUK4xW/jLLoABPdTYRWfPTFDlYHwdcaFJnsGBueFdVzwdkVAsF0qvq7V6tUGX+c
L1W7fOvGpWJbu9iTAsYLXeHyb1QB6Flrms5KhQYPF8/CJl70sSBGhn46faq2Tdo0
IbcBEeJbi7NvyDjLip1p6Er6HqJZ3YgbLULIrEESfPbKpeJYRivbHSqMs1fD4god
1TrAuTRWCfCCf79A20qCnQWhKd1DRiqwSvlasv5xuDI1eiWr17tXXbNq6FUNNYP/
HRAx0SsPDJ+kX7KxQu46eJ1w+8Bkl4eD/9tX/uTy7yfc2wsgxaco1Q2U28mXmWrr
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Washington/L=Seattle/O=client-name/OU=Digital Services/CN=dev.client-name.net/[email protected]
issuer=/C=US/ST=Washington/L=Seattle/O=client-name/OU=Digital Services/CN=private.root.ca/[email protected]
---
No client certificate CA names sent
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1908 bytes and written 354 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
	Protocol  : TLSv1.2
	Cipher    : ECDHE-RSA-AES256-GCM-SHA384
	Session-ID: 100400008BA098DC775BD8160D968B1234726C682C3C9202D5CC57ABD5B1556D
	Session-ID-ctx:
	Master-Key: 151432223F764513A9A00F598BB8E50F148676FC4A74E605691A2DBFBCA03C9A507774083B8B2B4633FDD926495FBF57
	Start Time: 1584382665
	Timeout   : 7200 (sec)
	Verify return code: 21 (unable to verify the first certificate)
---

NOTE: I get the same errors when I point libressl at the pem file for the root ca: openssl s_client -showcerts -CApath "E:\client-name\Keys\dev.client-name.net\dev.client-name.net.crt" -connect dev.client-name.net:443

  • iOS/OSX -- safari can view website -> Certificate is valid and works -- Vivaldi -> Can view website ->Certificate is valid and works -- iOS App -> Certificate works.

I recognize this seems to be a windows specific error, but I'm unable to find any further information about what might be causing the problem. I was hoping you might have some insight?

Regards, Russell

rhaley-starfish avatar Mar 17 '20 16:03 rhaley-starfish

After all this was done, I installed the root certificate in my local Windows 10 PC. Looks like installing the root certificate failed. Try uninstalling the root CA cert and look whether it makes any difference. If not, check your way to install the root CA.

https://superuser.com/questions/1315820/how-to-make-chrome-trust-windows-system-root-ca-certificate

chris2511 avatar Mar 18 '20 13:03 chris2511

Thanks for the response. I was told to go buy a certificate, but the upside is there might be a little hint in the GoDaddy instructions for IIS 10. The instructions say to convert from *.crt to a Base-64 encoded *.cer file:

https://ca.godaddy.com/help/manually-install-an-ssl-certificate-on-my-iis-10-server-27349

I'll try this soon...

rhaley-starfish avatar Mar 19 '20 23:03 rhaley-starfish

If you just need ordinary, valid server certificate for a publically reachable server, you may simply use https://letsencrypt.org/

XCA could also assist in converting the certificate to "Base-64 encoded *.cer", which is usually called PEM.

chris2511 avatar Mar 20 '20 07:03 chris2511

If you just need ordinary, valid server certificate for a publically reachable server, you may simply use https://letsencrypt.org/

My tinfoil hat prevents me from using letsencrypt for client projects. I'm probably being irrational but, "there we are".

XCA could also assist in converting the certificate to "Base-64 encoded *.cer", which is usually called PEM.

Thanks, I used to know some of this stuff but it leaked out my ear over the years.

I've tried multiple paths with no luck. Right now I'm just testing from a browser on the server. Steps:

  1. I add the server cert from the p12 file and the system complains of NET::ERR_CERT_AUTHORITY_INVALID. Fair.

  2. Next I add the Root CA cert to the Trusted Root Certificate store. Everything imports correctly and I confirm the cert is in the Trusted Root CA store. I restart IIS, close and re-open the browser (I even restarted the server once!) but I still get the NET::ERR_CERT_INVALID error. I've tried DER and PEM encoding for the root CA.

The message that vivaldi presents is this: "dev.client-name.net normally uses encryption to protect your information. When Vivaldi tried to connect to dev.client-name.net this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be dev.client-name.net, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Vivaldi stopped the connection before any data was exchanged.""

The only clue I haven't followed up is this: When viewing the certificate in Windows, it says that "All the intended purposes of this certificate could not be verified". I don't think that's actually the problem but I've got nothing else. I guess I did manage to mangle the certificate chain somehow...

rhaley-starfish avatar Mar 20 '20 21:03 rhaley-starfish

Had this exact problem.

The issue was that the X509v3 Extended Key usage was not set. So the purpose was All when viewing the trusted cert authorities in Windows.

Selecting TLS client and server auth, Code Signing, E-Mail protection and Time Stamping, on the Extensions page, then redoing the CA cert allowed new certs signed by it to work.

(Note you also have to set the Subject Alternative name in Extensions for Chrome to NOT complain on newly signed certs)

imathrowback avatar Jul 03 '20 02:07 imathrowback