Несъответствие в името на сертификата или изтичане: как да ги различим

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

Текстът на грешката е диагнозата

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

Четете ги на етапа, на който се появяват. Отказ по време на ръкостискането е проблем със сертификата, а отказ след вдигане на тунела е проблем с маршрутизирането или идентификационните данни. Задържането на етапа е това, което не позволява на разследването да се отклони към несвързани настройки.

Ако отказът се различава между опитите, имате трета възможност: повече от един възел зад едно и също име.

Проверки на името: какво сравнява клиентът

Клиентът сравнява самоличността, която е бил настроен да очаква, с имената в сертификата, които живеят в разширението subjectAltName. Суров IP в профила, псевдоним, който сертификатът не изброява, или име, което просто се разрешава до същия сървър, всички се провалят на тази проверка. Да достигнете правилната машина не е същото като да представите правилната самоличност.

Прегледайте сертификата, който сървърът действително представя, вместо файл от по-ранен опит. Командата по-долу пита за името, което сте настроили, така че отговорът включва сертификата, който реален клиент би видял.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Сертификат от доверен издател все още може да е за друга услуга. Дръжте проверките на името в клиента включени, защото доверието към CA не оторизира всяко име, което този CA някога е подписвал. Изключването на проверката превръща конфигурационна грешка в излагане.

Изтичане: чий часовник се чете

Валидността е двойка времеви отпечатъци и проверяващият ги сравнява със собствения си часовник. Устройство с грешен часовник съобщава валиден сертификат като изтекъл или като все още невалиден и поправката е часовникът, а не сертификатът. Разлика в показването на часовата зона не е същото като грешно подлежащо време.

Сравнете датите на сертификата с UTC на клиента, преди да заключите нещо:

openssl x509 -in cert.pem -noout -dates
date -u

Ако датите наистина са отминали, подновете чрез издателя. Ако съществува замяна, но тя още не е станала валидна, следвайте поддържаното преминаване, вместо да местите часовника, за да я нагодите. Връщането на датата на устройство назад, за да удовлетвори сертификат, е решение с последствия далеч отвъд тунела.

Защо поправянето на едното разкрива другото

Валидацията изпълнява поредица от проверки и първият отказ спира доклада. Поправете името и клиентът може после да ви каже, че веригата е непълна или че сертификатът е изтекъл. Това не означава, че първата проверка е била ненужна. Означава, че веригата е имала повече от един проблем, така че очаквайте втората грешка, вместо да я четете като доказателство, че първата поправка е била грешна.

Множеството възли влошават това. Услуга с балансиране на натоварването може да представя различни сертификати от различни членове, така че тест, който минава два пъти и се проваля веднъж, говори за флота, а не за вашия клиент. Дръжте адреса на партньора и времето на опита в диагнозата.

Тази подробност превръща нестабилния тикет във възпроизводим.

Докажете го с ново свързване

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

Запазете точния етап на грешката и подробностите за сертификата с тикета.

Този запис спира следващия човек да нулира пароли на акаунти заради проблем със сертификат. Самоличността и валидността са отделни въпроси и RFC 5280 е справката за това как се оценява вторият.