Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

[lat9nq]

Background

• Operating System: Fedora 35
• CKAN Version: v1.30.4 (rpm from Releases page)
• KSP Version: 1.12.9 I think? Not sure this is relevant anyway

Have you made any manual changes to your GameData folder (i.e., not via CKAN)?
no

Problem

Describe the bug
Can't download some mods due to SSL errors. Following the instructions at https://github.com/KSP-CKAN/CKAN/wiki/SSL-certificate-errors has not been helpful.

Steps to reproduce

• Select an affected mod such as Near Future Solar
• Click Apply Changes and follow subsequent prompts
• See error

I'm ignoring the rest of this template because I'm pretty sure you guys have seen this song and dance before, seeing how many times this issue has been opened.

---

I tried following the steps from #3567 (comment) -- meaning I downloaded the expired certificate to my system since it didn't already exist on my system. I placed it at /etc/pki/ca-trust/source/blacklist as well as /etc/pki/ca-trust/source/blocklist, re-ran the cert-sync commands on the previously mentioned wiki article, and to no avail.

Since the wiki article mentions #3457 which was merged after the most recent release, and because there are no artifacts to download from the repo's CI, I attempted to build CKAN. Running ./build results in an error fairly early. (Obviously this isn't a supported case, but) trying to build with the GitHub workflow yml using nektos/act also fails, albeit at a much later stage. If any of this is worth making another issue for let me know.

If there are more recent artifacts, I would like to be wrong in that there are actually artifacts to download.

[HebaruSan]

If there are more recent artifacts, I would like to be wrong in that there are actually artifacts to download.

Yes, that's probably the only thing here we can actually help you with. The latest build is always here:

https://ksp-ckan.s3-us-west-2.amazonaws.com/ckan.exe

... though that won't affect whether you have the certificate problem, since it only affected the containers where we build ckan.exe, it didn't change anything about how the exe behaves.

[HebaruSan]

Anyway, it sounds like you have the opportunity to translate the wiki's current tips for Debian- and Arch-based distros into Redhat world. Please let us know if you find what steps are needed on your system and we'll update the wiki.

[lat9nq]

Well, thanks for handing me an updated build. And yeah that didn't help, but at least I got that answer now.

If I take another crack at this I'll try and let you all know what helped. I'm at my wit's end and making an Issue for it is a last resort type of thing for me to do.

[DasSkelett]

I just tried on a Fedora system and noticed that if I put the certificate in /etc/pki/ca-trust/source/blocklist (with o)it will not be blocklisted. Only /etc/pki/ca-trust/source/blacklist (with a) works.
You can verify it by looking at trust list after running update-ca-trust, there should be one with label: DST Root CA X3 which says trust: blacklisted. If it says trust: anchor it did not work.

[lat9nq]

Okay, so I think update-ca-trust was the step I was missing.

By default Fedora does include the certificate, but it's bundled with a bunch of other certificates in a single file: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt. Running grep -n 'DST Root CA X3' ca-bundle.trust.crt will inform what line it's located at.

In a VM I was able to get CKAN going with the following steps:
As root:

grep -A21 'DST Root CA X3' /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt > /etc/pki/ca-trust/source/blacklist/DST_Root_CA_X3.pem
update-ca-trust
cert-sync /etc/ssl/certs/ca-certificates.crt

As a user:

cert-sync --user /etc/pki/tls/cert.pem

This can hopefully be adopted for a section after Arch in Removing expired Let's Encrypt certificates.

[NdranC]

I just tried on a Fedora system and noticed that if I put the certificate in /etc/pki/ca-trust/source/blocklist (with o)it will not be blocklisted. Only /etc/pki/ca-trust/source/blacklist (with a) works. You can verify it by looking at trust list after running update-ca-trust, there should be one with label: DST Root CA X3 which says trust: blacklisted. If it says trust: anchor it did not work.

I'm currently using Fedora 36 and I noticed the solution listed on the wiki and this comment thread was not working for me. Trying out a couple options I noticed the certificate was not getting blacklisted at all by putting it in "/etc/pki/ca-trust/source/blacklist" it only worked for me after putting it in "/etc/pki/ca-trust/source/blocklist".

I'm unsure as to why is working differently for some people. This means the wiki instructions for fedora are wrong (at least for me).