Some certbot issue, not sure if bug (OpenConnect + Let's Encrypt cert)

Bugs
,
1

Hello dear sirs,

I’m facing issue with certificate renewal. As I see in the logs certbot successfully renewed my cert, but now it looks like invalid because (my guess) chain of trust has become wrong.

Here’s what it looks like:

$ show pki 
Certificate Authorities:
Name                        Subject                                                  Issuer CN        Issued               Expiry               Private Key    Parent
--------------------------  -------------------------------------------------------  ---------------  -------------------  -------------------  -------------  --------
AUTOCHAIN_LE-vpn.xxx.io  CN=R10,O=Let's Encrypt,C=US                              CN=ISRG Root X1  2024-03-13 00:00:00  2027-03-12 23:59:59  No             X1
AUTOCHAIN_vpn.xxx.io     CN=R10,O=Let's Encrypt,C=US                              CN=ISRG Root X1  2024-03-13 00:00:00  2027-03-12 23:59:59  No             X1
X1                          CN=ISRG Root X1,O=Internet Security Research Group,C=US  CN=ISRG Root X1  2015-06-04 11:04:38  2035-06-04 11:04:38  No             N/A

Certificates:
Name           Type    Subject CN        Issuer CN    Issued               Expiry               Revoked    Private Key    CA Present
-------------  ------  ----------------  -----------  -------------------  -------------------  ---------  -------------  ------------
vpn.xxx.io  Server  CN=vpn.xxx.io  CN=R11       2025-07-14 15:46:58  2025-10-12 15:46:57  No         Yes            No

Certificate Revocation Lists:
CA Name    Updated    Revokes
---------  ---------  ---------

So the problem is that previous cert was issued by R10, and renewed issued by R11. And I don’t have certificate of this authority. What are my current options to fix this? Can I just install CA certificate for R11 authority (as name suggests it was installed automatically previously)?

Clients don’t have any issues connecting to VPN (just warnings), so I can do some tshoot and attach debug info if this is a bug.

Sysinfo:


Version:          VyOS 2025.05.05-0020-rolling
Release train:    current
Release flavor:   generic

Built by:         autobuild@vyos.net
Built on:         Mon 05 May 2025 00:20 UTC
Build UUID:       999dbb8c-a02c-4c74-8785-f2c6c0b008de
Build commit ID:  65f3b103a5b312

Architecture:     x86_64
Boot via:         installed image
System type:      VMware guest
Secure Boot:      disabled

Hardware vendor:  VMware, Inc.
Hardware model:   VMware20,1
Hardware S/N:     VMware-56 4d 2d d7 b6 2c 4d 6d-3b bb bb 93 e1 a4 b3 5e
Hardware UUID:    d72d4d56-2cb6-6d4d-3bbb-bb93e1a4b35e

Copyright:        VyOS maintainers and contributors

As always - thanks for your hard work making your product.

Regards,
Konstantin

2

I don’t think R10/R11 matters - I could be wrong, but I’m pretty sure they’ll both be signed by the root cert, not a specific intermediate one.

Why do you think it looks invalid?

What if you try something like https://testssl.sh/ against it, what does that report?

3

@tjh I just monitor validity using this - SSL monitoring and integration with Zabbix

Tool you suggested says my original guess was right :slight_smile:

 Chain of trust               NOT ok (chain incomplete)

And I get similar error output from OpenConnect client:

Server certificate verify failed: signer not found

Certificate from VPN server "vpn.xxx.zzz" failed verification.

Thanks for your prompt reply, HTH

4

FYI just installed subordinate certs from Chains of Trust - Let's Encrypt and now chain of trust looks good :slight_smile:

Maybe there should be some tech design considerations about these AUTOCHAIN_* certs. If I recall this right I installed X1 root CA first and AUTOCHAIN_* certs were created automagically when I configured ACME for OpenConnect. What are the best practices here?

1 Like
5

Trying to dig deeper on this issue, but have not so much time unfortunately :frowning:

Problem is kinda gone HTTPS-wise - OpenConnect client shows no errors, testssl.sh shows no chain of trust issues.

But zabbix-agent2 goes like:

$zabbix_get -s 192.168.200.12 -k web.certificate.get[vpn.xxx.io]

{"x509":{"version":3,"serial_number":"062172ed2c8b263558018a66a75d4ec35d47","signature_algorithm":"SHA256-RSA","issuer":"CN=R11,O=Let's Encrypt,C=US","not_before":{"value":"Jul 14 15:46:58 2025 GMT","timestamp":1752508018},"not_after":{"value":"Oct 12 15:46:57 2025 GMT","timestamp":1760284017},"subject":"CN=vpn.xxx.io","public_key_algorithm":"RSA","alternative_names":["vpn.xxx.io"]},"result":{"value":"invalid","message":"failed to verify certificate: x509: certificate signed by unknown authority"},"sha1_fingerprint":"642e39bf9cff732bfb1d9ef2c42eb28f74c1de70","sha256_fingerprint":"42a3e67d102ea9c1975efa3dd890c0000a78967d3ade58e1756276d43a09a62b"}

Tried to restart agent - no luck.

Any ideas why? Or do I have to dig source code? :slight_smile:

TIA

6

FYI looks like the problem was with wrong CA certificate in vpn openconnect ssl - there was old AUTOCHAIN_ configured. Strange fact is that sometimes everything worked like a charm - testssl.sh (and OpenConnect client) showed no chain of trust issues.

So now my config goes like this (no explicit CA certificate, just this):

set vpn openconnect ssl certificate 'vpn.xxx.io'

Am I getting this right that in this case CA cert is used according to PKI? Show PKI shows all the certificates - intermediate and root ones.

TIA, regards,
Konstantin