Easylist update fails. Expired Cert

fireodo

@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

costanzo

@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:

As of this morning, the SSL issue still hasn't been resolved:

costanzo

@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

fireodo

@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:

As of this morning, the SSL issue still hasn't been resolved:

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

Thank you for clarification,
fireodo

jimmythedog

@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

drewsaur

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

RubberPike

@jimmythedog Thanks! Good find on that Sophos link.

Derelict

@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.

drewsaur

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}

jsylvia007

@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?

dennis_s

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

costanzo

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

Alanesi

@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.

jimmythedog

@Alanesi I totally agree about backing up the file first

Rico

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

-Rico

jsylvia007

@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.

Rico

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

Vatreni

@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

Old thread but still relevant and found in google. I have an older pfsense install that I can't update for now. The CA file referred to above in mine has dozens of certs now out of date.

I have removed some that had "not after" prior to today, and it let the update of easylist work, so many thanks.

There are plenty to still remove, and while I'm sure the official solution is "update pfsense ffs", is there a place to just download an up-to-date valid ca-root-nss.crt
that will work?

And thanks for your update - v helpful

Gertjan

@Vatreni

Just thinking out loud : what about getting an ISO from 'whatever' open source project ? FreeBSD or Debian etc.
Copy what you find under /etc/ssl/.

edit : forgot about the most obvious one : get the latest pfSense !!!!!
( as you need it even when you don't install it !!)

and get the latest ca-root certs out of it.

Btw: having troubles with expired certs if the top of the ice-berg(problem).