SOLVED System Update Not Working

Status
Not open for further replies.

alexr

Explorer
Joined
Apr 14, 2016
Messages
59
There are 380 changes in this file. While the new version is nicely regularized, it might be better to publish just the one change to remove the bad cert so it's easier for others to review. (Which seems like a good idea for changes to a file like this, right?)
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
There are 380 changes in this file. While the new version is nicely regularized, it might be better to publish just the one change to remove the bad cert so it's easier for others to review. (Which seems like a good idea for changes to a file like this, right?)

Two problems with that:

1) Each release of FreeNAS has a different version of the file.. for example, FreeNAS 11.3-U4.1 has nss-3.46, 11.2R has nss-3.36.1, etc.

2) This is actually a file that SHOULD be kept up-to-date as time passes, because of the addition and deprecation of CA's over time.

I absolutely appreciate your concern, but I am simply not interested in trying to maintain a bunch of versions of this.

Since both my organization and iXsystems distribute customized FreeBSD versions, I decided that my solution was going to be to not just rely on FreeBSD ports to keep ca-root-nss up to date, and instead to develop a better mechanism, one that could also blacklist certificates. Therefore it was better to post the latest version of the CA data. This is likely to have the "longest legs" in terms of usable lifetime. This coincides with some work here that is attempting to do a better job of this moving forward.

From an SSL perspective, I totally appreciate not wanting to just blindly trust someone you don't particularly know out out the Internet. Your recourse there would be to build NSS and check out my file vs theirs, but of course by that point you'd just use theirs (assuming you trust Mozilla more than me). But I'm not actually a rando Internet crank, I do infrastructure engineering for NTP.ORG and if you've got your NTP servers set to pool.ntp.org, then you are already relying on services I've engineered. :smile: (I am absolutely an Internet crank, just not a rando one).

This is why I've told people not to trust it, but I know many of them will, and I provided instructions on how to edit the file yourself.
 

Mannekino

Patron
Joined
Nov 14, 2012
Messages
332
I don't think I have ever seen a "pki folder". I have designed and implemented several enterprise root CA's and a bunch of other random SSL stuff under my belt, along with automated systems to integrate enterprise CA's into system default lists alongside stuff like the Netscape ca-root-nss.crt list, fully hashed even, and I'll go so far as to say that in my opinion there is not a uniform standard as to whether these even go into a single file, a hashed directory, or where or what specifically that may be, depending on OpenSSL's installation directory and OS defaults.

On FreeNAS, it seems like they're borrowing the ports mechanism, and have what appears to be the ports Netscape NSS list in /usr/local/share/certs/ca-root-nss.crt as a single file. You could try plucking out the offending certificate from there to see if it fixes it. Note that the decoded certificate comes BEFORE the encoded certificate, so you would want to make a backup of the file, then try deleting the decoded bits starting at

Code:
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
all the way through the following
Code:
-----END CERTIFICATE-----

which follows the decoded bits and the machine-readable certificate (about 78 lines). This is not a guarantee that this will work, it's just the first thing I'd try.

Thank, this has worked to solve my Jackett issue with two particular trackers.
 

mysticpete

Contributor
Joined
Nov 2, 2013
Messages
143
I don't think I have ever seen a "pki folder". I have designed and implemented several enterprise root CA's and a bunch of other random SSL stuff under my belt, along with automated systems to integrate enterprise CA's into system default lists alongside stuff like the Netscape ca-root-nss.crt list, fully hashed even, and I'll go so far as to say that in my opinion there is not a uniform standard as to whether these even go into a single file, a hashed directory, or where or what specifically that may be, depending on OpenSSL's installation directory and OS defaults.

On FreeNAS, it seems like they're borrowing the ports mechanism, and have what appears to be the ports Netscape NSS list in /usr/local/share/certs/ca-root-nss.crt as a single file. You could try plucking out the offending certificate from there to see if it fixes it. Note that the decoded certificate comes BEFORE the encoded certificate, so you would want to make a backup of the file, then try deleting the decoded bits starting at

Code:
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
all the way through the following
Code:
-----END CERTIFICATE-----

which follows the decoded bits and the machine-readable certificate (about 78 lines). This is not a guarantee that this will work, it's just the first thing I'd try.

Totally worked for me too
 

alexr

Explorer
Joined
Apr 14, 2016
Messages
59
All but one instance is working for me now. My poudriere 11.4-RELEASE jail for building packages is failing to fetch things properly. The jail doesn't have security/ca-root-nss installed and the base behavior is a bit hard to follow. Any idea of where it's getting the bad cert from? I even tried putting a DST_Root_X3.pem file in /usr/share/certs/blacklisted in the jail.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
All but one instance is working for me now. My poudriere 11.4-RELEASE jail for building packages is failing to fetch things properly. The jail doesn't have security/ca-root-nss installed and the base behavior is a bit hard to follow. Any idea of where it's getting the bad cert from? I even tried putting a DST_Root_X3.pem file in /usr/share/certs/blacklisted in the jail.


The base behavior is that there aren't any SSL certificates.

The base system's OpenSSL looks in /etc/ssl/certs or /etc/ssl/cert.pem, depending on whether it is in directory or jumbo amalgamated file mode, and typically on a FreeBSD system, /etc/ssl/cert.pem is pointed at /usr/local/share/certs/ca-root-nss.pem when the Mozilla NSS package is installed. But this is relatively arbitrary. If you've also installed the OpenSSL port, you may find /usr/local/etc/ssl/certs or /usr/local/etc/ssl/cert.pem populated, and some of us purists install a full table at /etc/ssl/certs/* along with the proper hashing to "make it go fast."

More importantly, since any app is allowed to specify its own list of acceptable root CA's, this is really only a starting point for the joyous possibilities of where to track this all down.

Also, because we do actually install a custom list of certs here, most of this is from memory and/or brief-inspection, and might be just a wee bit errant in the details. I don't have a "clean" FreeBSD host to look at.
 

alexr

Explorer
Joined
Apr 14, 2016
Messages
59
The base behavior is that there aren't any SSL certificates.
OK, so it's somehow fetching the bad DST Root X3 cert and because it's OpenSSL 1.0.2u, it's failing with that? I've tried adding that cert to /etc/ssl/blacklisted and the related ISRG Root X1 cert to /etc/ssl/trusted and still no success. Is it reasonable to just install ca_root_nss into this builder jail?
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Try to bear in mind that I have no visibility into what is happening on your system. I have no idea what the hell "blacklisted" or "trusted" are; neither of these makes much sense. You "blacklist" a CA by removing it. You "trust" a CA by adding it. I'm not aware of anything in OpenSSL that would make use of these directories.

What do you imagine these files or directories to be doing? What's actually in them? Are they referenced by openssl.cnf?
 

alexr

Explorer
Joined
Apr 14, 2016
Messages
59
These directories are used by certctl, added in later distributions.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
"distributions" or "distros" are a Linux community term that refers to either a flavor of Linux ("Debian", "Red Hat", etc) or, confusingly, sometimes, a specific release of a flavor.

FreeBSD has "releases". Newer releases of FreeBSD have also moved to OpenSSL 1.1.1, which doesn't have the LetsEnc issue.

FreeNAS is based on FreeBSD 11.(n)R or earlier, and definitely does not have anything called "certctl".

It's pretty clear that this is a general shortcoming of OpenSSL on many platforms, as trust store management has generally been highly inconsistent (often nonexistent) between platforms. As noted a few messages above, there are several places on a default FreeBSD system with ca-root-nss installed that have the CA file, and nothing that even breaks up the file into the more efficient hashed version. If I get time later, maybe I'll go see if I can figure out wtf "certctl" is.
 

Meya

Dabbler
Joined
Dec 5, 2018
Messages
39
You could try plucking out the offending certificate from there to see if it fixes it.

Hello jgreco, my ca-root-nss.crt file has 151 certificates. How do I know which one is the offending one? I currently get this:
1634589422773.png
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Actually I'm going to lock this thread and just redirect everyone to

 
Status
Not open for further replies.
Top