Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 48 replies
  • Subscribers 1 subscriber
  • Views 155358 views
  • Users 0 members are here
Options
Suggested
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

TPok
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.
  • 0
    Thanks for posting this. I am also experiencing this issue. Uploaded the root CAs using the Symantec link and now its a lot better. Hopefully Sophos has a patch for this tomorrow. I imagine there will be a lot of other sites still affected.
  • 0 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
  • 0
    also having this problem with a bank website

  • 0 in reply to ben83
    Strange thing here (running 9.211-3) - when trying to import the pem file (web protection / filtering options / https ca´s / local verifications ca´s / upload it always would say "import of certificate failed".

    UTM running 9.310-11 says: "Import of certificate failed.The X509 certificate with private key object cannot use HTTPS verification CA objects for the issuer certificate attribute." when using verisings pem files.

    This is strange because there is no private key in these pem files ;-) - Now - any idea?

    Best regards,
    Joerg
  • 0
    load up support with tickets...

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to William Warren
    The problem seems to be in the new certdata.ph file.  In the old version, the Verisign Class 3 Public Primary Certification Authority is trusted for codeSigning, emailProtection and serverAuth.  Now it is only trusted for emailProtection.  Here is the diff (I removed the indentation to make it readable): 

    @@ -300,27 +322,12 @@

      'serial' => '70BAE41D10D92934B638CA7B03CCBABF',

      'subject' => 'C=US, O=VeriSign\, Inc., OU=Class 3 Public Primary Certification Authority',

      'trust' => [

    -              'codeSigning',

    -              'emailProtection',

    -              'serverAuth'

    +      'emailProtection'

                 ],

      'file' => 'Verisign_Class_3_Public_Primary_Certification_Authority.pem',

      'startdate' => 'Jan 29 00:00:00 1996 GMT',

      'fingerprint' => '74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2'
  • 0 in reply to Ákos Szalkai
    I inserted the missing serverAuth lines into 
    /var/confd/res/ca/certdata.ph
     (there are a few Verisign certs where it was removed), ran 
    /usr/local/bin/confd-client.plx trigger global_cas
     restarted httpproxy and everything started working again. [:)]

    So I'm going to open a support ticket with this solution included.
  • 0
    Thanks Asok, great!

    Problem on production systems under active support: I think we can´t do this without official OK from sophos - i am pretty sure this would violate their policies. 

    Their hotlines are completely flooded....no coming through at this time.
  • 0
    Hi guys

    Same problems here with version 9.309-3
  • 0 in reply to OliverZumbach
    Same problems here with version 9.309-3


    Yes, because it's independent of the firmware version.  Also happens on V9.2.  The cause of the problem is in the latest cadata pattern update, u2d-cadata-9.40-60.patch.tgz.gpg
Unfiltered HTML