Solved fetch and ca_root_nss not working on Raspberry Pi image

gladiola

gladiola

I'm having trouble with fetch from an https site. Normally, I set up fetch to pull from an https site by installing pkg install ca_root_nss. This time, I'm trying it on a Raspberry Pi 3 running FreeBSD 12.1-RELEASE r354233 GENERIC arm64. Unfortunately, it's not working.

I still see the usual error that you would get if you did a fetch from an https without ca_root_nss:
1084624896:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915

I tried a couple of sites. When I fetch from a box that normally works, with the ca_root_nss installed, the page pulls down just fine. When I try the same site on the Pi, it fails.

Is this just a limitation of the RaspPi image? Any advice you might give could be helpful.
 
What does ls -l /etc/ssl return? There should be a cert.pem@ link to /usr/local/share/certs/ca-root-nss.crt. Check also /usr/local/etc/ssl.
 
Both of those show the links. Excerpt below.
Code: 
For ls -l /etc/ssl:
cert.pem -> /usr/local/share/certs/ca-root-nss.crt

For ls -l /usr/local/etc/ssl:
cert.pem
cert.pem.sample -> /usr/local/share/certs/ca-root-nss.crt

pkg info ca_root_nss shows:
Code: 
ca_root_nss-3.54
Name           : ca_root_nss
Version        : 3.54
Installed on   : Fri Nov  1 09:17:06 2019 UTC
Origin         : security/ca_root_nss
Architecture   : FreeBSD:12:*
Prefix         : /usr/local
Categories     : security
Licenses       : MPL20
Maintainer     : ports-secteam@FreeBSD.org
WWW            : UNKNOWN
Comment        : Root certificate bundle from the Mozilla Project
Options        :
    ETCSYMLINK     : on
Annotations    :
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 784KiB
Description    :
Root certificates from certificate authorities included in the Mozilla
NSS library and thus in Firefox and Thunderbird.

This port directly tracks the version of NSS in the security/nss port.

Given that output, I feel that pkg was successful in installing the ca_root_nss package. The date, though, trips me up. I didn't install it on 01NOV2019. I installed it yesterday. Maybe this has something to do with the November dates on the Pi image. Not sure.

If I go to /usr/local/share/certs, I do see that ca-root-nss-.crt file. When I cat it, it's filled with multiple signatures and fingerprints. I think the package has put the right items in the right place.

Not sure how to check things out on the fetch end. Since fetch is a part of the main system, I can't really reinstall it. Return code is a 1, of course, because of the authentication error.

I considered trying to rebuild the image from scratch, so that I could watch the process; but, I found no good directions. Lacking knowledge about ARM assembly, I doubt I would be qualified to figure out what right looks like on my own.
Coincidentally, I can't use freebsd-update on this image; it tells me to rebuild from source. Well, I looked around. It's a Pi 3. The ARM files look like they are 32 bit on FreeBSD 13. For the 12.1, I don't see anything I could use to build or rebuild this item. I'm pretty sure that if I took source code meant for another architecture, that I'd be wasting my time. Not sure how to proceed.

Sort of wondering if Pi use for FreeBSD 12.1 was still experimental to the point the fetch wasn't working yet.
 
I vaguely remember feeling like the last time I solved this problem, it was a permissions issue between openssl and fetch. openssl, fetch, and these files are all root wheel. All of that is as-is, I don't think that's it.

Yet, I feel like it was that the group needed write permissions on a file, but I'm not finding the reference I used to solve that problem. Poured over fetch(3) and the other man page, but didn't find what I needed. Tried setting an environment variable to point to that crt file, but that didn't help, either.
 
I apologize. It was failing because the time was off. As soon as I set the date to the current date and time, fetch worked. The authentication was probably failing because the time was out of range. The Pi image believed it was still November 2019.

I found my clue here, when searching for the error code at the beginning of the message (1084624896:error:1416F086:SSL routines). Earlier, I was searching for the tail end of the error message, that was showing the point of the verification failing (tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:).

REF: https://stackoverflow.com/questions...86ssl-routinestls-process-server-certificatec

Sorry, I hadn't used that thing much. I still had the default image and was setting it up for first use. Thanks to everyone who helped.
 
You must log in or register to reply here.
Back
Top