Easylist update fails. Expired Cert

revengineer

@RonpfS said in Easylist update fails. Expired Cert:

You could change the State of the URL to Flex until the cert issue is fixed.

Could you explain what a switch from ON to FLEX does? I could not find documentation on this. Thank you.

revengineer

I am puzzled. When I go to https://easylist-downloads.adblockplus.org/easyprivacy.txt with my browser and then check the cert, I get an expiration date of 3/26/21, which is well into the future. Not sure why pfBlockerNG reports an expired certificate. Does the URL access by pfBlockerNG differ from the above?

RonpfS

@revengineer Did you click on the

Flex: Downgrade the SSL Connection (Not Recommended)

revengineer

@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

@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

jimmythedog

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

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