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:         [email protected]
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