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.
  • 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
  • This solves the issue. Thank you.
    The certificate can be found here (Root 2):
    Licensing and Use of Root Certificates | Symantec

    I'll leave the Support case open. IMHO Sophos has to fix this.
  • IMHO Sophos has to fix this.


    Indeed. I am not happy to have old 1k Verisign root on trust list in 2015 [:(]

    But to be realistic - implementation of alternate verification algorithm requires two changes:

    [LIST=1]
    • Upgrade OpenSSL to either 1.0.2 or patch OpenSSL 1.0.1 with backported support of "trusted_first".
    • Enable use of "trusted_first" in httpproxy (and maybe it will be useful to do so in other daemons performing SSL/TLS MitM like pop3 proxy).
    [/LIST]

    These changes require a lot of testing, so personally I don't expect this to be done in a few days. Nevertheless, such changes may already be in release plan.
  • These changes require a lot of testing, so personally I don't expect this to be done in a few days. Nevertheless, such changes may already be in release plan
    I would highly recommend every paid license user open up a support case on this, which will increase the fix priority at Sophos.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
  • Opened a ticket yesterday after posting this: 

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/52/t/30040

    I thought it was related to to the update as well.  Will try the solution from Ondrej, thanks for posting it.
  • https://www.sophos.com/en-us/support/knowledgebase/115592.aspx

    Go directly to step 2:


    What to do
    1. Import the certificate  

    Make sure that your new certificate is saved in  PKCS#12 format, and that you have the .p12 file password
    Navigate to Web Security | Filtering Options | HTTPS CAs
    Under Signing CA, click Upload
    Browse to find the certificate file on your system
    enter the password in both password fields. 


    2. Optional: Import a verification CA to the ASG 

    You are using a CA from an external institution that is not listed under Verification CA. On the same Tab you are able to import a Verification CA to the ASG. 
  • Thanks a million for the workaround!  Worked like a charm.
  • Hi Guys,

    Thanks for the workaround.. after importing the 'Root 2' certificate from Symantec sites like Paypal and Amazon are working fine.

    However, i'm still getting certificate errors like the one below for some other sites.

  • Hi Guys,

    Ok managed to fix the issue. I went back to the website Licensing and Use of Root Certificates | Symantec and clicked on each and every 'Test Site' that Symantec has provided to check the Certificate CA..

    Basically, for each test site error you get, upload the corresponding Certificate into the Sophos UTM. That should fix most of your certificate related problems.
  • Hi Guys, me again..

    Today's not going to be a good day for people dealing with these certificate issues i believe.

    Even after checking the Symantec for all test sites, i'm still having issues with this banks website :



    Which certificate do i need for this ? And how do we find out which certificate to match ?