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