Selfonderteken vs. openbare CA vir 'n VPN: wat werklik verander

Jy bereik die sertifikaatbladsy van 'n VPN-opstelling, sien 'n gratis selfondertekende opsie langs 'n betaalde openbare CA, en die vraag klink na 'n sekuriteitskeuse. Dit is eintlik 'n keuse oor die gehoor. Albei opsies versleutel die tonnel met dieselfde kriptografiese boustene, en albei word waardeloos as die privaatsleutel lek. Wat hulle skei, is wie die bewering oor die bediener se identiteit maak, en wie in 'n posisie is om daardie bewering te kontroleer.

'n Sertifikaat doen twee take wat verwar word

'n Sertifikaat bind 'n openbare sleutel aan 'n naam, en die sleutel doen die versleutelings- en ondertekeningswerk. Die handtekening op die sertifikaat is 'n aparte verklaring: een of ander owerheid het nagegaan dat die naam aan hierdie sleutelhouer behoort. 'n Selfondertekende sertifikaat maak daardie verklaring oor homself, wat glad geen derdeparty-bewering is nie.

Openbare webwerwe het die derdeparty-weergawe nodig, want besoekers kom sonder enige vooraf verhouding en maak staat op 'n blaaier se vertrouensberg. 'n VPN-kliënt is nie 'n vreemdeling nie. Jy gee dit die CA-sertifikaat, of pen die bedienersertifikaat vas, binne die profiel wat dit installeer, sodat verifikasie teen presies die owerheid wat jy gekies het, plaasvind. Geen kommersiële CA hoef betrokke te wees vir daardie kontrole om iets te beteken nie.

Die sterkte van die gevolglike sessie kom van die sleutelgrootte en versleutelingsuite, nie van die ondertekenaar nie. Daarom is dit eenvoudig verkeerd om 'n selfondertekende sertifikaat "minder versleutel" te noem; dit word minder wyd gewaarborg, wat 'n ander eienskap is.

Waar 'n openbare CA sy fooi verdien

Die duidelikste geval is die administrasiebladsy. As kollegas, kontrakteurs of enigiemand anders sonder 'n voorbereide profiel die VPN-bediener se webkoppelvlak moet oopmaak sonder 'n blaaierwaarskuwing, verwyder 'n publiek vertroude sertifikaat daardie wrywing. Die blaaier vertrou reeds die ondertekenaar, so daar is niks om in te voer en niks om te verduidelik nie.

Daardie gerief het koste wat die moeite werd is om voor jou aankoop te noem. Hernuwing moet geoutomatiseer word, anders breek die werf volgens 'n skedule, openbare sertifikate stel die gasheernaam in sertifikaat-deursigtigheidslogboeke bloot, en uitreikingskoerslimiete straf 'n skrip wat te gretig herprobeer. Nie een daarvan is redes om 'n openbare CA te vermy nie, maar dit is operasionele werk wat 'n private CA elders plaas.

Wat 'n openbare sertifikaat nie doen nie, is om jou gebruikers te verifieer. Kliëntidentiteit is 'n aparte besluit, geneem met kliëntsertifikate, wagwoorde of 'n tweede faktor, en die CA wat die bediener onderteken, sê niks oor wie daarmee mag verbind nie.

Waar 'n private CA by 'n VPN pas

Vir 'n private VPN met 'n bekende stel kliënte is dit die konvensionele keuse om jou eie CA te bestuur. Jy skep die CA een keer, onderteken die bedienersertifikaat met 'n naam wat die kliënte sal gebruik, en versprei die CA-sertifikaat binne elke profiel. Elke kliënt verifieer dan die bediener teen jou owerheid, en geen buitestaander leer die gasheernaam nie.

Die koste is werklik maar beperk. Blaaiers sal waarsku wanneer iemand die admin-bladsy direk oopmaak, want die blaaier het geen rede om jou CA te vertrou nie. Profielverspreiding word deel van die aanboordproses, en om die CA te roteer beteken om elke kliënt aan te raak. Dit is aanvaarbare pryse vir 'n diens met tien of vyftig bekende gebruikers en pynlik vir 'n openbare eindpunt met duisende.

Een voorwaarde maak die hele reëling geldig: verifikasie moet plaasvind. 'n Kliënt wat ingestel is om sertifikaatfoute te ignoreer, aanvaar enige bediener wat enige sertifikaat voorlê, so die identiteitswaarborg verdwyn terwyl die versleuteling bly. Daardie instelling is die werklike swakheid in die meeste verhale van "selfondertekend is onveilig".

Die CA se privaatsleutel bepaal wat jy later kan doen

Die verrassing kom gewoonlik maande later, wanneer jy 'n toestel wil byvoeg. Om 'n kliëntsertifikaat uit te reik vereis die CA se privaatsleutel, en dieselfde geld vir die maak van 'n herroepingslys. As jy 'n bediener geërf het wat die sertifikaat- en sleutellêers het maar nie die CA-sleutel nie, kan jy niks nuuts onderteken nie. Jou opsies is om die PKI te herbou en elke kliënt 'n nuwe CA-sertifikaat te gee, of om oor te skakel na wagwoordverifikasie, wat 'n ander sekuriteitsmodel is en nie herstel wat verlore gegaan het nie.

Twee kleiner strikke lê in dieselfde gebied. Die easy-rsa-skripte aanvaar dat jy in die gids staan wat hulle huisves, so 'n ontbrekende-lêer-fout beteken gewoonlik die verkeerde ligging eerder as 'n beskadigde installasie. En 'n ontwerp wat net op sertifikate staatmaak, is heeltemal wettig: jy kan kliëntsertifikate vereis sonder 'n vooraf gedeelde sleutel, mits elke kliënt een het en die bediener die ketting verifieer.

Reik een sertifikaat per toestel uit eerder as een gedeelde kliëntsertifikaat vir die hele span. 'n Verlore skootrekenaar kos jou dan 'n enkele herroeping in plaas van 'n heruitreiking vir almal.

Kontroleer wat jy geërf het

Voordat jy enige verandering beplan, lees die sertifikaat wat jy reeds het:

$ 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

As die uitreiker gelyk is aan die onderwerp, is die sertifikaat selfonderteken, wat 'n ontwerpkeuse eerder as 'n fout is. Die datums vertel jou wanneer hernuwing iemand se probleem word, en 'n suksesvolle verifikasie teen die CA wat jy van plan is om te verskeep, bevestig dat die ketting werk voordat 'n enkele kliënt dit probeer.

Kies dan volgens gehoor en verspreiding: openbare CA wanneer onbekende blaaiers die admin-bladsy moet vertrou, private CA wanneer elke kliënt 'n profiel ontvang wat jy beheer. Nie een antwoord is meer versleutel as die ander nie.