Easylist update fails. Expired Cert



  • @RonpfS said in Easylist update fails. Expired Cert:

    @revengineer Did you click on the

    Flex: Downgrade the SSL Connection (Not Recommended)

    Thanks for the explanation. Fortunately, a forced reload seems to have fixed the issue now.

    EDIT: Not sure what led be to believe this is fixed. It is not, the issue remains. I understand nothing the pfsense team or package developer can do about.



  • @costanzo I tried emailing and contacting them via twitter about their cert issue.

    Haven't heard back... Does anyone know how to reach them?

    For twitter I used: @AdblockPlus
    For email I used: info@eyeo.com



  • Hi All,
    First time user, so please be gentle with me!

    I think this article describes the problem quite well - especially the Cross-signing section

    So, to fix it, I deleted the old CA from the /usr/local/share/certs/ca-root-nss.crt file (lines 423-512 in my version), as described in the What to do? section in that link above

    HTH



  • @jimmythedog said in Easylist update fails. Expired Cert:

    Hi All,
    First time user, so please be gentle with me!

    I think this article describes the problem quite well - especially the Cross-signing section

    So, to fix it, I deleted the old CA from the /usr/local/share/certs/ca-root-nss.crt file (lines 423-512 in my version), as described in the What to do? section in that link above

    HTH

    I have done what you purpose and I can confirm that it works!

    Thanks,
    fireodo



  • @fireodo Unfortunately, the cert issue can only be addressed by the person who manages the server that houses the EasyList txt files.

    The person who manages their website needs to re-install the certs. Typically there are three files used to install a server cert: private key, signed cert, and CA bundle (contains root and intermediate certificates).

    In the case with EasyList, the CA bundle contains an expired cert.

    As a work around for us netgate users, we can change the source definitions to Flex. This will allow the downloads to continue, ignoring the SSL errors:

    ef210218-8a42-4ffc-9266-4a6c19c89fc7-image.png

    As of this morning, the SSL issue still hasn't been resolved:
    f2972c28-446f-43a5-8032-ac480a08b36c-image.png



  • @costanzo Here's some additional info from the SSL issuer about the problem and what actions are need:

    https://sectigo.com/resource-library/sectigos-addtrust-root-is-soon-to-expire-what-you-need-to-know



  • @costanzo said in Easylist update fails. Expired Cert:

    @fireodo Unfortunately, the cert issue can only be addressed by the person who manages the server that houses the EasyList txt files.

    The person who manages their website needs to re-install the certs. Typically there are three files used to install a server cert: private key, signed cert, and CA bundle (contains root and intermediate certificates).

    In the case with EasyList, the CA bundle contains an expired cert.

    As a work around for us netgate users, we can change the source definitions to Flex. This will allow the downloads to continue, ignoring the SSL errors:

    ef210218-8a42-4ffc-9266-4a6c19c89fc7-image.png

    As of this morning, the SSL issue still hasn't been resolved:
    f2972c28-446f-43a5-8032-ac480a08b36c-image.png

    Thats what I tough too but I thought to give the solution of @jimmythedog a try!

    Thank you for clarification,
    fireodo



  • @costanzo I don't think you're actually correct about the CA cert being issued with the server cert bundle - intermediate certs, yes, but not the CA cert
    The CA cert is usually held in the browser or OS, in their trust stores - that is one of the ways you can trust a cert bundle, because the last intermediate cert in the chain must link to the issuer CA cert in your trust store (there's a clue with the term trust store)

    Now, the problem with the Sectico certs is that the CA cert in the trust store has expired - not the one in the server cert or the intermediate certs
    That is why I deleted the one from the OS trust store, as it is not longer valid and, indeed, should not be used - this needs to be done by the OS package provider too, and I would expect an update to be available fairly soon to get around this problem
    By deleting it, the library will attempt to validate the server cert chain by using the alternative chain, which will end up at the valid Sectico CA cert in the trust store

    Personally, I do not see any risk whatsoever in what I have done, but I do see a potential risk in changing the source definition state to Flex
    I do agree that the site admin needs to install an updated cert, but this fix will get around the problem with no risk (that I can see)

    HTH, and I am willing to be corrected on the above
    Jimmy



  • @jimmythedog This was all very good sleuthing and reporting. Thanks for the tip.



  • @jimmythedog Thanks! Good find on that Sophos link.


  • LAYER 8 Netgate

    @jimmythedog That is both correct and incorrect.

    The problem is that none of the chains presented by the server will end up chaining to the expired AddTrust cert UNLESS that is what is presented by the server. Server administrators SHOULD NOT be including the CA certificates that SHOULD be being pulled from the clients trusted root store in the first place. They should only be pushing as much of the chain as necessary to get the client chained into and pulling from its own trusted CA store.

    Some clients (macOS, Windows) ignore superfluous certificates from the server and use their own store as soon as they have a match up the chain so they continue to validate even when the server admin makes a mistake.

    Some (like OpenSSL in FreeBSD and CentOS at least) try to use what is pushed to them by the server. Those fail.



  • Well, now that I have made the modifications, Arpwatch now sends me these alerts:

    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin>
    X-Cron-Env: <HOME=/root>
    X-Cron-Env: <LOGNAME=root>
    X-Cron-Env: <USER=root>
    
    Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
    34374270280:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3_clnt.c:1269:
    fetch: https://files.pfsense.org/lists/fullbogons-ipv4.txt: Authentication error
    Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
    
    
    {many more of these}
    
    


  • @drewsaur said in Easylist update fails. Expired Cert:

    Well, now that I have made the modifications, Arpwatch now sends me these alerts:

    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin>
    X-Cron-Env: <HOME=/root>
    X-Cron-Env: <LOGNAME=root>
    X-Cron-Env: <USER=root>
    
    Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
    34374270280:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3_clnt.c:1269:
    fetch: https://files.pfsense.org/lists/fullbogons-ipv4.txt: Authentication error
    Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
    
    
    {many more of these}
    
    

    I'm also having this issue too. Looks like there's one more server that needs to be updated on pfSense's side?


  • Netgate

    @jsylvia007 This is something our IT team is aware of and they are working to resolve.



  • @costanzo Quick update: Got a response from @AdblockPlus via twitter. They let their filter team know.



  • @jimmythedog Great, it works for me too. but you have to be careful while doing that I recommend to take a backup of this file before starting this process.

    Steps here if someone wants to follow:

    After you access the file /usr/local/share/certs/ca-root-nss.crt focus on this "Not After : Jan 1 00:00:00 2020 GMT" check the month and year if expired delete from "Certificate:" until "-----END CERTIFICATE-----". In my case, I found two then save and run update.



  • @Alanesi I totally agree about backing up the file first


  • LAYER 8 Rebel Alliance

    Seems like they have fixed their Cert.
    I don't see any errors using the pfBlockerNG default settings for EasyList.

    -Rico



  • @Rico said in Easylist update fails. Expired Cert:

    Seems like they have fixed their Cert.
    I don't see any errors using the pfBlockerNG default settings for EasyList.

    -Rico

    Concur. Same here.


  • LAYER 8 Rebel Alliance

    Fixed between 06/12/20 19:15:00 and 06/12/20 20:15:00 (UTC+1)

    [ EasyList ]			 Downloading update . cURL Error: 60
    SSL certificate problem: certificate has expired Retry in 5 seconds...
    . cURL Error: 60
    SSL certificate problem: certificate has expired Retry in 5 seconds...
    . cURL Error: 60
    SSL certificate problem: certificate has expired Retry in 5 seconds...
    .. unknown http status code | 0
    
     [ DNSBL_EasyList - EasyList ] Download FAIL [ 06/12/20 19:15:28 ]
    
    [ EasyList ]			 Downloading update .. 200 OK.
      ----------------------------------------------------------------------
      Orig.    Unique     # Dups     # White    # TOP1M    Final                
      ----------------------------------------------------------------------
      2491     2452       5          0          0          2447                 
      ----------------------------------------------------------------------
    
    [ EasyPrivacy ]			 Downloading update [ 06/12/20 20:15:17 ] .. 200 OK.
    

    -Rico


Log in to reply