SoftEther ServerCertSet: імпорт оновленого ланцюга через vpncmd

Certbot повідомляє про успішне оновлення, файли на диску мають нові дати, а клієнти досі зустрічають стару ідентичність. SoftEther тримає свій SSL-сертифікат сервера у власній конфігурації на рівні сервера, тому новий файл на диску нічого не змінює, доки не імпортовано лист і його ключ. Наведена нижче послідовність охоплює один ручний імпорт, обгортку, яка запускається після кожного оновлення, і перевірку, яка читає, що слухач насправді представляє. Кожен крок залишає докази, які можна порівняти після наступного оновлення.

Оновлений файл не змінює ідентичність сервера

Видача і розгортання — окремі події з окремими режимами відмови. Клієнт ACME записує файли в каталог лінії та фіксує успіх; SoftEther продовжує використовувати сертифікат, який останнім було завантажено в його конфігурацію. Тому нульовий код виходу описує файли, а не службу, і ці двоє можуть розходитися, поки ніхто не дивиться. Вважайте імпорт кроком розгортання, а оновлення — його входом.

Ця різниця пояснює і заплутану половинчасту відмову: старий сертифікат працює до закінчення терміну, тому спочатку ніщо не виглядає зламаним. Коли термін спливає, усі клієнти відмовляють одночасно, що виглядає як збій, а не як пропущений крок розгортання. Перевірка представленої ідентичності після кожного оновлення перетворює цей сюрприз на рутинне спостереження.

Виберіть виклик, що підходить слухачу

Сертифікат має називати хост, який перевіряють клієнти, тому використовуйте публічне DNS-ім'я, а не внутрішню мітку чи адресу. HTTP-01 вимагає, щоб на виклик відповіли на порту 80 на мить, що є тимчасовим слухачем і ніколи не причиною переносити власний порт SoftEther. DNS-01 доводить контроль через запис і зовсім не потребує вхідного HTTP.

Оновлення без нагляду означає автоматизовану інтеграцію DNS з обліковими даними, обмеженими однією зоною, а не запис TXT, який вручну вводять раз на два місяці. Підстановчий знак змінює тип виклику, а не потребу в цій автоматизації. Вирішіть це до появи першого сертифіката, бо зміна типу виклику пізніше означає одночасно торкатися конфігурації клієнта і брандмауера.

Тримайте артефакти в порядку, поки ви тут. Лист і проміжні сертифікати надходять окремими файлами і одним об'єднаним файлом ланцюга, закритий ключ знову окремо, а імпорту потрібен ланцюг із відповідним ключем, а не публічний сертифікат сам по собі.

Імпортуйте ланцюг на рівні сервера

Зробіть резервну копію конфігурації сервера і підтвердьте, що ви ще досягаєте інтерфейсу керування, перш ніж торкатися сертифіката. Підключайтеся як адміністратор сервера, а не як адміністратор Virtual Hub, бо сертифікат належить об'єкту сервера. Потім завантажте ланцюг і ключ за абсолютним шляхом, із файлів, які може читати обліковий запис, що виконує команду. Зверніть увагу, що шляхи абсолютні, бо команда розв'язує їх із робочого каталогу того процесу, який запустив vpncmd:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

Читайте вивід команди, а не припускайте успіх, і потім перечитайте ланцюг, а не довіряйте переданому файлу. Межа між збірками, які імпортують весь пакет PEM, і збірками, які беруть лише перший сертифікат, не задокументована в одному місці, тому саме перевірка вирішує це для збірки перед вами. Порахуйте сертифікати, які представляє слухач; лист без проміжних — це підпис імпортера, що витратив лише перший блок.

Тримайте імпортований ключ читабельним лише для облікового запису, який запускає сервер, і тримайте пароль керування поза історією оболонки. Під час цього першого імпорту введіть пароль у запрошенні, а не передавайте його аргументом команди. Ці дві звички нічого не коштують і усувають найпоширеніший спосіб, яким розгортання сертифіката розкриває те, що мав захищати. Зробіть це до першого імпорту, а не після.

Підключіть розгортання, а не оновлення

Коли ручний імпорт працює, покладіть саме ці кроки в невелику обгортку і викличте її з клієнта ACME після успішного оновлення. Certbot встановлює для хука RENEWED_LINEAGE і RENEWED_DOMAINS, тому обгортка може діяти на один сертифікат на машині, що керує кількома. Фільтруйте за лінією, а не реагуйте на кожне оновлення на хості. Обгортка — це код розгортання, що працює з правами сервера, тому перегляньте її як будь-який інший скрипт у цій ролі.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

Хук, що працює без нагляду, потребує власного захищеного сховища облікових даних і сигналу про відмову, який доходить до людини. Якщо видача вдалася, а імпорт не вдався, повторіть імпорт, а не запитуйте інший сертифікат, бо другий запит приховує дефект розгортання за новим файлом. Документація Certbot про оновлення ясно каже, що запуск, який нічого не оновлює, є нормальним результатом, тому саме хук розрізняє ці два випадки.

Порівняйте представлений ланцюг із файлом

Читайте слухач, а не диск. Підключіться до порту, оберненого до клієнтів, з ім'ям сервера, яке використовують клієнти, потім порівняйте відбиток і доставлений ланцюг із лінією, яку встановив хук. Дві команди охоплюють це, і перша також показує, чи проміжні взагалі надходять:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

Потім створіть нове клієнтське з'єднання, бо сеанси, встановлені до імпорту, були автентифіковані за попередньою ідентичністю і нічого не доводять про нову. Якщо клієнти закріплюють старий лист, їм потрібне узгоджене оновлення навіть коли публічний ланцюг чинний, і це завдання належить до того самого runbook, що й оновлення. Зворотний проксі перед службою може представляти добрий сертифікат, поки слухач VPN ще тримає старий, і саме тому перевірка має називати порт, до якого клієнти справді доходять. Запишіть відбиток поруч із датою оновлення, щоб наступне порівняння було перевіркою, а не актом пам'яті.