Обновување на VPN сертификат без промена на неговиот идентитет

Обновување на сертификат што го менува идентитетот не е обновување, туку миграција облечена во тикет за одржување. Клиентот проверува име, синџир и понекогаш одреден клуч, и сите три можат да се сменат без да се смени датумот на истекување. Пред да побарате замена, запишете што клиентот всушност проверува: името на домаќинот или идентитетот на партнерот, намената на сертификатот, политиката за клучеви и синџирот на издавачот. Обновувањето е рутинско или координирано во зависност од тоа што од тие работи го менува замената.

Три услови ја одредуваат формата на обновувањето

Трите услови се: дали нешто го фиксира листот, дали се менува синџирот и кој друг го проверува името. Одговорете на нив од страната на клиентот, а не од удобноста на CA, бидејќи клиентот е тоа што откажува во три часот наутро.

Започнете со проверка на сертификатот што го имате. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName го печати субјектот, издавачот, периодот на важност и имињата за кои сертификатот е навистина валиден. Последното поле е најважно и најчесто се претпоставува: барање за обновување што изоставува SAN на кој клиентот се потпира создава сертификат што е технички валиден, но функционално погрешен. Копирајте ја листата SAN од стариот сертификат во барањето, наместо да ја пишувате повторно од меморија.

Прв услов: дали нешто го фиксира листот

Ако клиентите веруваат на одржуван CA и го проверуваат името, обновувањето на листот со нов клуч е невидливо за нив. Ако кој било клиент го фиксира сертификатот на листот, неговиот отпечаток или неговиот јавен клуч, замената е координирана промена со тврд премин, бидејќи старото фиксирање не може да го валидира новиот сертификат.

Откријте во кој случај сте пред да нарачате нешто. Фиксирање што никој не го документирал останува фиксирање кога ќе се скрши.

Втор услов: споредете ги фиксирањата и синџирот

Отпечатоците го прават фиксирањето проверливо: openssl x509 -noout -fingerprint -sha256 -in server.crt на стариот и на новиот сертификат, и openssl x509 -noout -pubkey за споредување на јавните клучеви. Ако конфигурацијата на клиентот, мобилниот профил или доверливото складиште на уредот содржи некоја од тие вредности, имате фиксирање. Мобилните VPN профили се често скривалиште, бидејќи профилот се дистрибуира еднаш и повеќе никогаш не се проверува.

Ако замената доаѓа од истиот посредник и клиентот веќе го има тој посредник или може да го добие, ништо не се менува на страната на довербата. Нов посредник, различен издавач или синџир доставен во погрешен редослед го претвораат обновувањето во промена на довербата, а дефектот изгледа како непознат издавач, а не како истечен сертификат.

Проверете го синџирот што серверот навистина го праќа со openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, и валидирајте го локално со openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Тоа да го направите пред промената ви дава основна линија за споредба потоа.

Трет услов: кој друг го проверува името

VPN концентратор, балансер на оптоварување, сонда за мониторинг, RADIUS или SAML интеграција и мобилен профил секој може да чува своја копија од очекуваното име или сидрото на доверба. Обновувањето е моментот кога тие копии се разидуваат, бидејќи сертификатот се менува, а копиите не.

Наведете го секој потрошувач пред промената и одлучете за секој дали му треба ажурирање. Тоа што ќе го заборавите е она што ќе ве повика.

Има и временска стапица. Проверете го почетокот на важноста, како и истекот, бидејќи сертификат подготвен за подоцнежно активирање се одбива ако се инсталира прерано, а грешката изгледа како проблем со часовникот, а не како проблем со подготовката. openssl x509 -noout -dates на новата датотека пред да ја распоредите е проверка од две секунди. Одржувајте и поддржан пат за обновување и познатата добра конфигурација, за да може неуспешното обновување да се врати со враќање на претходниот сертификат и клуч.

Распоредете, потврдете со свежа автентикација, потоа повлечете

Воспоставен тунел ја одразува валидацијата што се случила кога бил изграден, па може да изгледа здраво додека секоја нова врска не успее. Тестирајте со свежа автентикација користејќи го вистинското име на услугата што го користат клиентите.

Завршете ја проверката на ниво на апликација што му е важна на корисникот и потврдете ја испораката на синџирот од перспектива на клиентот, а не на серверот. Не потиснувајте ги проверките на името или сертификатот за да го задржите преминот тивок; тоа претвора привремен проблем со компатибилноста во траен.

Повлечете го застарен материјал само откако распоредувањето ќе биде потврдено, а компромитираниот клуч третирајте го како сосема друг случај: самото обновување не отповикува ништо, па засегнатиот идентитет бара процес за отповикување и управување со сесии на распоредувањето. RFC 5280 ги дефинира правилата за сертификати и валидација на патеката врз кои лежи сето ова. Држете го рутинското обновување на листот одвоено од замена на CA, за да не се бара од клиентите да веруваат на нов издавач без причина.