Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 48 replies
  • Subscribers 1 subscriber
  • Views 155371 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.
Parents Reply Children
  • 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 in reply to Ákos Szalkai
    ...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....


    It seems that such change is intentional. Browser vendors also reduce root trust by removing old root certificates with weak keys. Personally I completely support this intention.

    The errorneous behavior introduced by such trust change is different story (OpenSSL's verification algorithm) and shows insufficient testing before patterns release. Especially in this case, where many frequently visited sites send cross-certified chains and end up with certificate verification failure.

    Nevertheless: Two important things about workarounds with manual import:
    [LIST=1]
    • Importing certificate into UTM's trust list extends trust. By importing fake root certificate, you open possibility for bad guys to perform MitM attacks. So, you should get that root certificate from trustworthy source and doublecheck it (fingerprint) before importing to UTM.
    • After Sophos fixes this issue, recheck UTM's trust list and remove manually added old roots. They are still valid and their short RSA keys are challenge for brute-force crackers.
    [/LIST]
Unfiltered HTML