Herroepde VPN-sertifikaat maak steeds verbinding? Toets CRL-handhawing

Jy het die sertifikaat herroep, 'n nuwe lys geskep, en die ou profiel bring steeds 'n tonnel op. Aan die herroeping self is niks fout nie: 'n CRL is 'n ondertekende verklaring dat 'n reeksnommer nie meer geldig is nie, en dit verander toegang eers wanneer die komponent wat TLS beëindig dit laai, vir die regte uitreiker, voordat dit die aanvaardingsbesluit neem. Daardie laaste deel is waar die meeste van hierdie gevalle lê, en dit is waarom herroeping en weiering twee aparte feite is.

Werk die vyf kontroles hieronder in volgorde deur, en stop by die eerste een wat nie hou nie, want elke latere kontrole aanvaar dat die vroeëres waar is.

Toets watter komponent die aanvaardingsbesluit neem

Noem die proses wat die kliëntsertifikaat valideer, want net daardie proses kan 'n lys handhaaf. Op 'n OpenVPN-bediener is dit die daemon self, opgestel met crl-verify. Op ocserv is dit die crl-reël in ocserv.conf. Op strongSwan is die insette die gelaaide CRL's saam met strictcrlpolicy. 'n TLS-beëindigende proxy of toestel voor die VPN kan ook die werklike verifieerder wees, en as dit so is, sien die daemon daaragter nooit die kliëntsertifikaat nie.

WireGuard val in 'n ander kategorie. Dit het geen sertifikate en geen herroepingslys nie; 'n peer word toegelaat op sy publieke sleutel in die konfigurasie, so toegang beëindig beteken om daardie sleutel te verwyder. As jy in 'n ontplooiing met net WireGuard na 'n CRL soek, is daardie meganisme nie daar nie.

Pas ook op vir die strik aan die kliëntkant. 'n Kliënt wat weier om te verbind omdat hy nie van die bediener se sertifikaat hou nie, handhaaf die bediener se ketting en herroep nie sy eie geloofsbrief nie. 'n Gebruikersertifikaat word net herroep waar daardie gebruikersertifikaat gevalideer word, en dit is byna altyd die bedienerkant.

Toets vir watter uitreiker die lys onderteken is

'n CRL is beperk tot een uitreikende CA. Met 'n wortel en 'n intermediêre kom bladsertifikate van die intermediêre, so die lys wat saak maak is die intermediêre se CRL; die wortel se lys sê niks oor daardie blare nie. 'n Verifieerder wat na die verkeerde lêer wys, ontleed dit vrolik, vind geen passende inskrywing nie en aanvaar alles.

Bevestig die paring voordat jy die daemon aanraak. Die uitreiker op die sertifikaat moet met die onderwerp van die lys ooreenstem:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Wanneer albei van dieselfde CA kom, is die reeksnommer wat vir die sertifikaat gedruk is die waarde wat in die lys moet verskyn. Stem hulle nie ooreen nie, dan hou jy die verkeerde CRL of die verkeerde kopie daarvan vas.

Geldigheid hoort by dieselfde kontrole. 'n nextUpdate in die verlede maak die lys verouderd, en 'n verifieerder wat fail-closed werk, sal dan elke kliënt verwerp eerder as net die herroepte een.

Toets dat die reeksnommer in die kopie is wat die daemon gelaai het

Herroeping skryf 'n inskrywing in die CA-databasis, en hergenerering skryf 'n nuwe lêer. Nie een van die twee aksies bereik 'n lopende daemon wat die ou kopie by aanvang gelaai het nie. Stort die lys uit en soek die reeksnommer:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Toets dan hoe jou implementering die lêer optel. OpenVPN lees 'n pad wat aan crl-verify gegee is een keer by aanvang, so 'n nuwe lys benodig 'n herbegin of 'n herbegin-sein; dieselfde opsie wat na 'n gids wys, word vir elke verbinding weer gelees, en daarom bestaan die gidsmodus. strongSwan moet sy geloofsbriewe herlaai, byvoorbeeld met swanctl --load-creds. Dat die lêer op skyf korrek is en dat die verifieerder dit gebruik, is twee verskillende feite.

Toets die beleid vir 'n ontbrekende of vervalle lys

Dit is die besluit wat baie ontplooiings nooit uitdruklik neem nie, en dit bepaal of herroeping jou beskerm of almal uitsluit. Fail-closed beteken dat geen bruikbare herroepingsinligting 'n verwerping lewer nie; fail-open beteken dat die verifieerder sonder dit voortgaan. strongSwan bied die keuse as strictcrlpolicy. OpenVPN met crl-verify weier om te begin op 'n lêer wat hy nie kan lees of ontleed nie, en 'n vervalle lys verskyn as 'n TLS-verifikasiefout oor 'n vervalle CRL eerder as 'n stil aanvaarding.

Watter rigting jy ook kies, die outomatisering tel meer as die keuse: 'n taak wat die CRL voor nextUpdate hergenereer, en 'n waarskuwing wanneer die ontplooide kopie ouer word, hou enige beleid daarvan om 'n voorval te word. Aanlyn toetsing met OCSP skuif varsheid na 'n responder, maar dieselfde reël geld, want 'n verifieerder wat nie opgestel is om die antwoord te toets nie, verander niks.

Toets die lewende sessie, dan die kopieë van die sleutel

Herroeping word tydens sertifikaatvalidasie geëvalueer, wat by verbinding en by heronderhandeling gebeur. 'n Gevestigde sessie hou aan tot dit heronderhandel, en OpenVPN se verstek is een keer per uur met reneg-sec 3600. As die persoon nou van die netwerk af moet wees, beëindig die sessie sowel as die publikasie van die lys, en bevestig dan dat die herverbinding geweier word.

Skei die geloofsbrief van sy kopieë. Om 'n profiel op een skootrekenaar te skrap keer nie dat 'n ander kopie van dieselfde private sleutel authentiseer nie; herroeping is wat elke kopie nutteloos maak, en eers wanneer die vroeëre kontroles hou. Gee 'n vervangingsapparaat sy eie sertifikaat sodat een herroep kan word sonder om die ander te raak.

Voordat jy dit klaar noem: die validerende komponent is geïdentifiseer, die lys se uitreiker stem ooreen met die blaar se uitreiker, die herroepte reeksnommer sit in die kopie wat die daemon werklik gelaai het, die beleid vir ontbrekende of vervalle lyste is doelbewus en gemonitor, en die aktiewe sessie is beëindig eerder as afgewag. Die formate agter dit alles word in RFC 5280 gespesifiseer.