Två OpenVPN-certifikat, ett CCD-namn: vad gick fel

Två klientcertifikat med olika serienummer, olika nycklar och till och med olika fullständiga subjekt kan ändå hamna i samma policyfil, eftersom servern inte tittar på något av det. Den läser ett namn ur certifikatet och öppnar motsvarande klientkonfigurationsfil. Om båda certifikaten bär samma namn ärver det andra det förstas policy i det ögonblick det ansluter.

Kollisionen skapas vid registreringen och upptäcks först vid anslutning, vanligtvis när en enhet får en adress eller en uppsättning rutter som tillhör en annan maskin. Att förebygga den innebär att komma överens om vilket fält servern mappar och sedan reservera det värdet innan något signeras.

Dina certifikatverktyg varnar dig inte, eftersom unikhet inuti X.509 och unikhet för ett OpenVPN-policynamn är olika krav som upprätthålls av olika system.

Servern slår upp ett namn, inte ett fingeravtryck

Med den vanliga certifikatbaserade mappningen tar servern det vanliga namnet från det presenterade certifikatet och letar efter en fil med det namnet i sin klientkonfigurationskatalog. Den filen kan fästa en statisk adress, skicka rutter eller tillämpa brandväggsmarkeringar per klient. Uppslaget är en strängjämförelse mot ett filnamn, så stora och små bokstäver, mellanslag och skiljetecken spelar alla roll.

Vissa driftsättningar byter medvetet om mappningen så att ett autentiserat användarnamn tar över det vanliga namnet, och då är det användarnamnet som måste vara unikt. Hur som helst är det värde som väljer policy det värde du reserverar. Bestäm vilket det är innan du utfärdar något; att gissa efter en kollision kostar mer än att fråga.

Där två myndigheter möts på samma namn

En organisation som accepterar certifikat från mer än en utfärdande myndighet driver två oberoende registreringsprocesser som skriver i ett namnutrymme. Varje myndighets egna unikhetsregler gäller inom den, så båda kan lagligt utfärda för samma vanliga namn utan att någon av dem märker något fel.

Serienummer hjälper inte. X.509 kräver att ett serienummer är unikt inom sin utfärdares område, vilket är en egenskap hos den myndighetens bokföring och inte en global enhetsidentitet. En subjektkontroll är också ett annat test än en vanlig-namn-kontroll: två certifikat kan dela ett CN men ändå skilja sig i organisationsenhet och därför bära olika subjekt. Var och en av dessa egenskaper kan gälla medan servern fortfarande mappar båda certifikaten till ett filnamn.

OpenSSL CA-dokumentationen täcker inställningen unique_subject som styr dess egen databas uppfattning, och den ärliga utgångspunkten är att läsa din utfärdarkonfiguration i stället för att anta att en viss EasyRSA- eller OpenSSL-standard gäller.

Reservera det effektiva namnet före signering

För ett register som mappar en enhet till dess godkända post och därifrån till ett exakt policyfilnamn, så att ett namn tilldelas en gång och förblir tilldelat. Reservationen måste vara atomär, vilket i praktiken innebär en databasbegränsning eller ett lås runt steget tilldela-och-sedan-signera, inte ett kalkylark som två personer redigerar.

Gör sedan kontrollen till en del av utfärdandet: vägra signera när det begärda namnet redan finns, och inkludera varje myndighet som servern litar på i den kontrollen, eftersom ett namn som reserverats av den andra myndigheten är lika upptaget. En avvisad begäran med tydlig anledning är billigare än ett ärende om en enhet som ständigt får någon annans statiska adress.

Förnyelsen återanvänder ett namn med avsikt

Utfärdande på nytt för en befintlig enhet bör ge ett nytt serienummer under samma policynamn, och det är legitim återanvändning och inte en kollision. Det som måste avgöras i förväg är överlappningen: om gamla och nya certifikat får vara giltiga samtidigt, och hur den gamla inloggningsuppgiften dras tillbaka.

Ta inte till duplicate-cn för att lösa detta. Det serveralternativet styr samtidiga anslutningar som presenterar samma namn; det låser inte registreringen, och att aktivera det gör inte en delad statisk adress säker för två maskiner samtidigt. Återkallelse identifierar normalt ett certifikat via utfärdare och serienummer, så tillbakadragandet av den gamla inloggningsuppgiften behöver inte ogiltigförklara dess ersättning så länge servern tar emot och tillämpar korrekta återkallelsedata.

Bekräfta mappningen med verktygen på maskinen

Innan du lämnar en enhet dess nya inloggningsuppgift, läs namnet ur certifikatet så som servern kommer att göra, och jämför det sedan med den policyfil du förväntar dig ska väljas.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

Det första kommandot skriver ut subjektfält separat, vilket gör en vilsegången organisationsenhet eller ett dubbelt mellanslag synligt direkt. Det andra bekräftar att en policyfil finns under exakt det namnet, och det tredje visar om servern är konfigurerad att tillåta flera sessioner på ett namn. Kör alla tre mot ett nytt certifikat innan det lämnar registreringssteget, medan ett fel fortfarande kostar en signatur i stället för en incident. Spara utdata tillsammans med ärendet så att nästa person ser vilket namn servern faktiskt fick.

Avsluta med en riktig anslutning och jämför den tilldelade adressen och de skickade rutterna med policyfilen i stället för med det du tänkte skriva. Om två enheter rapporterar samma statiska adress har registret en kollision som ingen certifikatinspektion någonsin kommer att avslöja.