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-а још држи стари, и зато провера мора да именује порту коју клијенти заиста достижу. Запишите отисак поред датума обнављања, да следеће поређење буде провера, а не чин памћења.