Twee OpenVPN-certificaten, één CCD-naam: wat ging er mis

Twee clientcertificaten met verschillende serienummers, verschillende sleutels en zelfs verschillende volledige subjects kunnen toch op hetzelfde beleidsbestand uitkomen, omdat de server naar niets daarvan kijkt. Hij leest een naam uit het certificaat en opent het bijbehorende clientconfiguratiebestand. Als beide certificaten dezelfde naam dragen, erft het tweede het beleid van het eerste op het moment dat het verbinding maakt.

De botsing ontstaat bij de inschrijving en wordt pas bij het verbinden ontdekt, meestal wanneer een apparaat een adres of een set routes krijgt die bij een andere machine hoort. Om dit te voorkomen moet je afspreken welk veld de server mapt en die waarde vervolgens reserveren voordat er iets wordt ondertekend.

Je certificaattools waarschuwen je niet, omdat uniciteit binnen X.509 en uniciteit van een OpenVPN-beleidsnaam verschillende eisen zijn die door verschillende systemen worden afgedwongen.

De server zoekt een naam, geen vingerafdruk

Bij de gebruikelijke op certificaten gebaseerde mapping neemt de server de common name uit het aangeboden certificaat en zoekt een bestand met die naam in zijn clientconfiguratiemap. Dat bestand kan een statisch adres vastpinnen, routes pushen of firewallmarkeringen per client toepassen. De opzoeking is een stringvergelijking met een bestandsnaam, dus hoofdletters, spaties en leestekens zijn allemaal van belang.

Sommige implementaties wisselen de mapping bewust om, zodat een geauthenticeerde gebruikersnaam de common name overneemt, en dan is het de gebruikersnaam die uniek moet zijn. Hoe dan ook, de waarde die het beleid selecteert is de waarde die je reserveert. Bepaal welke dat is voordat je iets uitgeeft; gokken na een botsing kost meer dan vragen.

Waar twee autoriteiten op dezelfde naam passen

Een organisatie die certificaten van meer dan één uitgevende autoriteit accepteert, draait twee onafhankelijke inschrijvingsprocessen die in één naamruimte schrijven. De eigen uniciteitsregels van elke autoriteit gelden binnen die autoriteit, dus beide kunnen legitiem uitgeven voor dezelfde common name zonder dat een van beide iets verkeerds merkt.

Serienummers helpen niet. X.509 vereist dat een serienummer uniek is binnen het bereik van zijn uitgever, wat een eigenschap is van de boekhouding van die autoriteit en niet een wereldwijde apparaatidentiteit. Een subjectcontrole is ook een andere test dan een common-name-controle: twee certificaten kunnen een CN delen en toch verschillen in organisatieonderdeel en dus verschillende subjects dragen. Elk van die eigenschappen kan gelden terwijl de server beide certificaten nog steeds op één bestandsnaam mapt.

De OpenSSL CA-documentatie behandelt de instelling unique_subject die de mening van zijn eigen database stuurt, en het eerlijke uitgangspunt is je uitgevende configuratie te lezen in plaats van aan te nemen dat een bepaalde EasyRSA- of OpenSSL-standaard geldt.

Reserveer de effectieve naam voordat je ondertekent

Houd een register bij dat een apparaat aan zijn goedgekeurde record en van daaruit aan een exacte beleidsbestandsnaam koppelt, zodat een naam één keer wordt toegewezen en toegewezen blijft. De reservering moet atomair zijn, wat in de praktijk een databaserestrictie of een lock rond de stap toewijzen-en-dan-ondertekenen betekent, niet een spreadsheet die twee mensen bewerken.

Maak de controle vervolgens deel van de uitgifte: weiger te ondertekenen wanneer de gevraagde naam al bestaat, en betrek elke autoriteit die de server vertrouwt in die controle, want een naam die door de andere autoriteit is gereserveerd is net zo goed bezet. Een afgewezen verzoek met een duidelijke reden is goedkoper dan een ticket over een apparaat dat steeds iemands anders statische adres krijgt.

Verlenging hergebruikt een naam met opzet

Opnieuw uitgeven voor een bestaand apparaat zou een nieuw serienummer onder dezelfde beleidsnaam moeten opleveren, en dat is legitiem hergebruik en geen botsing. Wat vooraf moet worden besloten is de overlap: of oude en nieuwe certificaten tegelijk geldig mogen zijn, en hoe de oude inloggegevens buiten gebruik worden gesteld.

Grijp niet naar duplicate-cn om dit op te lossen. Die serveroptie regelt gelijktijdige verbindingen die dezelfde naam aanbieden; hij vergrendelt de inschrijving niet, en het inschakelen ervan maakt één gedeeld statisch adres niet veilig voor twee machines tegelijk. Intrekking identificeert een certificaat meestal via uitgever en serienummer, dus het buiten gebruik stellen van de oude inloggegevens hoeft de vervanging niet ongeldig te maken zolang de server de juiste intrekkingsgegevens ontvangt en handhaaft.

Bevestig de mapping met de tools op de machine

Voordat je een apparaat zijn nieuwe inloggegevens geeft, lees je de naam op de manier waarop de server dat zal doen uit het certificaat, en vergelijk je die vervolgens met het beleidsbestand waarvan je verwacht dat het wordt gekozen.

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

De eerste opdracht drukt subjectvelden apart af, waardoor een verdwaald organisatieonderdeel of een dubbele spatie meteen zichtbaar wordt. De tweede bevestigt dat er een beleidsbestand onder precies die naam bestaat, en de derde laat zien of de server zo is geconfigureerd dat meerdere sessies op één naam zijn toegestaan. Voer alle drie uit op een nieuw certificaat voordat het de inschrijvingsstap verlaat, terwijl een fout nog een handtekening kost in plaats van een incident. Bewaar de uitvoer bij het ticket zodat de volgende persoon ziet welke naam de server werkelijk heeft gekregen.

Sluit af met een echte verbinding en vergelijk het toegewezen adres en de gepushte routes met het beleidsbestand in plaats van met wat je van plan was te schrijven. Als twee apparaten hetzelfde statische adres melden, heeft het register een botsing die geen enkele certificaatinspectie ooit zal onthullen.