Обновен VPN сертификат: някои клиенти все още го отхвърлят

Половината от парка се свързва отново след обновяването, а три устройства отказват, всяко с предупреждение за идентичността на шлюза. Самото обновяване е рутинно. Това, което тези три устройства пазят, е закрепване към стария обект, и закрепването не е списък с CA, проверка на име или запис в хранилище за доверие. Сравнете трите механизма, преди да пипате който и да е клиент.

Едно обновяване, две поведения

Клиентите, които се свързват отново, имат решение за доверие, което все още минава, а тези, които отказват, имат изискване, което новият сертификат не удовлетворява. Тази разлика е информация, а не шум. Прочетете съобщението на отказалия клиент точно. Несъответствие на името, неизвестен издател и променен отпечатък са три различни присъди и само последната сочи към закрепване.

Проверете също кой профил е избрал отказалият клиент. Импортирано копие, което живее в собственото си хранилище, не се променя, когато администраторът редактира оригиналния файл другаде.

Обновяването заменя обекта, не само датата

Отпечатъкът идентифицира кодираното съдържание на сертификата. Обновяването създава нов сертификат, така че отпечатъкът се променя дори когато името на субекта и публичният ключ остават идентични. Това е очаквано и безвредно за клиенти, които се доверяват на CA и проверяват името. Това е фатално за клиент, конфигуриран да приема точно един сертификат, и също е фатално за клиент, чието хранилище за доверие така и не е получило новия издател.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

Вторият ред отговаря на различен въпрос: дали двойката ключове е оцеляла. Обновяване, което е използвало ключа отново, запазва тази стойност и променя само сертификата, което е точно случаят, в който администраторът е изкушен да предположи, че нищо не се е променило. Инспектирайте сертификата, който е разгърнат, а не този на машината за изграждане. Сравняването на файл в хранилище доказва какво е било генерирано, а не какво слушателят представя в момента.

Прочетете какво закрепва клиентът

Някои клиенти пазят отпечатък в профила си и го сравняват при всяка връзка. Други го съхраняват в хранилище за доверие на платформата, а трети разчитат само на CA. Поправката е различна във всеки случай, затова първо установете механизма.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Първата команда показва закрепване в конвенционален профил; втората показва отпечатъка, който крайната точка всъщност представя в момента. Когато тези две се различават, сте локализирали повредата без догадки. Не поставяйте новата стойност във всеки клиент, който се оплаква. Клиент, който отказва поради издателя, ще продължи да отказва и вие ще сте се научили, че отпечатъкът е бил проблемът, когато не е бил.

Сравнете сертификата, който представя всеки бекенд

Периодичните резултати обикновено означават повече от една крайна точка, а обновяване, приложено на един възел, оставя останалите да представят стария обект. Сравнявайте всеки бекенд по адрес, а не по споделеното име.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Пул, в който един възел изостава, обяснява клиент, който се свързва от втория опит и се проваля от първия. Той също обяснява проверка за мониторинг, която минава, докато потребителите се оплакват. Първо отстранете изоставането. Разгръщането на конфигурацията за доверие, преди всеки възел да представя новия сертификат, създава прозорец, в който нищо не работи, а разгръщането след това оставя клиентите да се провалят непредвидимо.

Променете доверието по управлявания път

Потвърдете замяната през вече доверен административен канал, преди да я приемете някъде. Правдоподобна дата на изтичане не е доказателство за собственост. Актуализирайте управляваната конфигурация чрез процеса, който я притежава, с всяко планирано застъпване на приемливи идентичности, и запазете проверката на името, която изисква разгръщането. Закрепване без проверка на име е по-слаб дизайн от доверието към CA, което е заменило.

След това проверете по клиент: свържете се, потвърдете идентичността, която е приел, и отбележете версията на сертификата, на която се доверява сега. Предупреждение, отхвърлено веднъж, има навика да се връща при следващото обновяване.