’n OpenVPN-profiel het drie sertifikaatblokke: watter een is geheim?

Jy maak ’n .ovpn-lêer oop om een reël te verander en vind drie blokke base64 wat almal soos geloofsbriewe lyk. Een is veilig om te publiseer, een is so sensitief soos ’n wagwoord, en een is ’n publieke sleutel wat niks beteken tensy iets anders met sy paar onderteken het. Mense plak die hele lêer in ’n ondersteuningsdraad omdat die blokke uitruilbaar lyk, en dit is hoe ’n kliëntsleutel in ’n openbare argief beland. Om uit te sorteer watter blok wat doen, verduidelik die meeste van die verwarring rondom hierdie profiele, en dit sê ook vir jou watter mislukkings joune is om reg te maak.

Een lêer, drie blokke, verskillende take

’n Tipiese profiel sluit ’n ca-blok, ’n cert-blok en ’n key-blok tussen BEGIN- en END-merkers in, of verwys na dieselfde drie as afsonderlike lêers. Sommige profiele voeg ’n vierde blok by vir ’n tls-auth- of tls-crypt-sleutel, wat ’n gedeelde geheim is eerder as ’n sertifikaat. Die kliënt lees elke blok volgens die opdrag wat dit benoem, so die etikette maak meer saak as die volgorde waarin hulle voorkom.

Behandel die saamgestelde profiel as sensitief totdat jy werklik binne gekyk het. ’n Openbare sertifikaat en ’n private sleutel kan ’n paar reëls uitmekaar in dieselfde lêer sit, en ’n skermkiekie wat die kop bevat, kan albei bevat. Om die sigbare base64 met die hand te redigeer is ook onbetroubaar, want ’n gedeeltelike blok leksteeds die sertifikaatmetadata wat jou ontplooiing benoem. Om die drie opdragte sonder hul waardes te kopieer, is gewoonlik genoeg om ’n nuttige vraag te vra.

Die opdragte rondom die blokke bepaal hoe hulle gebruik word. Verander ca en die kliënt vertrou ’n ander owerheid; verander cert sonder om key te verander en die handshake misluk met ’n wanpassing wat niks met vertroue te doen het.

Die CA-blok is openbaar, die CA-sleutel nooit nie

’n Sertifikaatowerheid onderteken sertifikate wat ’n publieke sleutel aan ’n identiteit bind, en sy eie sertifikaat is die anker wat ’n kliënt gebruik om te besluit of ’n ketting betroubaar is. Daardie sertifikaat is openbaar deur ontwerp: om dit in elke profiel te verskeep is normaal, en dit is die rede waarom ’n selfondertekende ontplooiing sonder ’n kommersiële owerheid kan werk.

Wat nooit in ’n kliëntprofiel moet verskyn nie, is die owerheid se private ondertekeningssleutel. Die kliënt het dit nie nodig om enigiets te valideer nie, en die teenwoordigheid daarvan beteken enigiemand wat die profiel het, kan nuwe identiteite vir die hele ontplooiing skep.

Om ’n owerheid te vertrou is ook nouer as wat dit klink. ’n Kliënt wat enige sertifikaat aanvaar wat deur die CA onderteken is, sal steeds ’n sertifikaat aanvaar wat vir ’n ander diens op dieselfde CA uitgereik is. Opsies wat die verwagte bedienerrol of -naam vaspen, sluit daardie gaping, en die TLS-opsieverwysing lys die verifikasie-opdragte wat dit doen.

Bediener- en kliëntsertifikate wys in teenoorgestelde rigtings

Die bediener se sertifikaat is wat die kliënt ondersoek om te bevestig dat dit die regte eindpunt bereik het. Jou kliëntsertifikaat werk die ander kant toe: die bediener gebruik dit om te besluit dat hierdie toestel of gebruiker een is wat hy ingeskryf het. Dieselfde formaat, teenoorgestelde rigting van vertroue.

’n Adres is nie ’n identiteit nie. Om die regte IP te bereik bewys niks oor wie geantwoord het nie, en daarom hoort kontrole van gasheernaam of sertifikaatnaam steeds in die profiel. ’n Rekeningwagwoord vervang ook nie stilletjies ’n vereiste kliëntsertifikaat nie, want die twee word op verskillende stadiums nagegaan en ’n ontplooiing kan albei vereis.

Die kliënt se private sleutel is die deel wat privaat moet bly. As dit moontlik blootgestel is, verander die verwydering van die lêer op jou skootrekenaar niks op die bediener nie, wat die ooreenstemmende sertifikaat sal bly aanvaar totdat die operateur dit herroep. Om die operateur te vra om daardie identiteit te vervang of te herroep, is die enigste oplossing wat saam met jou reis.

Twee vrae wat identies lyk en nie is nie

’n Sleutel wat in geënkripteerde vorm gestoor is, vra ’n wagfrase voordat die kliënt dit kan gebruik. Die VPN-diens kan afsonderlik ’n rekeningwagwoord vra, en die twee vrae kan sekondes uitmekaar verskyn met byna dieselfde bewoording. Die wagfrase beskerm ’n lêer op jou skyf; die wagwoord bewys ’n rekening aan ’n bediener. Om hulle te verwar stuur mense na wagwoordhernuwings wat onmoontlik kan help.

Lees die vraag voordat jy enigiets terugstel. ’n Rekeningwagwoord-terugstelling doen niks vir ’n vergeete sleutelwagfrase, ’n herroepte sertifikaat of een wat verval het nie, en om die wagwoord terug te stel wanneer die fout sertifikaatvalidering is, maak ’n oplossing van twee minute ’n ondersteuningsgeval. As die klag geldigheidsdatums noem, kyk eers na die toestel se klok en dan na die genoemde sertifikaat se eie venster.

Wanneer die sertifikaat werklik verval het, moet die vervanging van diegene kom wat dit uitgereik het. ’n Sleutel wat aan iemand anders behoort, is nie ’n hernuwingspad nie, en om ’n werkende profiel by ’n kollega te leen is ook nie.

Wat ’n skoon handshake bewys en nie bewys nie

Om ’n voltooide TLS-handshake te bereik beteken die gekonfigureerde identiteitsverhouding het gehou: die bediener se sertifikaat het aan jou CA geketting en jou sertifikaat is aanvaar. Dit sê niks oor die operateur se logbeleid nie, en niks daaroor of jou toepassings sal werk sodra die tonnel op is nie.

Roetes en DNS is later stadiums van die verbinding, so ’n onbereikbare intranet-gasheer ná ’n suksesvolle aanmelding is ’n verbindingsprobleem eerder as ’n sertifikaatprobleem. Werk daardie laag eerder as om geloofsbriewe te ruil, en hou die profiel se oorsprong, sy private materiaal en sy identiteitskontroles saam wanneer jy dit aan iemand gee.