Undersøgelse af et VPN-certifikat uden at dumpe dets nøgle

At læse et certifikats offentlige felter kræver aldrig, at man viser den private nøgle, der hører til, og værktøjerne til det følger med ethvert system, der terminerer en VPN. Risikoen ligger et skridt tidligere: den fil, du har fået, er måske slet ikke et certifikat. Et PEM-certifikat, en DER-blob, en PKCS#12-pakke og en OpenVPN-profil kan ankomme med samme navn og indeholde meget forskelligt materiale, så identificér beholderen, før du vælger en kommando.

Tre forhold afgør, hvilken kommando der er sikker: hvad filen indeholder, hvad du skal læse ud af den, og hvem der ser outputtet. Tager du fejl af blot ét af dem, bliver selve undersøgelsen hændelsen.

Hvilken af de tre filer du har fået

Et PEM-certifikat er tekst med synlige BEGIN- og END-markører, en DER-fil er binær og kræver et flag for inputformat, og en pakke er en beholder, der kan rumme en nøgle ved siden af certifikatet. file server.crt skiller tekst fra binært på et sekund, og et blik på den første linje skiller et bart certifikat fra en profil, der indlejrer et. Det er gætteriet her, der gør en undersøgelse til en hændelse.

Hvis filen er en profil og ikke et certifikat, så behandl den som en adgangsoplysning, indtil det modsatte er bevist. Den antagelse koster intet og forhindrer den mest almindelige fejl i hele opgaven.

Læsning af offentlige felter i et PEM-certifikat

For et certifikat, du har tilladelse til at undersøge, udskriver underkommandoen x509 med -noout kun de felter, du vælger, og intet andet. Det er undertrykkelsen af kroppen, der holder outputtet på metadata, og det er også det, der gør det sikkert at indsætte i en ticket. Vælgerne nedenfor er de offentlige, og dokumentationen for openssl x509 viser resten.

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

På et lokalt genereret testcertifikat udskriver kommandoen en subject- og issuer-linje, parret notBefore og notAfter samt ét SHA-256-fingeraftryk. De felter identificerer objektet; de etablerer ikke en gyldig tillidssti, hvilket er en separat verifikationsopgave med sin egen kommando og sit eget svar. En kædefil kan også kun udskrive det første certifikat, medmindre du selv itererer gennem filen. At sammenligne to filer på denne måde koster én kommando og afgør, hvilken af dem modparten faktisk præsenterer.

Pakker, der rummer en nøgle ved siden af certifikatet

En .p12- eller .pfx-fil kan bære en privat nøgle, og parserkommandoen udskriver den, medmindre du undertrykker den del af outputtet. Med -nokeys rapporterer samme kommando stadig beholderens struktur, inklusive en tilsløret nøglepose, uden at udsende nøglemateriale; fjerner du flaget, dukker en nøgleblok op i din terminal og i din shell-historik.

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

En OpenVPN-profil indlejrer det samme materiale som tekst, så grænsen er synlig, hvis du ved, hvor du skal kigge. Offentligt materiale ligger mellem BEGIN CERTIFICATE og END CERTIFICATE, mens alt mellem BEGIN PRIVATE KEY og dens matchende END-linje er nøglen og ikke må forlade værten. Kopierer du profilen i sin helhed, offentliggør du begge.

Hent referenceværdien et andet sted

Et fingeraftryk, der læses fra den forbindelse, du prøver at verificere, beviser intet, fordi det er den part, du ikke stoler på, der har leveret det. Det er ikke et argument mod fingeraftryk; det er et argument om oprindelse. Sammenlign værdien med en, der er hentet gennem en kanal, som modparten ikke kan skrive til, fx certifikatet, der er offentliggjort i et internt lager, eller hashen, der er trykt i en signeret ændringslog.

Hvor et tillidslager udfører valideringen, så lad det gøre det, og læs den fejl, det producerer, i stedet for at erstatte den med din egen sammenligning. Den afgørende forskel er, hvem der leverede referencen, ikke hvilken hashfunktion der blev brugt.

Del resultatet, og hvad du gør efter en fejl

Send den præcise valideringsfejl, de relevante datoer og kun de identitetsoplysninger, modtageren har brug for. Interne værtsnavne og kontoidentifikatorer forbliver følsomme, selv når der ikke er nogen nøgle, og en offentlig indsættelsestjeneste er det forkerte sted for noget af det. Indsæt i ticketen, ikke i en kladdebuffer, som en anden deler.

Hvis nøglemateriale alligevel dukkede op på skærmen eller i en fil, så betragt det som kompromitteret og roter det i stedet for at håbe på, at ingen har kigget. Skriv derefter ned, hvilken fil der blev undersøgt, hvilken kommando der blev brugt, og hvor outputtet endte, fordi den registrering er det, der gør en forskrækkelse til en procedure. Rotation er billig sammenlignet med prisen for at antage, at ingen har gemt et skærmbillede, og den samme registrering fortæller den næste ingeniør, hvilke filer der overhovedet blev berørt. Gør begge dele, før ticketen lukkes.