keenetic viva: ipsec перестал принимать серт от let's encrypt

[dotcom]

После автоматического обновления сертификата Let’s Encrypt через certbot на сервере (Linux) перестало подключаться IKEv2 VPN-подключение с клиента Keenetic (Viva). Версия ОС. 5.0.10

При этом подключения с macOS / iOS / Android работают корректно.

Изменение, после которого возникла проблема:

• ранее сертификат был выдан через Let’s Encrypt R12
• после обновления сертификат выдан через R13

Серверная часть (Linux) выдаёт следующие сообщения:

____

using certificate "CN=vpn.domain.ru"
no issuer certificate found for "CN=vpn.domain.ru"
issuer is "C=US, O=Let's Encrypt, CN=R13"
no trusted RSA public key found for 'vpn.domain.ru'

____

Лог кинетика

ipsec

06[CFG] using certificate "CN=vpn.*.ru"

Апр 24 17:05:19

ipsec

06[CFG] no issuer certificate found for "CN=vpn.*.ru"

Апр 24 17:05:19

ipsec

06[CFG] issuer is "C=US, O=Let's Encrypt, CN=R13"

Апр 24 17:05:19

ipsec

06[IKE] no trusted RSA public key found for 'vpn.*.ru'

Изменено 24 апреля пользователем dotcom

[dotcom]

Разобрался, проблема была в приватном ключе.

В /etc/ipsec.d/private/ оставался старый privkey. Ранее при обновлениях через certbot (chain1–chain3) использовался один и тот же ключ, поэтому всё работало и я про него забыл.

При последнем обновлении certbot сгенерировал новый приватный ключ, но в /etc/ipsec.d/private/ был старый. В результате сертификат и ключ не совпадали, что приводило к AUTH_FAILED почемуто только у части клиентов.

Изменено 24 апреля пользователем dotcom

[dotcom]

Итак, оставлю решение здесь, в том числе для себя на будущее, постоянно забываю и бьюсь целый день.

Исходные данные:

• VPN-сервер на StrongSwan (IKEv2/EAP).
• Сертификаты Let's Encrypt получены через Certbot.
• Клиенты macOS, iOS, Android и Windows подключаются без проблем.
• Клиент на Keenetic не может установить соединение.

В логах Keenetic наблюдаются сообщения:

received end entity cert "CN=vpn.***.ru"
using certificate "CN=vpn.***.ru"
no issuer certificate found for "CN=vpn.***.ru"
issuer is "C=US, O=Let's Encrypt, CN=YR1"
no trusted RSA public key found for 'vpn.***.ru'

После обновления сертификата Let's Encrypt начал использовать новую цепочку сертификации:

vpn.***.ru
 └─ YR1
     └─ Root YR
         └─ ISRG Root X1

При этом сертификат сервера и цепочка находились в стандартном каталоге Certbot:

/etc/letsencrypt/live/vpn.***.ru/

Однако для корректной работы клиента Keenetic оказалось недостаточно наличия цепочки только в fullchain.pem и chain.pem.

Решение:

1. Извлечь промежуточные сертификаты из файла:

/etc/letsencrypt/live/vpn.***.ru/chain.pem

файл chain.pem содержит несколько сертификатов подряд в одном PEM-файле. В рассматриваемом случае внутри файла последовательно расположены два сертификата, каждый заключён между маркерами:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Первый сертификат — промежуточный CA YR1, второй — сертификат CA Root YR.

 

2. Разделить цепочку на отдельные PEM-файлы:
   • сертификат CA YR1;
   • сертификат CA Root YR.
3. Поместить эти два новых файла  в каталог StrongSwan:

/etc/ipsec.d/cacerts/

4. Установить права:

chmod 644 /etc/ipsec.d/cacerts/*.pem

5. Перезапустить StrongSwan:

ipsec restart

6. Убедиться, что сертификаты загружены:

ipsec listcacerts

В выводе должны присутствовать как минимум:

C=US, O=Let's Encrypt, CN=YR1
C=US, O=ISRG, CN=Root YR

После добавления промежуточных сертификатов в хранилище CA StrongSwan клиент Keenetic успешно проходит проверку цепочки сертификатов и устанавливает IKEv2-соединение.

Предположительно, часть клиентов (macOS, iOS, Windows и Android) способны самостоятельно достраивать цепочку доверия по полученному сертификату, тогда как Keenetic требует корректно сформированную и доступную цепочку сертификации со стороны VPN-сервера.

Изменено 4 июня пользователем dotcom

[yrzorg]

В 04.06.2026 в 17:48, dotcom сказал:

Итак, оставлю решение здесь

Спасибо тебе, добрый человек
Целый день убил на решение, пока не наткнулся здесь