Solved: Can't update bogons on a 2.4.5-p1 (cert expired)

bingo600

Success

This was a "Ride into FreeBSD" & Certificates , and multiple cert files.

1:
fetch uses the cert file in :

/usr/local/etc/ssl/cert.pem

Most other uses the cert file in :

/usr/local/share/certs/ ca-root-nss.crt

Or the cert file in:

/etc/ssl/cert.pem

That is in fact symlinked to : /usr/local/share/certs/ca-root-nss.crt

/etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt

2:
Make fetch use the same cert file as the "system" via symlink

cd /usr/local/etc/ssl/
rm cert.pem
ln -s /usr/local/share/certs/ca-root-nss.crt cert.pem

Now a

ls -l /usr/local/etc/ssl/cert.pem

Should show

cert.pem -> /usr/local/share/certs/ca-root-nss.crt

3: Let's fix the expired certificate
Idea from here :
https://www.truenas.com/community/threads/ssl-certificate-problem-certificate-has-expired-the-openssl-1-0-2-vs-letsencrypt-issue.95874/

With your favorite editor open : /usr/local/share/certs/ca-root-nss.crt

Locate the below certificate : I searched for : DST Root CA X3

Now delete all lines beginning with : Certificate

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Validity
            Not Before: Sep 30 21:12:19 2000 GMT
            Not After : Sep 30 14:01:15 2021 GMT

And further down , where you will eventually see a BEGIN CERTIFICATE and a bunch of ASCII encoded binary garbage. Delete all of this, all the way through the following , including the below line

-----END CERTIFICATE-----

The total deleted section should be 81 lines.

Save the file , and bogons update should work again:

Test with:

/usr/bin/fetch -a -w 600 -T 30 -q -o /tmp/bogons https://files.pfsense.org/lists/fullbogons-ipv4.txt

That should run without errors.

Bogons will be in : /tmp/bogons

fetch was driving me crazy ...
openssl wasn't showing errors after the removal of teh bad certificate , and curl would get the file. But fetch still showed error .....

After lot's of headscratching i finally saw someone mention that fetch used its "own" cert file

Now that "they" symlinked one file why not the other ?????

/Bingo

Gertjan

@bingo600

Tell fetch what certificate file to use :

/usr/bin/fetch -a -w 600 -T 30 -q --ca-cert=/usr/local/share/certs/ca-root-nss.crt -o /tmp/bogons https://files.pfsense.org/lists/fullbogons-ipv4.txt

All certs in this file will be trusted.

bingo600

@gertjan
That won't work with the "Auto update of bogons"
They don't specify any cert file.

You will have to edit the cert file or (imho better) , symlink to the file the other programs uses.

/Bingo

Gertjan

@bingo600 said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

That won't work with the "Auto update of bogons"
They don't specify any cert file.

Correct - this won't help the update script'(s).
Far better is correcting the needed files.

I posted the extra part "--ca-cert=/usr/local/share/certs/ca-root-nss.crt" so files could get loaded.
The /usr/local/share/certs/ca-root-nss.crt should be corrected manually, as more root certificates will expire in the future.

Btw : even when MS updates for Windows XP stopped many years ago, there were still updates : the files with system trusted certs.

JeGr

@gertjan said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

Btw : even when MS updates for Windows XP stopped many years ago, there were still updates : the files with system trusted certs.

Yes, but you would only need that if you would stay in 2.4.5 - which isn't the normal/desired outcome, as - especially with a security product - we should update to the next stable version. So expiration of other CAs would only hit if you'd stay with 2.4.5 which isn't recommended / supported anyways and in 2.5.2 (latest current stable) the CA file should already be correct.

johnpoz

I concur with @jegr here - the actual solution to the problem is getting the pfsense current.

While updating the CAs trusted is a temp solution to a specific problem, it is only a stopgap measure at best.

To be honest my bogon being a bit dated is least of my worries on my older pfsense installs, that yes need to be updated when can actually get into the office, etc.

bingo600

@jegr
I'm not planning on staying on 2.4.5-p1 forever.
But given the "first track record" of the 2.5.x systems , i decided to wait a bit.
Ie. the early unbound issues would have been a "killer".

I do have one test site running 2.5.2 wo. any issues, it "just upgraded" ....
AKA keeps the L2L connection up wo. any dropouts.
But it doesn't see any load or usage, it's just a "passive system" at my desk.

But on the "Job" i have 1 Central pfSense and 6 remote (openvpn) L2L coupled sites.

My sites are spread around the world, and it would be a "Major issue" if they went down.
I have a "Cold spare" on my two most urgent sites, but they "never" found the time to upgrade the pfSense OS with me, o the "secondary". That is purely "manager politics", that i try to get around, but haven't succeeded yet.
So the failover systems aren't up to it.

My central unit has 1:1 (alias) NAT to several public "outside" IP's , and i'm a bit worried about that. I read that there was some NAT issues with 2.5.x , but maybe 2.5.2 has solved it , i don't know yet.
Any hints here ?.

I have a "Central Cold spare" i could wipe & install 2.5.2 on , and then give it the 2.4.5-p1 config. But i will "Not get a prize" if it doesn't work, even if it's just for 4..6 hours.

/Bingo

johnpoz

@bingo600 said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

But i will "Not get a prize" if it doesn't work, even if it's just for 4..6 hours.

haha - I hear ya.. But you might be finding a new job ;)

While your solution is good - I personally would of just disabled bogon if was having issues with it. While sure its the "right" thing to do blocking it, in the big picture is not high on the list of security things to make sure your blocking..

bingo600

@johnpoz
Bogon's was for my own 2 pfSenses
And a ... I'm not giving up kinda moment.
I haven't even bothered implementing that "trick" on the Job ones ....

I have 2 x 240GB Samsung EVO-870 SSD disks , just waiting for me to install in the "home/summerhouse" pfSenses, along w. ZFS & 2.5.2.
I chose 240G because i plan to use ZFS snapshots for real, on 2.5.2.

I just have to find the right time, we're streaming TV here ....
And if you thought i was nervous of the "Job Boss" ...
That's nothing compared to the "Real BOSS"

And when done "home" , the the one in the summerhouse is next.

JeGr

@bingo600 said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

And a ... I'm not giving up kinda moment.
I haven't even bothered implementing that "trick" on the Job ones ....

I appreciate it! I have some 2.4.5 systems in the wild myself that customers aren't able to update right now and those had rising numbers of dead/zombie processes (dying bogon procs) that we were able to fix that way - so thumbs up from me for the fact finding mission

johnpoz

@jegr said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

rising numbers of dead/zombie processes (dying bogon procs)

Hmmm - interesting.. Curious bogon believe is only suppose to update every 30 days.. How many did they have? I wonder if it fails it start hammering looking to work more often than once every 30 days.

I just looked at 1 of my older installs

52 processes: 1 running, 50 sleeping, 1 zombie

bingo600

@johnpoz
They seem to "never die/timeout"
So you'll accumulate foe each month , and if you try to update manual that'll also start an additional.

Can't remember if each try starts 3 processes.
The php master + the fetch + "i think another"

/Bingo

bingo600

@jegr said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

@bingo600 said in Solved: Can't update bogons on a 2.4.5-p1 (cert expired):

And a ... I'm not giving up kinda moment.
I haven't even bothered implementing that "trick" on the Job ones ....

I appreciate it! I have some 2.4.5 systems in the wild myself that customers aren't able to update right now and those had rising numbers of dead/zombie processes (dying bogon procs) that we were able to fix that way - so thumbs up from me for the fact finding mission

Glad to be able to give a little back

And ...
Now i know that to tomorrow on the job for 7 firewalls
Done ....

And home fwall
Fresh install w. ZFS , and config restoren only one minor "quirk"
iftop didn't install , but the pkgmgr. was informing about that

/Bingo