Какво проверява вашият VPN клиент, преди да се довери на сертификат

Вашият VPN клиент казва, че сертификатът не може да бъде проверен, и диалоговият прозорец спира дотам. Файлът е налице, сървърът работи, а същият профил е работил на друг лаптоп миналия месец. Под това предупреждение от един ред клиентът е прекарал сертификата на партньора през четири порти: удостоверяващ орган, който сте конфигурирали, гарантира пътя на подписа, този път стига до органа, името на партньора е това, което поискахте, и сертификатът е използваем сега за тази цел. Намерете портата, която се е затворила, и поправката обикновено е един файл; пропуснете тази стъпка и ще внасяте пакети цял следобед.

Прочетете диалога, преди да редактирате профила

Грешките за сертификати се формулират от библиотеката отдолу, а не от VPN продукта, който сте инсталирали, затова точният низ е първото ви доказателство. „Не може да се получи сертификат на локалния издател“ сочи към пътя или към котвата на доверие. „Сертификатът е изтекъл или все още не е валиден“ сочи към времето. „Неподдържано предназначение на сертификата“ сочи към разширеното използване на ключа. Несъответствието на името ви казва кое име е искал. Нито една от четирите не се поправя с преинсталиране на клиента.

Вдигнете нивото на журнала, преди да променяте каквото и да е. OpenVPN съобщава за неуспеха на проверката около ръкостискането, след като го стартирате с --verb 4, а strongSwan записва решенията си за самоличност и верига в журнала charon. След това потвърдете кой сертификат проверявате, защото хората обикновено тестват файла на диска, докато профилът вгражда по-старо копие. Когато профилът вгражда PEM блокове, тестваният сертификат е вграденият.

Удостоверяващият орган подписва самоличности, а не разрешения

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

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

Изградете отново пътя, който клиентът се опитва да изгради

Пътят тръгва от сертификата на партньора, през нула или повече междинни сертификати, до корен в хранилището ви за доверие. Липсващият междинен сертификат е най-честата повреда на веригата и от страна на клиента изглежда точно като недоверен корен. Прочетете първо листа, после оставете OpenSSL да изгради пътя от материала, който смятате да изпращате.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Нулев изходен статус означава, че пътят е изграден от тези файлове; неуспехът назовава сертификата, до който не е стигнал. Ако openssl verify успее, а клиентът продължава да отказва, разликата е в това какво реално изпраща сървърът или кой файл за доверие зарежда профилът. В OpenVPN междинните сертификати могат да пътуват във файла на сървърния сертификат или да се подават отделно с --extra-certs, а пакет с два корена, записани под едно и също име на субект, ще прати един от клиентите ви в грешния клон.

Името и предназначението са отделни порти

Изграждането на веригата никога не пита дали името е ваше. OpenVPN го проверява само когато профилът задава --verify-x509-name, а старият навик да се сравнява само общото име се чупи при сертификати, чиито самоличности живеят в subjectAltName. Внедряванията на IKEv2 сравняват конфигурираната самоличност със записи в SAN или с отличителното име, в зависимост от клиента, а стойност с заместващ знак или %any тихо изключва сравнението, което сте мислили, че имате.

Следват времето и предназначението. Лаптоп, чийто часовник бърза с няколко часа, отхвърля сертификат, който още не е валиден, а изтекъл междинен сертификат проваля пътя, докато листът е валиден. Провалите по предназначение идват от сертификат без serverAuth в разширеното използване на ключа или с keyUsage, който не позволява подписа на ръкостискането, което OpenSSL съобщава като неподдържано предназначение. Преиздайте от правилния шаблон; нищо в това съобщение не е причина да изключите проверката.

Отмяната работи само ако някой я е конфигурирал

CRL или отговор на OCSP не се търсят автоматично. На OpenVPN сървър клиентските сертификати се сверяват със списък само когато --crl-verify сочи към такъв. Проверката на сървърния сертификат от страна на клиента зависи от реализацията и често липсва. strongSwan се нуждае от приставката си за отмяна и от политика, преди да погледне CRL за партньор.

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

Ред на поправка, който запазва проверката включена

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

Минете списъка с едно преминаване: потвърдете файла, който профилът зарежда, изградете пътя сами, проверете дали сървърът изпраща междинния сертификат, сравнете часовника, прочетете SAN, прочетете EKU, после се свържете отново и гледайте как същият ред от журнала изчезва. Ако на устройство изобщо не може да се даде CA, закрепването е честната алтернатива, защото OpenVPN 2.6 приема --peer-fingerprint и стеснява доверието до един ключ, вместо да премахне проверката. RFC 5280 е справката за значението на всяко от тези полета.