1.5 rolling replaces symbolic links with files in certbot directory - another bug or feature request

Bugs
1

Hi there
Begin is there

It looks like somewhere in April or May bug was fixed but appear another one.

After rolling upgrade with authomatic Symbolic link to exesting letsencrypt certificate Windows Client could not establish VPN connection anymore.
Everything looks helsy but client exits with “IKE authentication credentials are unacceptable”
Evenlog on client contains “The user dialed a connection named IKEv2 VPN which has failed. The error code returned on failure is 13801.”

This error means

The error code 13801 when connecting to an IKEv2 VPN <mark>typically indicates an issue with the authentication credentials, specifically related to certificates</mark>. This often means the client computer doesn't trust the server certificate or the server certificate is not configured correctly.

Letsencrypt certificate looks fresh and helsy by himself.
renew certbot exits because it is too early to renew.

it would be useful to forcibly renew certificate but there is no command options to make this.

Looks like we need addtional option to renew certbot directive to forcibly renew certificate just to check would it help or not.

Simple sudo certbot renew doesn’t help because do not understand existing configuration.

2

Hi there,

Rolling releases since at least 20250606 (former one tested) give foloowing error during pki deployment

vyos@-VFW046# set pki certificate repka acme domain-name 'repka.xxx.yy'
[edit]
vyos@-VFW046# set pki certificate repka acme email '[email protected]'
[edit]
vyos@-VFW046# set pki certificate repka acme listen-address 'xx.x.xx.46'
[edit]
vyos@-VFW046# set pki certificate repka acme rsa-key-size 4096
[edit]
vyos@-VFW046# set pki certificate repka acme url https://acme-staging-v02.api.letsencrypt.org/directory
[edit]
vyos@-VFW046# commit
[ pki ]
Updating configuration: "vpn ipsec remote-access connection rw
authentication x509 certificate repka"

Traceback (most recent call last):
  File "/usr/libexec/vyos/services/vyos-configd", line 145, in run_script
    script.verify(c)
  File "/usr/libexec/vyos//conf_mode/pki.py", line 381, in verify
    certbot_request(name, cert_conf['acme'])
  File "/usr/libexec/vyos//conf_mode/pki.py", line 147, in certbot_request
    if ('haproxy' in dict_search('used_by', config) and
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument of type 'NoneType' is not iterable

[[pki]] failed
Commit failed

tested on 20250606 and 20250617
rolling release 20250506 works without this error

3

Thank you for the bug report, tracked via ⚓ T7573 pki: TypeError: argument of type 'NoneType' is not iterable when haprox is not in use and fixed in pki: T7573: fix TypeError when HaProx is not in use by c-po · Pull Request #4572 · vyos/vyos-1x · GitHub.

I also noticed the lack of the force renewal - but did not think someone other then me might need it. Well time to add it then pki: T7574: add optional force argument to renew certbot-issued certificates by c-po · Pull Request #4573 · vyos/vyos-1x · GitHub

1 Like
4

looks like Release 2025.07.01-0813-rolling · vyos/vyos-nightly-build · GitHub fixes above error with minor notes

Just after image upgrade by add system image and reboot, migration failed with unspecified error (didn’t checked thoroughly the issue)
But simple configure | load | commit | save ended without errors and everything looked fine.
AFAIU, PKI structure regenerated from the scratch during migration.
But I needed one more reboot to reload IKE VPN data/configuration for normal work.
At the moment everything looks helsy.

5

Hi,

Every reboot gives me configuration migration error

compare commands 0 | strip-private
delete pki ca AUTOCHAIN_repka certificate 'MIIFBTCCA......A54='
delete pki certificate repka acme domain-name xxxxxx
delete pki certificate repka acme email '[email protected]'
delete pki certificate repka acme listen-address 'xxx.xxx.59.46'
delete pki certificate repka acme rsa-key-size '2048'
delete pki certificate repka acme url xxxxxx

But as stated above simple configure | load | commit | save ended without errors.