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