Nuwe VPN-aanmeldings misluk terwyl sertifikate geldig is: kyk na die CRL

Sertifikate met nog maande oor en aanmeldings wat onmiddellik misluk, wys op twee verskillende objekte met twee verskillende horlosies. Die bediener verwerp verbindings omdat die lys van herroepte sertifikate wat hy raadpleeg sy eie vervaldatum verbygesteek het, nie omdat die gebruikers se sertifikate verval het nie. Die hernuwing van ’n gebruiker se sertifikaat doen niks aan daardie lys nie.

Om die twee skedules te skei, is die hele diagnose, en dit verander waaraan die oplossing moet voldoen.

Twee horlosies, en net een daarvan is die sertifikaat

’n Sertifikaat dra ’n geldigheidsvenster. ’n Sertifikaatherroepingslys dra sy eie venster, plus ’n uitgewer en ’n handtekening, en verifieerders weier om ’n lys te vertrou waarvan die volgende-opdateringstyd verby is. Wanneer dit gebeur, bied die kliënt ’n heeltemal geldige sertifikaat aan en laat die bediener die verbinding steeds val met ’n boodskap oor die lys. Gebruikers lees daardie boodskap as 'die sertifikaat het verval', wat die hernuwingsversoek na die verkeerde plek stuur.

Die twee objekte het ook verskillende eienaars: die sertifikaat kom van die CA wat dit uitgereik het, terwyl die lys volgens ’n skedule geskep word deur wie daardie CA bedryf. ’n Gebruiker kan dit nie vernuwe nie, en die heruitreiking van sertifikate kan dit nie verleng nie.

Lees die lys wat die diens werklik laai

Begin by die lopende konfigurasie eerder as by die lêer wat jy verwag. Die pad van crl-verify kan absoluut wees, relatief tot die profiel, of ’n kopie wat in ’n beeld ingebak is, en die verifieerder lees daardie kopie. Inspekteer dit op sy plek met openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate en vergelyk die datums met die bediener se horlosie.

Bevestig dan dat die lêer werklik die een is wat in gebruik is: kyk na sy handtekening met openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, wat ’n verifikasieresultaat rapporteer eerder as om stilweg velde te druk. ’n Lys wat deur ’n ander CA onderteken is, of ’n verouderde kopie wat in ’n tweede gids agtergebly het, misluk presies soos ’n vervalde een.

Skep opnuut uit die herroepingsdatabasis, nie van nuuts af nie

Die nuwe lys moet uit die CA se huidige herroepingsdatabasis kom, deur die goedgekeurde ondertekeningsproses. Om ’n leë lys te skep, of om opnuut uit ’n ou rugsteun van die indeks te skep, herroep stilweg elke identiteit wat sedert daardie rugsteun bygevoeg is. Dit verander ’n aanmeldingsonderbreking in ’n sekuriteitsagteruitgang, en niemand merk dit nie omdat die simptoom verdwyn.

Hou die scheppingsstap in weergawebeheer saam met die res van die CA-gereedskap, sodat die interval en die ondertekeningsleutel gedokumenteer is eerder as onthou. ’n Runbook-inskrywing wat die opdrag, die ondertekenaar en die publikasieteiken noem, is genoeg. Enigiemand op diens kan dan opnuut skep sonder om te raai watter indekslêer gesaghebbend is. Stoor die lys se reeksnommer en volgende-opdateringstyd saam met die ontplooiingsrekord.

Ontplooi waar die verifieerder kyk

Kopieer die nuwe lys na die pad wat die diens lees, stel eienaarskap en modus sodat die diensrekening dit kan lees maar ander nie, en herlaai of herbegin volgens die gedokumenteerde gedrag. As die daemon die lys by die opstart kas, verander die vervanging van die lêer sonder ’n herlaai niks wat die lopende proses sal opmerk nie. Bevestig die tydstempel wat die proses ná die herlaai rapporteer.

As verskeie dienste kliënte verifieer, ontplooi by elkeen van hulle. Om een eindpunt op te dateer en ’n ander met die ou kopie te laat, lewer ’n fout op wat net verskyn vir die gebruikers wat op die tweede een beland. Hou ’n kort lys van daardie eindpunte in dieselfde runbook. Kontroleer ná die uitrol elke een se gerapporteerde lysdatum eerder as om aan te neem dat die kopie daar aangekom het.

Maak die volgende spertyd sigbaar voordat dit verby is

’n Langer publikasie-interval verlaag die frekwensie van hierdie voorval sonder om ’n proses te skep. Kies die interval volgens die operateur se beleid en waarsku dan op die ontplooide lys se volgende-opdateringsveld met genoeg voorlooptyd om opnuut te skep en te ontplooi. Waarsku op die ontplooide kopie, nie op die CA-gasheer nie, want die ontplooide kopie is wat misluk.

Verifieer ná die ontplooiing albei rigtings: ’n toegelate gebruiker verbind, en ’n bekende herroepte identiteit misluk steeds. Die tweede kontrole is die een wat ’n onvolledige herschepping betrap, en dit kos een opdrag teen ’n toetsprofiel wat jy juis hiervoor aanhou.