Tanúsítványok, kulcsok tesztelése offline

Kettős kulcsokkal már régóta volt dolgom (pl. id_rsa, id_rsa.pub), ezek szerepe világos volt, generálásuk módja sem okoz ma már különösebb fejtörést.
Még a Let's Encrypt is beépült a hétköznapokba, ott a megfelelő démon teszi a dolgát és kész.
Azonban nemrég jött a radarra a "szerezz tanúsítványt a céges weboldalhoz" című témakör.

Ennek kapcsán körüljártam, hogy hogyan lehet ellenőrizni, hogy melyik fájl mire való (melyek tartoznak össze és miket tartalmaznak). Eleinte azt hittem, hogy (a kettős kulcsok mintájára) ez is triviális és pofonegyszerű témakör lesz, de nem.

Hasznos olvasmánynak bizonyultak:
https://www.linuxjournal.com/content/understanding-public-key-infrastru…
https://en.wikipedia.org/wiki/X.509
https://github.com/zakjan/cert-chain-resolver !
https://medium.com/@superseb/get-your-certificate-chain-right-4b117a9c0… !!

Pár apró kódrészletet osztanék meg + néhány tapasztalatot.
Az egyik, hogy hogy lehet "sima" ssh kulcsokat tesztelni bash-ben:

PRIVKEY=a/id_rsa
TESTKEY=b/id_rsa.pub
diff <( ssh-keygen -y -e -f "$PRIVKEY" ) <( ssh-keygen -y -e -f "$TESTKEY" )

Nem ad vissza semmit, ha rendben van a két kulcs. Fontos, hogy ne ugyanabban a könyvtárban tartsuk a kulcsokat, mert akkor "felderítheti" az openssh és ismertnek veszi őket és akkor is helyest mond, ha nem azokat adjuk át neki, lásd https://serverfault.com/questions/426394/how-to-check-if-an-rsa-public-…

A másik (számomra elsőre) meglepő tény, hogy a titkos kulcsból legyártható egy nyilvános kulcs, így: ssh-keygen -y -f id_rsa > ../b/id_rsa.pub

De az igazán izgalmas téma a webszerver tanúsítványokat érinti.

Maga a folyamat ugye az, hogy először egy "request" (.csr) fájlt kell legyártani (openssl req -out ...), aminek mellékterméke egy titkos kulcs (hívjuk p-nek, fejléce BEGIN PRIVATE KEY vagy BEGIN RSA PRIVATE KEY, nálam 17 soros). A megfelelő szöveges adatokat (igénylő terület stb., visszaolvasásuk: openssl req -in ...csr -noout -text) kódoltan magában hordozó "request" fájl alapján (némi idő után a megfelelő szervezettől) kaptam 3 fájlt, mindnek BEGIN CERTIFICATE a fejléce. Nevezzük őket 1-1 betűvel:

R 12 soros - Root CA Certificate
I 20 soros - Intermediate CA Certificate
S 29 soros - Server certificate

S ezek ellenőrzése, hogy valóban összetartoznak és mi közük az eredeti titkos kulcshoz, na ez nem volt triviális.
Persze lehet mondani, hogy "tőcsd föl osztkész", de kíváncsi voltam valami explicit igazolásra, hogy ezek jók, és én sem rontottam el semmit (pl. a "request" generálásakor).

A titkos kulcs így ellenőrizhető (azaz a Server certificate áll szemben a titkos kulccsal):

PRIVKEY=a/p
SERVKEY=b/S
diff <(openssl pkey -pubout -outform PEM -in "$PRIVKEY" ) <( openssl x509 -pubkey -noout -in "$SERVKEY" )

A tanúsítvány lánc pedig így, miután az R és I fájlokat egybeolvasztottuk: cat R I > RI

p=/home/teljes/eleresi/ut
docker run \
-v $p/S:/certs/cert.pem \
-v $p/p:/certs/key.pem \
-v $p/RI:/certs/cacerts.pem \
superseb/cert-check:latest \
url.pelda.hu

Maga a három tanúsítvány (a titkos kulcs nélkül) így is ellenőrizhető: openssl verify -verbose -CAfile <(cat R I) S
vagy openssl verify -verbose -CAfile R -untrusted I S

Hozzászólások

Az elején van egy kis zavar, az openssh id és id.pub fájljainál: openssl-t írsz de openssh-ra gondolsz:
"Fontos, hogy ne ugyanabban a könyvtárban tartsuk a kulcsokat, mert akkor "felderítheti" az openssl és ismertnek veszi őket..."

Ha már így szóbakerült a tanúsítványok kezelése, hadd ajánljam figyelmetekbe az XCA-t: https://hohnstaedt.de/xca/ Ha muszáj, én is elvagyok az openssl parancs különféle paramétereivel, de ezzel messze kényelmesebb akár csak egy CSR-t is előállítani, hogy pl. az OpenVPN tanúsítványok kezeléséről ne is beszéljünk.