Project

General

Profile

Actions

Bug #3337

closed

libressl/tls13_client.c:609

Added by aswell over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
01/16/2023
Due date:
% Done:

0%

Estimated time:

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?

Actions #1

Updated by tuxillo over 1 year ago

  • Status changed from New to In Progress

Are those other machinnes in the same network?

Actions #2

Updated by aswell over 1 year 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?

Actions #3

Updated by tuxillo over 1 year 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... " ?

Actions #4

Updated by aswell over 1 year 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?

Actions #5

Updated by aswell over 1 year 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.

Actions #6

Updated by aswell over 1 year 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.

Actions #7

Updated by tuxillo over 1 year ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF