Easylist update fails. Expired Cert
-
@Derelict OK. Easylist needs to update their certs. Good to know were the fault is. That's helpful.
The aggressive posture is, however, not helpful. If I could explain how downloading easylists has anything to do with Netgate's servers I would not have posted the question.
-
The list downloaded with Flex State :
[ EasyList_Adware ] Downloading update . cURL Error: 60 [ ! ] Downgrading SSL settings (Flex) . 200 OK. ---------------------------------------------------------------------- Orig. Unique # Dups # White # TOP1M Final ---------------------------------------------------------------------- 100 100 1 0 0 99 ---------------------------------------------------------------------- -
@jwj Aggressive? Man. How about pointed and factual. I was asking because I personally have no idea how Easylist works or how you have your node/Aliases/pfBlocker configured.
-
@Derelict Yup. And sarcastic. How about: "That's all server side, nothing you or we can do from this end." That would be pointed and factual. You asked because you knew damn well it had nothing to do with Netgate servers. Sorry if you found the question too stupid to answer as an adult. My bad for expecting an adult reply.
-
I didn't know what servers were in question until @RonpfS answered with specifics. I had a pretty good idea it wasn't going to be a netgate server but I did not know for sure. Sorry I offended your delicate sensibilities by providing an immediate, factual diagnosis of the exact problem you were asking about. Please forgive me for asking for additional, specific details.
-
@jwj Here's an easy way to see the issues with the EasyList SSL Cert chain: Just navigate to this site:
This is NOT a Netgate issue, but a problem with server hosting the EasyList txt files. EasyList cert has two CAs that expired today.
-
@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.
-
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?
-
@revengineer Did you click on the
Flex: Downgrade the SSL Connection (Not Recommended)
-
@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-signingsectionSo, to fix it, I deleted the old CA from the
/usr/local/share/certs/ca-root-nss.crtfile (lines 423-512 in my version), as described in theWhat to do?section in that link aboveHTH
-
@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-signingsectionSo, to fix it, I deleted the old CA from the
/usr/local/share/certs/ca-root-nss.crtfile (lines 423-512 in my version), as described in theWhat to do?section in that link aboveHTH
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:
As of this morning, the SSL issue still hasn't been resolved:
-
@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:
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 -
@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 termtrust 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 storePersonally, 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.
-
@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.
