Inspisere et VPN-sertifikat uten å dumpe nøkkelen

Å lese de offentlige feltene i et sertifikat krever aldri at du viser den private nøkkelen som hører til, og verktøyet for å gjøre det finnes på alle systemer som avslutter en VPN. Risikoen ligger ett steg tidligere: filen du fikk, er kanskje ikke et sertifikat i det hele tatt. Et PEM-sertifikat, en DER-blob, en PKCS#12-pakke og en profil fra OpenVPN kan komme med samme navn og inneholde svært forskjellig materiale, så identifiser beholderen før du velger kommando.

Tre fakta avgjør hvilken kommando som er trygg: hva filen inneholder, hva du trenger å lese ut av den, og hvem som ser utdataene. Tar du feil på ett av dem, blir selve inspeksjonen hendelsen.

Hvilken av de tre filene du har fått

Et PEM-sertifikat er tekst med synlige BEGIN- og END-markører, en DER-fil er binær og trenger et flagg for inndataformat, og en pakke er en beholder som kan inneholde en nøkkel ved siden av sertifikatet. file server.crt skiller tekst fra binært på et sekund, og et blikk på første linje skiller et bart sertifikat fra en profil som inneholder ett. Å gjette her er det som gjør en inspeksjon til en hendelse.

Hvis filen er en profil og ikke et sertifikat, må du behandle den som en legitimasjon til det motsatte er bevist. Den antagelsen koster ingenting, og den forhindrer den vanligste feilen i hele denne oppgaven.

Lesing av de offentlige feltene i et PEM-sertifikat

For et sertifikat du har tillatelse til å inspisere, skriver x509-underkommandoen med -noout ut feltene du velger og ingenting annet. Å undertrykke selve innholdet er det som holder utdataene til metadata, og det er også det som gjør det trygt å lime dem inn i en sak. Velgerne nedenfor er de offentlige, og dokumentasjonen for openssl x509 lister opp resten.

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

På et lokalt generert testsertifikat skriver den kommandoen ut en subject- og issuer-linje, paret notBefore og notAfter og ett SHA-256-fingeravtrykk. Disse feltene identifiserer objektet; de etablerer ikke en gyldig tillitskjede, som er en egen verifiseringsoppgave med sin egen kommando og sitt eget svar. En kjedefil kan også skrive ut bare det første sertifikatet med mindre du går gjennom filen selv. Å sammenligne to filer på denne måten koster én kommando og avgjør hvilken av dem motparten faktisk presenterer.

Pakker som inneholder en nøkkel ved siden av sertifikatet

En .p12 eller .pfx fil kan inneholde en privat nøkkel, og parsingskommandoen skriver den ut med mindre du undertrykker den delen av utdataene. Med -nokeys rapporterer den samme kommandoen fortsatt beholderens struktur, inkludert en innhyllet nøkkelbag, uten å sende ut noe nøkkelmateriale; fjerner du flagget, dukker en nøkkelblokk opp i terminalen og i skallhistorikken.

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

En OpenVPN-profil inneholder det samme materialet som tekst, så grensen er synlig hvis du vet hvor du skal se. Offentlig materiale ligger mellom BEGIN CERTIFICATE og END CERTIFICATE, mens alt mellom BEGIN PRIVATE KEY og den tilhørende END-linjen er nøkkelen og må ikke forlate verten. Kopierer du profilen i sin helhet, publiserer du begge.

Skaffe referanseverdien fra et annet sted

Et fingeravtrykk lest fra tilkoblingen du prøver å verifisere, beviser ingenting, fordi parten du mistror, leverte det. Det er ikke et argument mot fingeravtrykk; det er et argument om opprinnelse. Sammenlign verdien med en som er hentet gjennom en kanal motparten ikke kan skrive til, for eksempel sertifikatet som er publisert i et internt depot, eller hashen som er skrevet ut i en signert endringsoppføring.

Der et tillitslager utfører valideringen, la det gjøre det, og les feilen det produserer i stedet for å erstatte den med din egen sammenligning. Det som betyr noe, er hvem som leverte referansen, ikke hvilken hashfunksjon som ble brukt.

Dele resultatet, og hva du gjør etter en glipp

Send den nøyaktige valideringsfeilen, de relevante datoene og bare de identitetsopplysningene mottakeren trenger. Interne vertsnavn og kontoidenter er følsomme selv når ingen nøkkel er til stede, og en offentlig lim-inn-tjeneste er feil destinasjon for noe av det. Lim inn i saken, ikke i en midlertidig buffer som noen andre deler.

Hvis nøkkelmateriale faktisk dukket opp på skjermen eller i en fil, må du behandle det som kompromittert og rotere det i stedet for å håpe at ingen så det. Skriv deretter ned hvilken fil som ble inspisert, hvilken kommando som ble brukt og hvor utdataene havnet, fordi den oppføringen er det som gjør en skremmende hendelse om til en prosedyre. Rotering er billig sammenlignet med kostnaden ved å anta at ingen tok et skjermbilde, og den samme oppføringen forteller neste ingeniør hvilke filer som i det hele tatt ble berørt. Gjør begge deler før saken lukkes.