Hol laknak az RSA n, e, d, p és q értékei egy VPN-kulcsfájlban

Az RSA magyarázatában a betűk egyetlen objektum belső mezőit nevezik meg, nem olyan fájlokat, amelyeket egy PKI-eszköz kiad. A privátkulcs-fájl olyan struktúrát tartalmaz, amelynek első mezői nyilvánosak, későbbi mezői pedig soha nem hagyhatják el azt a gépet, amely lezárja az alagutat. E két tény között van a gyakorlati kérdések többsége arról, melyik fájl melyik kérdésre válaszol. Ez a kézikönyv először a struktúrát olvassa, majd azokat a parancsokat, amelyek kiontés nélkül vizsgálják.

Erősítse meg, hogy a kulcs RSA, mielőtt prímeket keres

A tanúsítvány bizonyítja, hogy létezik valamilyen kulcs, és aláírták; nem bizonyítja, hogy a kulcs RSA. A rendszerek épülhetnek elliptikus görbékre vagy Ed25519-re, és ugyanaz a könyvtárelrendezés szolgálja mindegyiket. Ellenőrizze az algoritmust, mielőtt olyan prímtényezőket kezdene keresni, amelyek soha nem voltak ott.

Ez a három csak olvasható parancs megválaszolja a kérdést, és rögzíti az eszköz verzióját.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

A verzió számít, mert az opciónevek elmozdultak a fő kiadások között. A tanúsítvány kimenetében keresse meg a nyilvános kulcs algoritmusának sorát és a kulcs méretét; a kulcs kimenetében az RSA kulcs moduluszt és nyilvános kitevőt ír ki. Az elliptikus görbe kulcsa helyette megnevezett görbét ír ki, és semmilyen keresés nem ad belőle n-t vagy q-t.

A struktúrát olvassa a base64 helyett

A PEM fejlécekbe csomagolt base64, és dekódolása DER-t ad, azaz szerializált struktúrát, nem egyetlen hatalmas egész számot. Az RSA privátkulcsok két elterjedt konténerben utaznak, PKCS#1 és PKCS#8, és mindkettő ugyanarra a számhalmazra oldódik.

Két prím esetén a privát struktúra kilenc mezőt hordoz: egy verziót, az n moduluszt, az e nyilvános kitevőt, a d privát kitevőt, a p és q prímeket, két CRT-kitevőt és egy CRT-együtthatót. RFC 8017 A.1 szakasz definiálja ezeket az összetevőket és az ASN.1-elrendezést, és kettőnél több prímet is megenged, ezért egy általános elemző további prímbejegyzéseket írhat ki. Figyelje a sorrendet, mert gyakori hibát magyaráz: a nyilvános fél a privát fájlon belül tárolódik, így egy nyilvános mező jelenléte nem teszi a fájlt megosztásra biztonságossá. Minden, ami utána jön, az az anyag, amelynek a gazdagépen kell maradnia.

A kódolás olyan réteget ad hozzá, amely könnyen összetéveszthető a tartalommal. openssl asn1parse fáként rajzolja ki a struktúrát, hogy a mezők sorrendje láthatóvá váljon, és semmit nem fejt vissza, és nem mondja meg, hogy a kulcs használható-e.

Párosítson tanúsítványt kulcshoz a kulcs kiírása nélkül

A következő kérdés általában az, hogy a tanúsítvány és a kulcs összetartozik-e. A moduluszok összehasonlítása megválaszolja, de a priváthoz közeli anyagot is átmásol egy terminálnaplóba, amely jegybe kerülhet. A nyilvános felek összehasonlítása ugyanarra a kérdésre válaszol anélkül, hogy bármi érzékeny lenne a képernyőn.

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

Azonos fájlok azt jelentik, hogy a tanúsítvány hordozza annak a kulcsnak a nyilvános felét, a különbség pedig azt, hogy rossz párt tart. Ez az eltérés a leggyakoribb oka annak az alagútnak, amely vidáman tárgyal, majd elutasítja a hitelesítést. Utána távolítsa el a két ideiglenes fájlt; semmi titkot nem tartalmaznak, de egy tiszta munkakönyvtár könnyebben átgondolható egy incidens közepén.

Tudja, mik nem a szomszédos fájlok

A tanúsítvány nem egy titkosított nyilvános kulcs, amelyet a partner a CA-tanúsítvánnyal nyit ki; ez egy aláírt kapcsolat egy nyilvános kulcs és az identitásadatok között. A CA privát aláírókulcsa elkülönül a saját tanúsítványától és minden ügyfélkulcstól. A kérés sem tanúsítvány: hordozza a kért információt és a nyilvános kulcsot a kérésre tett aláírással, ami belépési adattá teszi, nem jogosultsági bizonyítékká.

Ezek közül kettőt elég gyakran kevernek össze az RSA-paraméterekkel ahhoz, hogy kétszer is meg kelljen nevezni. Egy Diffie-Hellman paraméterfájl csoportparamétereket tartalmaz a kulcs létrehozásához, és egyetlen RSA-prímet sem, bár maga is nagy prímként íródik ki. A visszavonási lista a tanúsítványok állapotát teszi közzé, és nem olyan hely, ahol privát kitevő elrejtőzhetne.

Ezért minden leltársornak négy dolgot kell rögzítenie: objektumtípus, tulajdonos, cél és azt, hogy tartalmaz-e privát anyagot. Az utolsó oszlop dönti el, hová másolható a fájl, és éppen ezt hagyják ki az emberek.

Rögzítse a párosítást, majd ellenőrizze a kézfogást

Mielőtt bármit módosítana, mentse el az ellenőrzés kimenetét a dátummal és az OpenSSL verziójával. Így egy későbbi rotáció összehasonlítható bizonyítékokkal, nem emlékezettel.

openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates

A nyilvános kulcs összehasonlítása után járja végig a párt fogyasztó útvonalat: hozza fel az alagutat, erősítse meg, hogy a tanúsítvány bemutatásra és elfogadásra kerül, és ellenőrizze, milyen identitást rögzített az átjáró. Ha a kulcs és a tanúsítvány egyezik, és a hitelesítés mégis meghiúsul, a hiba a bizalomban, az identitásleképezésben vagy a hozzáférési szabályzatban van, nem a párosításban.

Visszaállításhoz tartsa az előző kulcsot és tanúsítványt dátumozott könyvtárban, és állítsa vissza mindkettőt együtt, soha ne csak az egyiket. A tanúsítvány nélküli kulcs és a kulcs nélküli tanúsítvány kívülről ugyanúgy meghiúsul, ami a félig visszaállított párokat hajnali kettőkor költségessé teszi kibogozni.