This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

unable to get local issuer certificate for a lot of sites after update to 9.310

Hi,

I did the update to 9.310 last weekend and now I am facing a "unable to get local issuer certificate" error for a lot of https sites. This could be relatet to the update or not. I am not sure but those sites were working a few days ago.

Some examples for non working sites:
https://www.ing-diba.de/ - Issuer: /C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3
https://www.amazon.de/ - Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
https://www.adobe.com/ - Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3

Some other sites like eBay are working so maybe thsi is related to the Issuning CA. As far as I can see those are present on the UTM.

Can anybody confirm there is an issue or not.
I will open a support case, too.

Thanks.

This thread was automatically locked due to age.

Parents

0 ondrej.holas over 9 years ago
Same here. This is unrelated to particular UTM version. The problem seems to be caused by changes in SSL/TLS listener configurations somewhere at Akamai made yesterday - now they send "extra certificate" in chain to be verifiable by both direct root CA and cross-certified root CA.

Certificate chain
0 s:/jurisdictionC=US/jurisdictionST=California/businessCategory=Private Organization/serialNumber=C0806592/C=US/postalCode=95014/ST=California/L=Cupertino/street=1 Infinite Loop/O=Apple Inc./OU=Internet Services for Akamai/CN=support.apple.com
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

However, since UTM uses OpenSSL engine 1.0.1 that lacks "trusted first" mode, as a workaround you must import "Class 3 Public Primary Certification Authority" into HTTPS scanning trusted CA list. The certificate exists in two versions with following SHA1 thumbprints:

74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2 (self-signed by md2RSA)
a1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b (self-signed by sha1RSA)

If you don't have this cert, you can find it already present in Trusted root CAs store on most Windows machines, in Firefox, on Linux in /etc/ssl/certs or download it directly from Verisign (now Symantec), link is in TPok's post below.

OpenSSL traditionally (without "trusted first") uses verification algorithm that tries to validate whole received certificate chain. With "trusted first", the verification algorithm searches local trust store for every chain level (similarly to Crypto API in Windows).

-trusted_first

    Use certificates in CA file or CA directory before certificates
    in untrusted file when building the trust chain to verify
    certificates. This is mainly useful in environments with Bridge CA
    or Cross-Certified CAs.

Source: www.openssl.org/.../verify.html

Regards,

Ondrej
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 ondrej.holas over 9 years ago
Same here. This is unrelated to particular UTM version. The problem seems to be caused by changes in SSL/TLS listener configurations somewhere at Akamai made yesterday - now they send "extra certificate" in chain to be verifiable by both direct root CA and cross-certified root CA.

Certificate chain
0 s:/jurisdictionC=US/jurisdictionST=California/businessCategory=Private Organization/serialNumber=C0806592/C=US/postalCode=95014/ST=California/L=Cupertino/street=1 Infinite Loop/O=Apple Inc./OU=Internet Services for Akamai/CN=support.apple.com
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

However, since UTM uses OpenSSL engine 1.0.1 that lacks "trusted first" mode, as a workaround you must import "Class 3 Public Primary Certification Authority" into HTTPS scanning trusted CA list. The certificate exists in two versions with following SHA1 thumbprints:

74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2 (self-signed by md2RSA)
a1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b (self-signed by sha1RSA)

If you don't have this cert, you can find it already present in Trusted root CAs store on most Windows machines, in Firefox, on Linux in /etc/ssl/certs or download it directly from Verisign (now Symantec), link is in TPok's post below.

OpenSSL traditionally (without "trusted first") uses verification algorithm that tries to validate whole received certificate chain. With "trusted first", the verification algorithm searches local trust store for every chain level (similarly to Crypto API in Windows).

-trusted_first

    Use certificates in CA file or CA directory before certificates
    in untrusted file when building the trust chain to verify
    certificates. This is mainly useful in environments with Bridge CA
    or Cross-Certified CAs.

Source: www.openssl.org/.../verify.html

Regards,

Ondrej
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data