Selfondertekende kliëntsertifikaat? Die VPN-bediener weier dit steeds

Die operateur stuur 'n adres en 'n gebruikersnaam, en die kliënt vra vir 'n CA-lêer, 'n sertifikaat en 'n sleutel. Om dié drie plaaslik te skep voel soos die ooglopende volgende stap. Dit lewer 'n sertifikaat waarin net jou eie masjien glo. Die bediener se vertroue is geanker in 'n CA wat jy nie beheer nie, so die handskud eindig voordat dit begin.

Vertroue leef op die bediener, nie in jou profiel nie

Sertifikaatverifikasie is 'n vergelyking. Die kliënt wys 'n sertifikaat; die poort kontroleer of dit deur een van die CA's in sy konfigurasie onderteken is.

Jou profiel noem die CA-lêer wat die kliënt moet gebruik om die bediener te verifieer. Dit kan nie 'n CA noem wat die bediener moet gebruik om jou te verifieer nie. Daardie helfte van die konfigurasie is nie joune nie.

’n Selfgemaakte sertifikaat faal hierdie vergelyking selfs wanneer dit tegnies perfek is. Dit het ’n geldige handtekening, ’n onderwerp en datums, maar die uitreiker is ’n CA waarvan die poort nog nooit gehoor het nie. Die fout verskyn tydens die handskud, nadat die bediener reeds om ’n sertifikaat gevra het. Niks in die kliëntprofiel kan die antwoord verander nie.

Waarom ’n selfondertekende sertifikaat nie kan instaan nie

’n Selfondertekende sertifikaat word deur sy eie sleutel onderteken. Die handtekening verifieer teen dieselfde lêer, wat dit selfkonsistent en nutteloos maak as ’n geloofsbrief vir iemand anders se poort.

Die poort vra nie of die sertifikaat intern konsekwent is nie. Dit vra of ’n vertroude uitreiker dit onderteken het.

Dit is waarom die foutboodskappe verwarrend is. Die kliënt kan ’n verifikasiefout rapporteer wat soos ’n bedienerprobleem klink, terwyl die bediener ’n onbekende uitreiker log. Albei beskryf dieselfde wanverhouding van teenoorgestelde kante.

Die CSR-pad behou jou private sleutel

Jy kan steeds die meeste werk plaaslik doen. Skep ’n sleutelpaar, bou ’n sertifikaatondertekeningsversoek rondom die publieke helfte en stuur daardie versoek aan die operateur. Net die versoek verlaat jou masjien. Die private helfte bly waar jy dit geskep het.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Die operateur onderteken die versoek met hul CA en stuur ’n sertifikaat terug. Jou private sleutel het nooit gereis nie, en die resultaat koppel aan die anker wat die poort vertrou.

Bestuurde dienste slaan die CSR dikwels oor en lewer die hele bondel. Dit is ’n redelike ruil wanneer dieselfde verskaffer reeds die tonnel beëindig en die CA hou. Die sleutel se bewaring word nie verbeter deur dit te hou nie, want die verskaffer kan enige tyd ’n nuwe een skep.

Bondels word ingevoer, nie geïnstalleer nie

Verskaffersbondels met veiligheidsklinkende name is dikwels OpenVPN-profiele. Hulle bevat konfigurasie en soms sertifikate, en hulle installeer niks nie. Voer die lêer in ’n kliënt wat die protokol praat, en die verbinding is opgestel.

Die hanteringsreël volg uit die inhoud. As die profiel ’n private sleutel insluit, is dit ’n geloofsbrief en verdien dit dieselfde sorg as ’n wagwoord: geen e-pos, geen bewaarplek, geen gedeelde aflaaisgids nie. Wanneer die operateur ca.crt, client.crt en client.key afsonderlik stuur, bêre hulle saam met beperkende regte en wys die profiel daarheen.

Voeg die kontroles by wat die operateur dalk oorgeslaan het

’n Routergegenereerde profiel het soms geen eweknie-verifikasie nie. remote-cert-tls server vereis dat die eweknie-sertifikaat die bedienerverifikasiedoeleinde dra, sodat ’n kliëntsertifikaat nie as ’n bediener herspeel kan word nie. Daardie een reël is ’n klein verandering met ’n duidelike regverdiging.

verify-x509-name gaan verder wanneer die operateur die verwagte onderwerp of SAN kan noem. Albei is klein byvoegings tot ’n profiel, en albei is verdedigbaar. Inspekteer wat jy ontvang het voordat jy dit invoer.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Verifikasie-instellings is nie ’n herstelling vir ’n gebroke ketting nie. As die uitreiker verkeerd is, is die antwoord ’n sertifikaat van die regte CA, nie ’n vlag wat kontrole afskakel nie. Om verifikasie af te skakel, verander ’n verifikasiefout in ’n onopgemerkte een.

Vra vir een bondel: die gesagssertifikaat as PEM, ’n kliëntsertifikaat wat daardie gesag onderteken het, ’n sleutel wat jy geskep het of wat deur ’n kanaal gekom het wat jy vertrou, en die presiese bedienernaam wat die sertifikaat moet wys. Noteer die vervaldatum in dieselfde boodskap, want ’n vervalle sertifikaat lyk maande later soos ’n netwerkfout.