Eén gemeenschappelijke naam, twee certificaten: toelatingslijst of intrekken?
Een certificaat opnieuw uitgeven voor dezelfde gemeenschappelijke naam laat het oude geldig. Een naamlijst kan ze niet onderscheiden; alleen een CRL of serienummercontrole kan dat.
Een laptopcertificaat opnieuw uitgeven onder dezelfde gemeenschappelijke naam voelt als een vervanging, en iedereen gaat ervan uit dat het oude dood is. Dat is het niet. De voorganger blijft een geldig certificaat, ondertekend door dezelfde autoriteit, en elke controle die clients op naam toelaat, zal hem blijven toelaten. Wat een identiteitscontrole van een referentiecontrole scheidt, is het serienummer, en daar hoort de oplossing.
Begin bij het naamgevingsbeleid dat de server gebruikt
Twee controles worden verward: een client toelaten omdat hij beweert iemand te zijn, en één specifiek certificaat buiten dienst stellen. De eerste is een naamcontrole, de tweede is een intrekkingscontrole. Ze beantwoorden verschillende vragen, en een implementatie kan de ene hebben zonder de andere.
Lees de serverconfiguratie en noteer welke identiteitsbron in het spel is. username-as-common-name maakt de geauthenticeerde gebruikersnaam de effectieve naam voor clientspecifieke opzoekingen. Zonder dat wordt de gemeenschappelijke naam van het subject uit het certificaat gebruikt. Wat het antwoord ook is, schrijf het op voordat je een toelatingslijst aanraakt.
De twee paden leveren een andere set toegestane namen op voor hetzelfde certificaat. Hier gokken betekent het verkeerde bestand bewerken en concluderen dat de controle niet werkt.
Controleer wat een client daadwerkelijk toelaat
Een client-config-dir met een overeenkomend bestand levert clientspecifieke opties; op zichzelf is het geen toelatingsregel. Toelating op naam vereist ccd-exclusive, dat clients weigert zonder overeenkomend bestand. Dat aanzetten op een live-implementatie verbreekt iedereen wiens naam geen bestand heeft, dus tel de bestanden voordat je iets omzet.
grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/De telling is de controle: vergelijk de directorylisting met de identiteiten die je verwacht te verbinden.
Bevestig vervolgens dat elke bestandsnaam exact overeenkomt met de effectieve identiteit, inclusief hoofdletters en spaties. Een bestand voor office-laptop doet niets voor een certificaat waarvan het subject luidt Office-Laptop. Spaties aan het einde verbergen zich ook voor een gewone listing, en zo blijft een bestand dat aanwezig lijkt ongelezen.
Controleer de CRL die de gateway laadt
Een CRL noemt ingetrokken certificaten op uitgever en serienummer, en dat is de granulariteit die een naamcontrole mist. Twee certificaten kunnen een gemeenschappelijke naam delen en verschillen in serienummer, en alleen een lijst op serienummerniveau scheidt ze.
Bevestig het geconfigureerde pad, de uitgiftedatum en het veld voor de volgende update voordat je het bestand überhaupt vertrouwt.
openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subjectVergelijk het serienummer in de CRL met het serienummer op het certificaat dat je wilt houden. Die vergelijking is de hele test, en het één keer met de ogen doen is meer waard dan een script vertrouwen dat niemand heeft gelezen. Verspreid de bijgewerkte CRL via het pad dat de gateway al leest. Een CRL in de verkeerde map handhaaft niets, en geen enkel clientlog zal hem noemen.
Vervang, bewijs daarna beide uitkomsten
Geef de vervanging uit onder dezelfde gemeenschappelijke naam, leg beide serienummers vast en trek pas dan het oude in. Die volgorde houdt een werkende identiteit beschikbaar terwijl je de wijziging voorbereidt.
Test eerst de vervanging: die moet authenticeren en bereiken waar zijn naam recht op heeft. Test daarna het oude certificaat en bevestig dat het wordt geweigerd, want een geslaagde vervanging zegt niets over intrekking. Als beide nog verbinden, wordt de intrekkingsinvoer niet gelezen of is het oude serienummer nooit vermeld. Als geen van beide verbindt, heb je de toelatingsregel kapotgemaakt en niet de referentie.
Sessies die al tot stand zijn gebracht, zijn een aparte zaak, omdat intrekking geldt voor nieuwe authenticaties, tenzij de gateway ook is geconfigureerd om live verbindingen te verbreken. Bepaal of onmiddellijke verwijdering nodig is voordat je het iemand belooft.
Wat een naamcontrole nooit kan
Een toelatingslijst beantwoordt of deze identiteit mag verbinden. Ze kan niet zeggen welk certificaat die identiteit gebruikte, en ze zal een oudere referentie toelaten zolang die referentie geldig en niet ingetrokken blijft. Die kloof komt aan het licht tijdens een incident, wanneer de vervanging maanden geleden is uitgegeven en de voorganger nog werkt.
Waar controle op certificaatniveau vereist is, gebruik een mechanisme dat het certificaat benoemt: CRL-vermeldingen, of een verificatiehaak die een vingerafdruk controleert die de operator onderhoudt. Beide kosten onderhoud, en beide zijn eerlijk over het object dat ze onderzoeken. OpenVPN 2.6-handleiding documenteert crl-verify en clientspecifieke toelating als afzonderlijke opties, juist om die reden.
Schrijf op welke controle welke taak doet, en test dan het negatieve geval. Een intrekking die je nooit een verbinding hebt zien weigeren, is een configuratie waarvan je hoopt dat ze werkt.