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 jazzoberoi over 9 years ago

hi Guys,

even after following the work around.. some banking websites usign the Symantec Certs still don't work..

Certs Installed:

Sophos Error on website - https://ib.nab.com.au/nabib/index.jsp
Cancel
Vote Up 0 Vote Down

Cancel
0 ondrej.holas over 9 years ago in reply to jazzoberoi
hi Guys,

even after following the work around.. some banking websites usign the Symantec Certs still don't work..

This is slightly different problem caused by SSL/TLS configuration at the bank side. They indeed send complete chain up to and including both cross-certified new root (blue) and self-signed old root (red):

$ echo Q | openssl s_client -connect ib.nab.com.au:443 2> /dev/null | grep -E "^[ 0-9]{3}[is]:"
0 s:/1.3.6.1.4.1.311.60.2.1.3=AU/businessCategory=Private Organization/serialNumber=004 044 937/C=AU/postalCode=3008/ST=Victoria/L=DOCKLANDS/street=L 3 800 Bourke St/O=National Australia Bank Limited/CN=ib.nab.com.au
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL SGC CA - G2
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL SGC CA - G2
   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
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Strictly speaking, there's no reason to include self-signed root certificate in chain, since the party that verifies the certificate (client or in this case UTM's HTTPS scanning proxy):

already trusts any certificate in the chain (uncommon case, but not rare) - verification finishes successfully before self-signed root certificate becomes interesting in verification (also see my notes on OpenSSL's default verification algorithm, compared to "trusted_first")
trusts only self-signed root certificate (most cases) - verification finishes successfully based on party's local knowledge of self-signed root certificate
trusts neither any certificate in the chain nor self-signed root certificate - verification fails since there's no way to build certificate chain up to locally trusted entity

Since the old root certificate in this case exists in two versions with different signature algorithms (see my post here https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/57149-unable-get-local-issuer-certificate-lot-sites-after-update-9-310-a.html#post295032), binary/fingerprint comparison fails if the server-supplied version of the root certificate differs from the one you trust.

The server ib.nab.com.au:443 sends chain that includes old root certificate with SHA1 fingerprint:

74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2

In "Local verification CAs" click on the blue "i" left to the certificate name and you'll see fingerprint. Also note that yesterday Up2date pattern included cadata package that reverts changes introduced two days before and again includes both versions of Verisign's old root CA, so the site ib.nab.com.au should be trusted.

Rgds,

Ondrej
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 ondrej.holas over 9 years ago in reply to jazzoberoi
hi Guys,

even after following the work around.. some banking websites usign the Symantec Certs still don't work..

This is slightly different problem caused by SSL/TLS configuration at the bank side. They indeed send complete chain up to and including both cross-certified new root (blue) and self-signed old root (red):

$ echo Q | openssl s_client -connect ib.nab.com.au:443 2> /dev/null | grep -E "^[ 0-9]{3}[is]:"
0 s:/1.3.6.1.4.1.311.60.2.1.3=AU/businessCategory=Private Organization/serialNumber=004 044 937/C=AU/postalCode=3008/ST=Victoria/L=DOCKLANDS/street=L 3 800 Bourke St/O=National Australia Bank Limited/CN=ib.nab.com.au
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL SGC CA - G2
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL SGC CA - G2
   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
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Strictly speaking, there's no reason to include self-signed root certificate in chain, since the party that verifies the certificate (client or in this case UTM's HTTPS scanning proxy):

already trusts any certificate in the chain (uncommon case, but not rare) - verification finishes successfully before self-signed root certificate becomes interesting in verification (also see my notes on OpenSSL's default verification algorithm, compared to "trusted_first")
trusts only self-signed root certificate (most cases) - verification finishes successfully based on party's local knowledge of self-signed root certificate
trusts neither any certificate in the chain nor self-signed root certificate - verification fails since there's no way to build certificate chain up to locally trusted entity

Since the old root certificate in this case exists in two versions with different signature algorithms (see my post here https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/57149-unable-get-local-issuer-certificate-lot-sites-after-update-9-310-a.html#post295032), binary/fingerprint comparison fails if the server-supplied version of the root certificate differs from the one you trust.

The server ib.nab.com.au:443 sends chain that includes old root certificate with SHA1 fingerprint:

74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2

In "Local verification CAs" click on the blue "i" left to the certificate name and you'll see fingerprint. Also note that yesterday Up2date pattern included cadata package that reverts changes introduced two days before and again includes both versions of Verisign's old root CA, so the site ib.nab.com.au should be trusted.

Rgds,

Ondrej
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data