Een VPN-certificaat inspecteren zonder de sleutel te dumpen

Het lezen van de openbare velden van een certificaat vereist nooit dat de bijbehorende privésleutel wordt getoond, en de hulpmiddelen daarvoor worden meegeleverd met elk systeem dat een VPN beëindigt. Het risico ligt een stap eerder: het bestand dat je kreeg is misschien helemaal geen certificaat. Een PEM-certificaat, een DER-blob, een PKCS#12-bundel en een OpenVPN-profiel kunnen onder dezelfde naam binnenkomen en heel verschillend materiaal bevatten, dus identificeer de container voordat je een commando kiest.

Drie feiten bepalen welk commando veilig is: wat het bestand bevat, wat je eruit moet lezen en wie de uitvoer zal zien. Zit er één fout, dan wordt de inspectie zelf het incident.

Welk van drie bestanden je kreeg

Een PEM-certificaat is tekst met zichtbare BEGIN- en END-markeringen, een DER-bestand is binair en vereist een vlag voor het invoerformaat, en een bundel is een container die een sleutel naast het certificaat kan bevatten. file server.crt scheidt tekst van binair in een seconde, en een blik op de eerste regel scheidt een kaal certificaat van een profiel dat er een insluit. Gissen is hier wat een inspectie in een incident verandert.

Als het bestand een profiel is en geen certificaat, behandel het dan als een credential tot het tegendeel bewezen is. Die aanname kost niets en voorkomt de meest voorkomende fout in deze hele taak.

De openbare velden van een PEM-certificaat lezen

Voor een certificaat dat je mag inspecteren, drukt het x509-subcommando met -noout de velden af die je selecteert en niets anders. Het onderdrukken van de body is wat de uitvoer tot metadata beperkt, en dat is ook wat het veilig maakt om in een ticket te plakken. De selectors hieronder zijn de openbare, en de documentatie van openssl x509 noemt de rest.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

Op een lokaal gegenereerd testcertificaat drukt dat commando een subject- en issuer-regel af, het paar notBefore en notAfter, en één SHA-256-vingerafdruk. Die velden identificeren het object; ze leggen geen geldig vertrouwenspad vast, wat een aparte verificatietaak is met een eigen commando en een eigen antwoord. Een ketenbestand kan ook alleen het eerste certificaat afdrukken, tenzij je zelf over het bestand itereert. Twee bestanden zo vergelijken kost één commando en beslecht welk ervan de tegenpartij werkelijk presenteert.

Bundels die een sleutel naast het certificaat houden

Een .p12- of .pfx-bestand kan een privésleutel bevatten, en het parsecommando drukt die af tenzij je dat deel van de uitvoer onderdrukt. Met -nokeys meldt hetzelfde commando nog steeds de structuur van de container, inclusief een verhulde sleutelbag, zonder enig sleutelmateriaal uit te zenden; laat je die vlag weg, dan verschijnt er een sleutelblok in je terminal en in je shellgeschiedenis.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

Een OpenVPN-profiel sluit hetzelfde materiaal als tekst in, dus de grens is zichtbaar als je weet waar je moet kijken. Openbaar materiaal staat tussen BEGIN CERTIFICATE en END CERTIFICATE, terwijl alles tussen BEGIN PRIVATE KEY en de bijbehorende END-regel de sleutel is en de host niet mag verlaten. Het profiel in zijn geheel kopiëren publiceert beide.

De referentiewaarde ergens anders vandaan halen

Een vingerafdruk die je leest uit de verbinding die je probeert te verifiëren, bewijst niets, omdat de partij die je wantrouwt hem heeft geleverd. Dat is geen argument tegen vingerafdrukken; het is een argument over herkomst. Vergelijk de waarde met een waarde die via een kanaal is verkregen waar de tegenpartij niet naar kan schrijven, zoals het certificaat dat in een interne repository is gepubliceerd of de hash die in een ondertekend wijzigingsrecord is afgedrukt.

Waar een truststore de validatie uitvoert, laat die dat doen, en lees de fout die hij produceert in plaats van hem te vervangen door je eigen vergelijking. Het verschil dat ertoe doet, is wie de referentie leverde, niet welke hashfunctie is gebruikt.

Het resultaat delen, en wat te doen na een slip

Stuur de exacte validatiefout, de relevante datums en alleen de identiteitsgegevens die de ontvanger nodig heeft. Interne hostnamen en account-ID's blijven gevoelig, zelfs als er geen sleutel aanwezig is, en een openbare plakdienst is voor niets daarvan de juiste bestemming. Plak in het ticket, niet in een scratchbuffer die iemand anders deelt.

Als er toch sleutelmateriaal op het scherm of in een bestand verscheen, behandel het dan als gecompromitteerd en roteer het in plaats van te hopen dat niemand keek. Schrijf daarna op welk bestand is geïnspecteerd, welk commando is gebruikt en waar de uitvoer heen ging, want dat verslag is wat een schrik in een procedure verandert. Rotatie is goedkoop vergeleken met de kosten van de aanname dat niemand een screenshot bewaarde, en hetzelfde verslag vertelt de volgende engineer welke bestanden überhaupt zijn aangeraakt. Doe beide voordat het ticket wordt gesloten.