Wat jou VPN-kliënt nagaan voordat dit ’n sertifikaat vertrou

Jou VPN-kliënt sê die sertifikaat kon nie geverifieer word nie, en die dialoog stop daar. Die lêer is teenwoordig, die bediener is aan die gang, en dieselfde profiel het verlede maand op ’n ander skootrekenaar gewerk. Onder daardie eenreël-waarskuwing het die kliënt die eweknie-sertifikaat deur vier hekke gehardloop: ’n sertifikaatowerheid wat jy opgestel het, borg die handtekeningpad, daardie pad bereik die owerheid, die eweknie-naam is die een wat jy gevra het, en die sertifikaat is nou vir hierdie doel bruikbaar. Vind die hek wat gesluit het, en die herstel is gewoonlik een lêer; slaan daardie stap oor en jy sal die hele middag bondels herinvoer.

Lees die dialoog voordat jy die profiel wysig

Sertifikaatfoute word deur die onderliggende biblioteek geformuleer, nie deur die VPN-produk wat jy geïnstalleer het nie, so die presiese string is jou eerste bewys. ’Kan nie plaaslike uitreiker-sertifikaat kry nie’ wys op die pad of op die vertrouensanker. ’Sertifikaat het verval of is nog nie geldig nie’ wys op tyd. ’Nie-ondersteunde sertifikaatdoel’ wys op uitgebreide sleutelgebruik. ’n Naamwanpassing vertel jou watter naam dit wou hê. Nie een van die vier word deur die herinstallasie van die kliënt herstel nie.

Verhoog die joernaal voordat jy enigiets verander. OpenVPN rapporteer die verifikasiefout rondom die handdruk sodra jy dit met --verb 4 uitvoer, en strongSwan teken sy identiteit- en kettingbesluite in die charon-log aan. Bevestig dan watter sertifikaat jy ondersoek, want mense toets gereeld die lêer op skyf terwyl die profiel ’n ouer kopie inlyn plaas. Wanneer die profiel PEM-blokke insluit, is die ingeslote sertifikaat die een wat getoets word.

Sertifikaatowerheid onderteken identiteite, nie toestemmings nie

Die owerheid hou ’n naam en ’n ondertekeningsleutel. Dit reik sertifikate uit wat ’n publieke sleutel aan daardie naam bind onder sy eie beleid, met ’n geldigheidsvenster en gebruiksbeperkings daaraan geheg. Jou kliënt benodig net die owerheidsertifikaat om die uitreiker te herken; dit het nooit die ondertekeningsleutel nodig nie, en om daardie sleutel aan kliënte te stuur, sou die vermoë weggee om enige identiteit te skep wat die ontplooiing vertrou.

Om ’n owerheid te vertrou, maak elke sertifikaat wat dit onderteken het ’n kandidaat, nie die regte eweknie nie. ’n Webbediener-sertifikaat van dieselfde interne CA is ook ’n kandidaat. Dit is waarom die naam- en doelhekke bestaan, en waarom ’n gekompromitteerde CA-sleutel meer saak maak as enige enkele bediener: dit bereik elke identiteit wat die owerheid ooit uitgereik het. Deel kliëntsertifikate per toestel uit, sodat ’n verlore skootrekenaar een herroeping is in plaas van ’n her-sleuteling oor die hele ontplooiing.

Bou die pad weer wat die kliënt probeer bou

Die pad loop van die eweknie-sertifikaat, deur nul of meer tussenliggende sertifikate, na ’n wortel in jou vertrouenswinkel. ’n Ontbrekende tussenliggende sertifikaat is die mees algemene kettingfout, en van die kliënt se kant lyk dit identies aan ’n onvertroude wortel. Lees eers die blaar, en laat OpenSSL dan die pad bou uit die materiaal wat jy van plan is om te stuur.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Uittree-status nul beteken die pad is uit daardie lêers gebou; ’n fout noem die sertifikaat wat dit nie kon bereik nie. As openssl verify slaag terwyl die kliënt steeds weier, lê die verskil in wat die bediener werklik stuur of in watter vertrouenslêer die profiel laai. In OpenVPN kan tussenliggende sertifikate saamry in die bediener-sertifikaatlêer of afsonderlik verskaf word met --extra-certs, en ’n bondel met twee wortels onder dieselfde vaknaam sal een van jou kliënte die verkeerde tak instuur.

Naam en doel is aparte hekke

Kettingbou vra nooit of die naam joune is nie. OpenVPN kontroleer dit net wanneer die profiel --verify-x509-name stel, en die ouer gewoonte om net die algemene naam te pas, breek op sertifikate wie se identiteite in subjectAltName leef. IKEv2-ontplooiings pas die opgestelde identiteit teen SAN-inskrywings of teen die onderskeidende naam, afhangende van die kliënt, en ’n wildcard- of %any-waarde skakel stilweg die vergelyking af wat jy gedink het jy het.

Tyd en doel kom volgende. ’n Skootrekenaar wie se klok ’n paar uur vinnig loop, verwerp ’n sertifikaat wat nog nie geldig is nie, en ’n vervalde tussenliggende sertifikaat laat die pad misluk terwyl die blaar geldig is. Doelfoute kom van ’n sertifikaat sonder serverAuth in uitgebreide sleutelgebruik, of met ’n keyUsage wat nie die handdruk-handtekening toelaat nie, wat OpenSSL as ’n nie-ondersteunde sertifikaatdoel rapporteer. Heruitreik uit die regte sjabloon; niks in daardie boodskap is ’n rede om verifikasie af te skakel nie.

Herroeping loop net as iemand dit opgestel het

’n CRL of ’n OCSP-antwoord word nie outomaties geraadpleeg nie. Op ’n OpenVPN-bediener word kliëntsertifikate net teen ’n lys nagegaan wanneer --crl-verify na een wys. Kliëntkant-kontrole van die bediener-sertifikaat hang van die implementering af en is dikwels afwesig. strongSwan benodig sy herroepingsinprop en ’n beleid voordat dit vir ’n eweknie na ’n CRL kyk.

Dit verduidelik die kaartjie wat jy uiteindelik sal kry: ’n herroepte kliëntsertifikaat verbind steeds, en almal kom tot die gevolgtrekking dat herroeping stukkend is. Niks het gekontroleer nie. Publiseer en verfris die CRL, of hou kliëntsertifikate kort genoeg dat ’n verouderde herroeping net kortliks saak maak, en oefen die herroepingspad op ’n laboratoriumsertifikaat voordat jy dit tydens ’n voorval nodig het.

Herstelorde wat verifikasie aan hou

Sorteer volgens simptoom voordat jy aan lêers raak, want elke ry van die tabel stuur jou na ’n ander objek.

Werk die lys in een deurgang: bevestig die lêer wat die profiel laai, bou die pad self, kontroleer dat die bediener die tussenliggende sertifikaat stuur, vergelyk die klok, lees die SAN, lees die EKU, en herverbind dan en kyk hoe dieselfde logreël verdwyn. As ’n toestel glad nie ’n CA gegee kan word nie, is vaspen die eerlike alternatief, want OpenVPN 2.6 aanvaar --peer-fingerprint en vernou vertroue tot een sleutel in plaas van om die kontrole te verwyder. RFC 5280 is die verwysing vir wat elkeen van daardie velde beteken.