Bug #3337
closed
libressl/tls13_client.c:609
0%
Description
On a fresh install of 6.4, when attempting to install a package, the following message is received:
root@server0:/tmp # pkg update
Updating Avalon repository catalogue...
Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3
Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3
Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3
34395427332:error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed:/usr/src/lib/libressl/../../crypto/libressl/ssl/tls13_client.c:609:
pkg: https://mirror-master.dragonflybsd.org/dports/dragonfly:6.6:x86:64/LATEST/packagesite.txz: Authentication error
Unable to update repository Avalon
Error updating repositories!
Editing /usr/local/etc/pkg/repos/df-latest.conf and changing 'https' to 'http' results in a working update.
Also, an attempt to fetch a file:
root@server0:/tmp # fetch https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-amd64-memstick.img.xz
Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3
Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3
Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3
34380796420:error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed:/usr/src/lib/libressl/../../crypto/libressl/ssl/tls13_client.c:609:
fetch: https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/13.1/FreeBSD-13.1-RELEASE-amd64-memstick.img.xz: Authentication error
Just for good measure, downloaded source and rebuilt world/kernel and rebooted, but whatever is causing the problem remains.
Interestingly, a few other machines with recent 6.4 installs do not exhibit this issue.
Suggestions?
Updated by tuxillo almost 2 years ago
- Status changed from New to In Progress
Are those other machinnes in the same network?
Updated by aswell almost 2 years ago
tuxillo wrote in #note-1:
Are those other machinnes in the same network?
Unfortunately the machine with the issue is remote, good machines are local. Any suggestions on how to resolve?
Updated by tuxillo almost 2 years ago
Unfortunately the machine with the issue is remote, good machines are local. Any suggestions on how to resolve?
The only thing that comes to mind right now is that there is some device who's doing mitm or so, hence replacing the ssl certificate with one of its own.
BTW, if it's a 6.4 install, why is it looking for packages in "...dragonfly:6.6:x86:64... " ?
Updated by aswell almost 2 years ago
tuxillo wrote in #note-3:
BTW, if it's a 6.4 install, why is it looking for packages in "...dragonfly:6.6:x86:64... " ?
Good question. When compiling from source I decided to switch to master, so 6.4 was originally installed, but it's now running master...
The only thing that comes to mind right now is that there is some device who's doing mitm or so, hence replacing the ssl certificate with one of its own.
I had considered that, but programs that use the userland SSL library appear to work fine. It seems something is not right with the base SSL.
How can one go about replacing or updating the base SSL install?
Updated by aswell almost 2 years ago
- Status changed from In Progress to Resolved
Update: It is now working properly. Nothing changed with the server, but I just went to test further, and both pkg and fetch work using https, without error.
So, either your mitm hypothesis was correct, or I stumbled on a glitch in the matrix...but either way the problem resolved itself.
Thanks for your feedback, much appreciated.
Updated by aswell almost 2 years ago
aswell wrote in #note-5:
So, either your mitm hypothesis was correct...
Note: the issue was seen within an hour of completing setup of a dedicated server. I am a new customer, and the provider is a larger company with their own facility. Therefore, the most likely explanation is that some security measures may have been in place at the time, that were shortly thereafter removed.