Едно общо име, два сертификата: списък с разрешени или отнемане?

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

Започнете с политиката за именуване, която използва сървърът

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

Прочетете конфигурацията на сървъра и отбележете кой източник на самоличност се използва. username-as-common-name прави удостовереното потребителско име ефективното име за справки, специфични за клиента. Без него се използва общото име на субекта от сертификата. Какъвто и да е отговорът, запишете го, преди да докоснете който и да е списък с разрешени.

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

Проверете какво всъщност допуска клиент

Директивата client-config-dir със съответстващ файл предоставя опции за отделния клиент; сама по себе си тя не е правило за допускане. Допускането по име изисква ccd-exclusive, който отказва клиенти без съответстващ файл. Включването му в работещо внедряване прекъсва всички, чието име няма файл, затова пребройте файловете, преди да превключите каквото и да е.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Броят е проверката: сравнете съдържанието на директорията със самоличностите, които очаквате да се свържат.

След това потвърдете, че всяко име на файл съвпада точно с ефективната самоличност, включително регистъра и интервалите. Файл за office-laptop не прави нищо за сертификат, чийто субект е Office-Laptop. Интервалите в края също се скриват от обикновен списък и така файл, който изглежда наличен, остава непрочетен.

Проверете CRL, който зарежда шлюзът

CRL изброява отнетите сертификати по издател и сериен номер — това е подробността, която проверката на името няма. Два сертификата могат да споделят общо име и да се различават по сериен номер, и само списък на ниво сериен номер ги разделя.

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

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

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

Заменете, после докажете и двата изхода

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

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

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

Какво проверката на името никога не може да направи

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

Където е необходим контрол на ниво сертификат, използвайте механизъм, който назовава сертификата: записи в CRL или hook за проверка, който проверява отпечатък, поддържан от оператора. И двете изискват поддръжка и двете са честни относно обекта, който изследват. Ръководството на OpenVPN 2.6 документира crl-verify и допускането на конкретни клиенти като отделни опции поради тази причина.

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