Dezelfde bestandsnaam ca.crt, ander certificaat: wat te vergelijken

Twee profielen leveren allebei een bestand met de naam ca.crt, de ene tunnel komt op en de andere faalt met een kettingfout. De twee bestanden naast elkaar openen beslecht het zelden, en verificatie uitzetten beslecht het in de verkeerde richting. De vraag die de fout feitelijk stelt is smaller: welk certificaat laadt elk proces als zijn vertrouwensanker, en zijn de twee hetzelfde object? Beantwoord dat eerst en de rest van de diagnose krijgt een richting. De bestandsnaam is een verpakkingsetiket, en het pad dat in het profiel staat is ook niet gezaghebbend, dus alles hangt af van wat het proces werkelijk leest.

Vind het certificaat dat de client werkelijk laadt

OpenVPN accepteert de autoriteit in twee vormen, en de vorm bepaalt welke bytes ertoe doen. Een profiel kan met ca naar een extern bestand wijzen, of het certificaat in een <ca>-blok in het profiel zelf insluiten. Als beide bestaan, wint het ingesloten blok en wordt het bestand naast het profiel nooit geopend.

Lees het mislukkende profiel en zoek uit welke vorm het gebruikt voordat je iets vergelijkt. Een kopie uit een naburige map, of uit het pakket waar het andere profiel vandaan kwam, vertelt je niets over wat dit proces vertrouwt. Hetzelfde geldt voor het pad in de configuratie: het wordt opgelost ten opzichte van de plek waar de client is gestart, en dat is niet altijd de map die je bekijkt. Lees het profiel, niet de map.

Certificaten worden geïdentificeerd door hun inhoud: de publieke sleutel, het subject en de uitgever, het geldigheidsvenster en de handtekening over dat alles. Twee bestanden met identieke bytes zijn hetzelfde certificaat hoe ze ook heten, en twee bestanden met dezelfde naam kunnen ongerelateerde autoriteiten zijn. De naam is een verpakkingsetiket, geen identiteit.

Neem de vingerafdruk van beide kopieën met openssl

Een vingerafdruk is een hash over de DER-codering van het certificaat, de vorm die de handtekening dekt, dus regeleinden en koptekst kunnen er geen invloed op hebben. Bereken hem voor elk bestand en je hebt twee door dubbele punten gescheiden hexstrings die ofwel overeenkomen of niet. Er hoeft niets anders in het certificaat te worden gelezen om de vergelijkingsvraag te beantwoorden.

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

Het is verleidelijk openssl op het profiel zelf te richten, maar het leest het eerste certificaatblok dat in het bestand voorkomt, en een profiel bevat meestal <cert> vóór <ca>. Pak het autoriteitsblok eruit en neem dan de vingerafdruk van het uitgepakte bestand, want dat is de kopie die de client werkelijk zal gebruiken.

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

Identieke vingerafdrukken betekenen dat het vertrouwensmateriaal hetzelfde is en dat de kettingfout een andere oorzaak heeft, wat een ander onderzoek is. Verschillende vingerafdrukken betekenen verschillende certificaten, en daar begint de volgende sectie.

Lees een afwijking voordat je een aanval aanneemt

Verschillende vingerafdrukken betekenen verschillende certificaten en niets meer. Een heruitgifte, een rotatie, een omgedoopte autoriteit of een verouderd bundel leveren allemaal verschillende bestanden op met volkomen legitieme geschiedenissen. Welke bij de uitrol hoort, is een vraag voor de operator of het uitrolregister, niet voor de wijzigingstijd van het bestand. Archieven kopiëren tijdstempels, dus een nieuwer bestand is niet automatisch het juiste anker.

Een wortel die zichzelf ondertekent is normaal, dus er een vinden is geen bewijs van een probleem. De taak van de verifieerder is een pad bouwen van het servercertificaat naar het anker dat hij kreeg, en een kettingfout betekent meestal dat dat pad niet kon worden voltooid.

Controleer of het anker van het mislukkende profiel een autoriteit is waar de uitrol nog steeds uit uitgeeft. Als de vingerafdruk nergens in het uitrolregister op past, is het profiel simpelweg verouderd, en geen enkele aanpassing aan de clientkant zal dat verhelpen.

Herstel vertrouwen zonder verificatie uit te zetten

De oplossing op korte termijn is verificatie uitzetten of elk certificaat in de keten als anker toevoegen. Beide laten de melding verdwijnen, en beide veranderen welke servers de client vanaf dan accepteert. Zet verificatie weer aan, installeer het bedoelde anker en test opnieuw.

Als de keten nu wordt opgebouwd maar er een andere fout verschijnt, is dat vooruitgang: naamverificatie, geldigheidsdatums en intrekking zijn aparte controles met aparte meldingen. Bewaar het vingerafdrukpaar en de oorspronkelijke fouttekst samen in het ticket, zodat de volgende persoon ziet welk anker is geladen en welk werd verwacht. Een paar vingerafdrukken is klein genoeg om in een overdrachtsnotitie te plakken, en de volgende keer duurt dan vijf minuten in plaats van een middag.

Verkrijg de juiste autoriteit via hetzelfde geauthenticeerde kanaal dat het profiel leverde. Een certificaat van de server trekken omdat het subject bekend lijkt, is een andere daad, en het verbreedt stilzwijgend wat de client zal vertrouwen.