Nethserver-blacklist/download failing

Support
1

Following the weekly cron job that rotates the logs (although, that does actually coincide with a daily cron, so the issue could have been with that) I’m now seeing a failure every time nethserver-blacklist/download runs, every 20 minutes.
Extracting out the failing command, and turning on debug, I see this:

[root@Nethserver ~]# GIT_TRACE=2 git --git-dir=/usr/share/nethserver-blacklist/ipsets/.git --work-tree=/usr/share/nethserver-blacklist/ipsets fetch --all
15:24:11.649657 git.c:344 trace: built-in: git ‘fetch’ ‘–all’
Fetching origin
15:24:11.650246 run-command.c:627 trace: run_command: ‘fetch’ ‘–append’ ‘origin’
15:24:11.652711 git.c:344 trace: built-in: git ‘fetch’ ‘–append’ ‘origin’
15:24:11.653439 run-command.c:627 trace: run_command: ‘git-remote-https’ ‘origin’ ‘https://xxxxxxxx-632f-4da0-92a4-xxxxxxxxxxxx:%%%redacted%%%@nethserver.bogolinux.net/git/ipsets’
fatal: unable to access ‘https://xxxxxxxx-632f-4da0-92a4-xxxxxxxxxxxx:%%%redacted%%%@nethserver.bogolinux.net/git/ipsets/’: Peer’s Certificate issuer is not recognized.
error: Could not fetch origin
15:24:11.792786 run-command.c:627 trace: run_command: ‘gc’ ‘–auto’
15:24:11.794919 git.c:344 trace: built-in: git ‘gc’ ‘–auto’
[root@Nethserver ~]#

Any ideas which one of the cron jobs could have done to cause this, and how do I correct it.

I’ll go looking for the references I used to set up the blacklists as I can’t seem to find them just yet.

Update Found it: here.

Cheers.

2

Is this the Blacklist URL? https://nethserver.bogolinux.net/git/ipsets/

config getprop blacklist Url

The cron job responsible to download the blacklists is /etc/cron.d/nethserver-blacklist/

Question for devs (@giacomo): Is it safe to share/post the URL which contains a secret ID? Just asking…

3

Yep:

[root@Nethserver ~]# config getprop blacklist Url
https://nethserver.bogolinux.net/git/ipsets
[root@Nethserver ~]#

Yes, that’s the script that’s failing with the git command I pasted earlier.

Redacted the information, just to be safe.

Cheers.

4

According to an online search (and sslabs analysis), the error might be related to an incomplete certificate chain. Don’t know if it’s a letsencrypt change or something else. Not right up my alley.

5

Interesting, as I haven’t touched anything to do with certificates. I’m using the certificate chain as constructed by LetsEncrypt/Nethserver, which has been working for over 1,000 days now, as the logs are wrapping.

Cheers.

6

OK, it’s one of the issues with certificate renewal I reported back in November 2016 and August 2017, both reported here.

I had “hacked” my copy of /usr/libexec/nethserver/letsencrypt-certs to work in (what I think is) all conditions. It looks like this was replaced fairly recently, for the first time in (obviously) over 2 years, so when LetsEncrypt renewed my certificate on January 25th, it wasn’t applied to my system.

It looks like the latest update fixes the mixed case issue, but not the one with the “pki/LetsEncryptDomains” property order. The fix I suggested in that report is my “hack”.

Cheers.

7

No it’s not :slight_smile: