[Solved] Business Edition Update Certificate Problem

[mooh]

Hello All!

I’m having a problem performing updates on a DEC750 . I‘m currently using a 3y business license valid until 2025-11-04. Checking for updates currently results in:

Code: [Select]

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 23.10_2 at Tue Nov 14 12:12:37 CET 2023
Fetching subscription information, please wait... Certificate verification failed for /C=DE/ST=LSA/L=Naumburg (Saale)/O=XXXXXXXX/CN=XXXXXXXX/emailAddress=XXXXXXX
8561461309440:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1921:
fetch: https://opnsense-update.deciso.com/${SUBSCRIPTION}/FreeBSD:13:amd64/23.10/subscription: Authentication error
… and lots more (changelog info, repository catalogue, etc) along those lines failing at line 1921.

It looks like our organisation’s private Web GUI certificate (the XXXs) is being used to authenticate to the update server, unsuccessfully of course. This behaviour hasn’t been seen before.

I’m not aware when exactly it started but it seems to be suspiciously close to 1 year after license installation. I have another DEC750 with a 3y license, but it was activated only this summer and is thus less than a year old. On that machine, everything is working just fine.

I’m guessing here, but would it be possible that the update certificates have expired after one year and that using a private certificate is only a last ditch effort by the updater? I.e. is the updater trying all certificates it can find, giving up after the list is exhausted and our certificate just happens to be the last one?

Anyway, I can’t find this specific problem in the forum other than https://forum.opnsense.org/index.php?topic=27851.0 But there is no http mirror for the business edition of OPNsense. So I’m stuck.

[mooh]

What a first posting...

The problem has been identified and fixed. The upstream router dhcpv6 service has failed. Another admin experimentally set the WAN v6 config to SLAAC, resulting in the WAN interface using a ULA, indicating IPv6 connectivity when there wasn't any. This coincided with the attempted update check.

While the problem has been solved, the error messages where pointing in the wrong direction. Maybe this can be improved in a future release.

Sorry for any confusion.

[franco]

Hi,

Defunct IPv6 would have been my guess as well. The IPv6 route for all traffic can for whatever reason start pointing to localhost where the proxy happens to be running. The service fetching is not at fault, neither is DNS likely pointing to the correct IPv6 of the update server. Only the routing is unexpected.

I'm not sure how reporting can be improved. The resulting message is relatively clear you're hitting the wrong server and therefore TLS fails.


Grüsse aus Lützen
Franco