Ett vanlig navn, to sertifikater: tillatelsesliste eller tilbakekalling?

Å utstede et nytt laptop-sertifikat under samme vanlige navn føles som en erstatning, og alle antar at det gamle er dødt. Det er det ikke. Forgjengeren forblir et gyldig sertifikat signert av samme myndighet, og enhver kontroll som slipper inn klienter etter navn vil fortsette å slippe det inn. Det som skiller en identitetssjekk fra en legitimasjonssjekk, er serienummeret, og det er der rettelsen hører hjemme.

Start med navnepolitikken serveren bruker

To kontroller blir blandet sammen: å slippe inn en klient fordi den hevder å være noen, og å fjerne ett bestemt sertifikat fra tjeneste. Den første er en navnesjekk, den andre er en tilbakekallingssjekk. De svarer på forskjellige spørsmål, og en utrulling kan ha den ene uten den andre.

Les serverkonfigurasjonen og noter hvilken identitetskilde som er i spill. username-as-common-name gjør det autentiserte brukernavnet til det effektive navnet for klientspesifikke oppslag. Uten det brukes subjektets vanlige navn fra sertifikatet. Uansett hva svaret er, skriv det ned før du rører noen tillatelsesliste.

De to veiene gir et annet sett tillatte navn for samme sertifikat. Å gjette her betyr å redigere feil fil og konkludere med at kontrollen ikke virker.

Sjekk hva som faktisk slipper inn en klient

En client-config-dir med en samsvarende fil gir klientspesifikke alternativer; alene er den ikke en innslipsregel. Innslip etter navn krever ccd-exclusive, som avviser klienter som ikke har en samsvarende fil. Å slå det på i en aktiv utrulling kobler fra alle hvis navn ikke har en fil, så tell filene før du snur noe.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Antallet er sjekken: sammenlign kataloglisten med identitetene du forventer skal koble til.

Bekreft deretter at hvert filnavn samsvarer nøyaktig med den effektive identiteten, inkludert store og små bokstaver og mellomrom. En fil for office-laptop gjør ingenting for et sertifikat hvis subjekt lyder Office-Laptop. Mellomrom på slutten skjuler seg også for en vanlig liste, og det er slik en fil som ser ut til å være der, forblir ulest.

Sjekk CRL-en som gatewayen laster

En CRL navngir tilbakekalte sertifikater etter utsteder og serienummer, og det er detaljnivået en navnesjekk mangler. To sertifikater kan dele et vanlig navn og avvike i serienummer, og bare en liste på serienivå skiller dem.

Bekreft den konfigurerte stien, utstedelsesdatoen og feltet for neste oppdatering før du i det hele tatt stoler på filen.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

Sammenlign serienummeret i CRL-en med serienummeret på sertifikatet du vil beholde. Den sammenligningen er hele testen, og å gjøre den én gang med øynene er verdt mer enn å stole på et skript ingen har lest. Distribuer den oppdaterte CRL-en via stien gatewayen allerede leser. En CRL som ligger i feil katalog håndhever ingenting, og ingen klientlogg vil nevne den.

Erstatt, og bevis deretter begge utfallene

Utsted erstatningen under samme vanlige navn, registrer begge serienumrene, og tilbakekall først da det gamle. Den rekkefølgen holder en fungerende identitet tilgjengelig mens du forbereder endringen.

Test erstatningen først: den skal autentisere og nå alt navnet har krav på. Test deretter det gamle sertifikatet og bekreft at det avvises, fordi en vellykket erstatning ikke sier noe om tilbakekalling. Hvis begge fortsatt kobler til, blir ikke tilbakekallingsinndataene lest, eller det gamle serienummeret ble aldri listet. Hvis ingen av dem kobler til, har du ødelagt innslipsregelen og ikke legitimasjonen.

Økter som allerede er etablert, er en egen sak, siden tilbakekalling gjelder nye autentiseringer med mindre gatewayen også er konfigurert til å avslutte levende tilkoblinger. Bestem om umiddelbar fjerning er nødvendig før du lover det til noen.

Hva en navnesjekk aldri kan gjøre

En tillatelsesliste svarer på om denne identiteten kan koble til. Den kan ikke si hvilket sertifikat identiteten brukte, og den vil slippe inn en eldre legitimasjon så lenge legitimasjonen forblir gyldig og ikke tilbakekalt. Det gapet dukker opp under en hendelse, når erstatningen ble utstedt for måneder siden og forgjengeren fortsatt virker.

Der kontroll på sertifikatnivå er påkrevd, bruk en mekanisme som navngir sertifikatet: CRL-oppføringer, eller en verifiseringskrok som sjekker et fingeravtrykk operatøren vedlikeholder. Begge koster vedlikehold, og begge er ærlige om objektet de undersøker. OpenVPN 2.6-håndboken dokumenterer crl-verify og klientspesifikk innslipp som separate alternativer, nettopp av den grunn.

Skriv ned hvilken kontroll som gjør hvilken jobb, og test deretter det negative tilfellet. En tilbakekalling du aldri har sett avvise en tilkobling, er en konfigurasjon du håper virker.