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 10 years ago

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.
Cancel
Vote Up 0 Vote Down

Cancel
0 ondrej.holas over 10 years ago in reply to jazzoberoi
In my previous post I mentioned recent configuration change of SSL/TLS listeners at Akamai. Although certificate chains they send look differently compared to about half a year ago, the trigger of this issue seems to be in Up2date (did you know that UTM's built-in list of trusted CAs is part of Up2date patterns?):

$ cat /var/log/up2date.log | grep "package=\"cadata\""
2015:04:28-20:02:22 utm audld[7587]: id="3707" severity="info" sys="system" sub="up2date" name="Successfully synchronized fileset" status="success" action="download" package="cadata"
2015:04:28-20:04:20 utm auisys[7663]: id="371Z" severity="info" sys="system" sub="up2date" name="Successfully installed Up2Date package" status="success" action="install" package_version="9.60" package="cadata"

Probably Sophos decided to remove old root certificates with weak keys and/or weak signatures. Combined with OpenSSL's default verification algorithm and certificate chains including cross-certified root CAs, the cause is now clear to me.

Regards,

Ondrej
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 ondrej.holas over 10 years ago in reply to jazzoberoi
In my previous post I mentioned recent configuration change of SSL/TLS listeners at Akamai. Although certificate chains they send look differently compared to about half a year ago, the trigger of this issue seems to be in Up2date (did you know that UTM's built-in list of trusted CAs is part of Up2date patterns?):

$ cat /var/log/up2date.log | grep "package=\"cadata\""
2015:04:28-20:02:22 utm audld[7587]: id="3707" severity="info" sys="system" sub="up2date" name="Successfully synchronized fileset" status="success" action="download" package="cadata"
2015:04:28-20:04:20 utm auisys[7663]: id="371Z" severity="info" sys="system" sub="up2date" name="Successfully installed Up2Date package" status="success" action="install" package_version="9.60" package="cadata"

Probably Sophos decided to remove old root certificates with weak keys and/or weak signatures. Combined with OpenSSL's default verification algorithm and certificate chains including cross-certified root CAs, the cause is now clear to me.

Regards,

Ondrej
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data