Самоподписани срещу публични CA за VPN: какво всъщност се променя

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

Сертификатът върши две работи, които се бъркат

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

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

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

Къде публичният CA си изкарва таксата

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

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

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

Къде частният CA пасва на VPN

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

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

Едно условие прави цялата схема валидна: проверката трябва да се случи. Клиент, настроен да игнорира грешки в сертификатите, приема всеки сървър, който представи какъвто и да е сертификат, така че гаранцията за самоличност изчезва, докато криптирането остава. Тази настройка е истинската слабост в повечето истории от типа "самоподписаното е несигурно".

Частният ключ на CA решава какво можете да правите по-късно

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

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

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

Проверете какво сте наследили

Преди да планирате каквато и да е промяна, прочетете сертификата, който вече имате:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

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

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