OPNsense Forum
English Forums => Web Proxy Filtering and Caching => Topic started by: Sahbi on March 18, 2019, 06:46:03 pm
-
The web proxy section seemed most accurate for me to post this in, but I suppose it's actually a "core" issue. It's just most noticeable when using squid.
It seems that the ca-root-nss.crt bundle uses slightly outdated root certs. Trying to navigate to certain pages (https://www.dfrobot.com) results in:
The following error was encountered while trying to retrieve the URL: https://www.dfrobot.com/*
Failed to establish a secure connection to 49.51.40.62
The system returned:
(92) Protocol error (TLS code: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)
SSL Certficate error: certificate issuer (CA) not known: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Now, I know Comodo reissued some of their intermediate certs a couple years ago. They previously used SHA1 but migrated to SHA2 (https://support.comodo.com/index.php?/Knowledgebase/Article/View/970/108/intermediate-2-sha-2-comodo-rsa-domain-validation-secure-server-ca) (had to deal with it at work too).
I quickly cooked up a script (https://forum.opnsense.org/index.php?topic=12096.msg67769#msg67769) to download any root CA's cert and put it along with its hashed-name version in /usr/local/openssl/certs. Since squid looks there I can now access mentioned site, but Comodo isn't exactly a lesser known CA so it should probably be fixed at the core. : D
Not sure if you (OPNsense devs) even have any control over the ca-root-nss bundle or if it's purely a BSD thing though.
-
ca_root_nss was updated to 3.43 a few days ago. I'm not sure if there's anything included in the direction of what you're missing. It's just that we follow what is in there as per recommendation.
There is an idea around how to also trust the additional certs and CAs added under system: trust, but it still needs to be written.
Beyond automatic and manual we don't want to "fudge" "known" "good" certificate authorities into our installations.
Cheers,
Franco
-
ca_root_nss was updated to 3.43 a few days ago. I'm not sure if there's anything included in the direction of what you're missing. It's just that we follow what is in there as per recommendation.
The downside with the approach I described is that many other tools like curl still only seem to look at the bundle by default, otherwise that way would be just fine by me. Also it seems (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.43_release_notes#Notable_Changes_in_NSS_3.43) that a couple of CAs were added, but not the one I mentioned. Do you think it's worth it to raise a report on Bugzilla? I think at least we'd get information on why it's not in there to begin with.
There is an idea around how to also trust the additional certs and CAs added under system: trust, but it still needs to be written.
Yeah I had to make squid trust my own intermediate and root certs manually as well. Which seemed weird because they're already known to OPN as self-signed CAs. :> But I think I saw mention of this feature being in the works somewhere around here so that's cool.
Beyond automatic and manual we don't want to "fudge" "known" "good" certificate authorities into our installations.
Not entirely sure what you mean here.
-
Same error for GeoTrust RSA CA 2018
the only way i found to solve the problem was to export the CA from firefox, import it in Trust->Authorities and then restart squid.
it should really interesting to have the script mentioned by Sahbi :)
-
Same error for GeoTrust RSA CA 2018
the only way i found to solve the problem was to export the CA from firefox, import it in Trust->Authorities and then restart squid.
it should really interesting to have the script mentioned by Sahbi :)
The script does require a URL to the original cert file though. In the case of GeoTrust RSA CA 2018 you'll find this page (https://knowledge.digicert.com/generalinformation/INFO1421.html#links) via Google, then copy the link from SHA-2 Intermediate CAs (under SHA-1 Root) > second Intermediate CA in the table > Download. This would be: https://www.websecurity.symantec.com/content/dam/websitesecurity/support/digicert/geotrust/ica/GeoTrust_RSA_CA_2018.pem
Anyways, the script in question:
#!/bin/sh
certdir=/usr/local/openssl/certs
checkem_ret() {
ret=$?
cmd="$1"
exitval="$2"
if [ -z "$cmd" ]; then cmd='<UNKNOWN>'; fi
if [ -z "$exitval" ]; then exitval=1; fi
if [ $ret -ne 0 ]; then
echo "$cmd returned non-zero exit code ($ret), not proceeding"
exit $exitval
fi
}
if [ -z "$2" ]; then
skripname="$(basename "$0")"
echo "Usage: $skripname <URL to PEM/DER-encoded cert file> <target local file>"
echo "A hardcoded variable \$certdir is prepended to the local file name, this variable is currently set to: $certdir"
echo "Example: $skripname 'https://support.comodo.com/index.php?/Knowledgebase/Article/GetAttachment/970/821027' COMODORSADomainValidationSecureServerCA.crt"
exit 0
fi
certurl="$1"
lfile="$certdir/$2"
if [ ! -d "$certdir" ]; then
mkdir "$certdir"
checkem_ret mkdir 1
fi
if [ -f "$lfile" ]; then
echo "A local cert with the given name already exists, not proceeding: $lfile"
exit 2
fi
# curl's -k flag ignores any certificate errors (useful for downloading self-signed ones like CAcert)
curl -vk -o "$lfile" "$certurl"
checkem_ret cURL 3
if ! grep -q '^-----BEGIN CERTIFICATE-----' "$lfile"; then
echo "Certificate doesn't seem to be PEM/base64 encoded, trying to convert"
bitch64=$(openssl x509 -inform DER -in "$lfile")
checkem_ret openssl 4
echo "Ayy we good y0"
echo "$bitch64" > "$lfile"
fi
certhash=$(openssl x509 -in "$lfile" -hash -noout)
checkem_ret openssl 5
echo "---"
echo "Certificate hash: $certhash"
num=0
while [ -e "$certdir/${certhash}.$num" ]; do
num=$((num + 1))
done
ln -vs "$lfile" "$certdir/${certhash}.$num"
Example usage is given when you run the script without arguments, but for completeness here's how you would/could download the GeoTrust cert:
./install_cacert.sh https://www.websecurity.symantec.com/content/dam/websitesecurity/support/digicert/geotrust/ica/GeoTrust_RSA_CA_2018.pem GeoTrustRSACA2018.crt
I prefer to have CA cert names without underscores and with a .crt extension, but you can choose whatever you want really. =] You don't have to restart squid after running this script, by the way.
-
To be honest, ca_root_nss package has been updated to its latest version very regularly. If you need "faster" than the software bundles can provide that's not really a topic for OPNsense.
doc/17.1/17.1.2:o ports: ca_root_nss 3.29
doc/17.1/17.1.3:o ports: ca_root_nss 3.29.3
doc/17.1/17.1.4:o ports: ca_root_nss 3.30
doc/17.1/17.1.5:o ports: ca_root_nss 3.30.1
doc/17.1/17.1.6:o ports: ca_root_nss 3.30.2
doc/17.1/17.1.9:o ports: ca_root_nss 3.31
doc/17.7/17.7.8:o ports: ca_root_nss 3.34
doc/17.7/17.7.9:o ports: ca_root_nss 3.34.1
doc/18.1/18.1:o ports: ca_root_nss 3.35
doc/18.1/18.1.10:o ports: ca_root_nss 3.37.3
doc/18.1/18.1.5:o ports: ca_root_nss 3.36
doc/18.1/18.1.8:o ports: ca_root_nss 3.37
doc/18.1/18.1.9:o ports: ca_root_nss 3.37.1
doc/19.1/19.1:o ports: ca_root_nss 3.42
doc/19.1/19.1.1:o ports: ca_root_nss 3.42.1
doc/19.1/19.1.10:o ports: ca_root_nss 3.44.1
doc/19.1/19.1.5:o ports: ca_root_nss 3.43
doc/19.1/19.1.8:o ports: ca_root_nss 3.44
doc/19.7/19.7:o ports: ca_root_nss 3.45
doc/19.7/19.7.4:o ports: ca_root_nss 3.46
doc/19.7/19.7.5:o ports: ca_root_nss 3.46.1
doc/19.7/19.7.6:o ports: ca_root_nss 3.47
Cheers,
Franco
-
Same error for GeoTrust RSA CA 2018
the only way i found to solve the problem was to export the CA from firefox, import it in Trust->Authorities and then restart squid.
it should really interesting to have the script mentioned by Sahbi :)
Can you explain me how did you do, i have the same problem but i cant understand what step i have to follow to import an exsisting certificate on Opnsense