Самопотпишан наспроти јавен 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 кога секој клиент добива профил што вие го контролирате. Ниту еден одговор не е повеќе шифриран од другиот.