tanúsítvány kulcs exportálása

Security-all

Sziasztok!

 

Windows server 2019-en készítek tanúsítványokat a Certification Authorityvel, melyekből ki akarom menteni a kulcsot. Ez alapján készítem a csr-t, bejelölve, hogy a kulcs exportálható legyen. A kész tanúsítványból mégsem tudom exportálni:

Export-PfxCertificate -cert Cert:\CurrentUser\My\ABF... -FilePath .\xxx.pfx -ChainOption EndEntityCertOnly -NoProperties -Password (ConvertTo-SecureString -String 'jelszo' -AsPlainText -Force)

Export-PfxCertificate : Cannot export non-exportable private key.

Amikor a CA-ból megnyitom a tanúsítványt, csak X.509 és P7B formátumokba hajlandó exportálni, PFX-be nem.

( Friczy v | 2022. 09. 23., p – 13:45 )

A tanúsítványból nem is, abban csak a publikus kulcs van benne. Gondolom, itt a tanúsítványtárat szeretted volna írni.

Segíteni nem tudok, mert nem értek hozzá, csak kötözködöm, annak érdekében, hogy megfelelő terminológiát használj.

( gemnon v | 2022. 09. 23., p – 16:40 )

Szerkesztve: 2022. 09. 23., p – 17:11

Non-exportable private keyről valami NISZ-es szarság jut eszembe (VIP gizi kihagyta az IT-t, vagyis (3rd) party IT-t használt aztán költözött volna), azt hiszem a Mimikatz exportálta ki.

De a fentiből a privát kulcs nem igazán volt exportálhatónak jelölve.

( NevemTeve | 2022. 09. 23., p – 17:16 )

Ha még az elején vagy, akkor kezd előről, de most sk generált kulcsot használj (openssl, keytool, certutil valamelyik csak van).

( n.balazs v | 2022. 09. 23., p – 20:36 )

Nekem nem világos, hogy pontosan hol generálod a CSR-t, melyik gépen. Ahol generálod, ott lesz mellette a privát kulcs is.

A CA template-nek, enrollment policy-nak mik a beállításai? Abban szerepel, hogy egyáltalán a privát kulcs exportálható legyen?
Megnyitod az adott Certificate template-t szerkesztésre, azon belül pedig a Request handling fülön az Allow private key to be exported mezőt be kell pipálni.
Ha már ott vagy, akkor nézd végig a többi beállítást is és állítsd be jól (pl: request hash legyen minimum SHA256, a subject name honnan jöjjön stb.). Különben orbitális szívásokba futhatsz bele (pl: SHA1 aláírás már unsecure és több szoftver se fogadja el az ilyen tanúsítványokat).

Ezt a CSR-t ugyanazon a gépen generálom, mint amin a tanúsítványt. Binárisan megvan a kulcs, exportálni is tudom - de az megint csak nem egyszerűsíti az életet, ha kézzel kell a nyers bináris kulcsból szabványos formátumot generálni.

Custom reqestet készítettem, enrollment policy nélkül. A kulcs méretét 2048-ra állítottam, kipipáltam, hogy exportálható legyen, sha256 a hash algoritmus.

Kérdéseim:
- Ha megvan a kulcs és exportálni is tudod, akkor mi a gond?
Ehhez kapcsolódóan ugye a privát kulcsot védeni kell. Ha szoftveres védelem van és nincs nagyon nyomós indokod, akkor SOHA ne vidd át máshová a privát kulcsot! Mindig ott generáld a CSR-t, ahol a tanúsítványt később fel fogod használni. Így a privát kulcsnak sose kell elhagynia a rendszert.

- Mit értesz szabványos formátum alatt? A PKCS8, PKCS12, PEM, DER stb. mind szabványos formátum.
Mely formátumok ekvivalensek egymással - kis túlzással:
PEM = Base64 enkódolt formátum, szöveges fájl, leggyakrabban használt
DER = bináris formátum

A PKCS szabványok - bármelyik lehet PEM és DER formátumban is - leegyszerűsítve:
PKCS8 = privát kulcs
PKCS10 = CSR
PKCS12 = mindent tartalmaz (privát kulcsot és a tanúsítványt is, akár a tanúsítványláncot is), jelszóval védett

- Egy step-by-step leírást nem olyan nehéz csinálni, Egyszer összerakod, akkor bármelyik kolléga* végre tudja hajtani.
*: Csak ne adj túl sok jogot mindegyik kollégának. Nehogy pl. visszavonja a CA saját tanúsítványát.

 

- Elárulod, hogy mi a teljes use case, amit le akarsz fedni?
Én a következőt tudnám elképzelni a leírásod alapján:
1. Valahol valakinek/valaminek szüksége van X509 tanúsítványra. Ezt a valamit hívjuk mondjuk igénylőnek. Csak szoftveres eszközök vannak, biztonságos kulcstároló (hw token), HSM nincs a rendszerben. Csak Windows CA-d van, elég, ha ez cégen belül működik.
2. Az admin az igénylő rendszerben legenerál egy CSR-t. A privát kulcs csak az igénylő rendszerben létezik. A privát kulcs exportálható vagy sem - utóbbi a biztonságosabb.
3. Next-next-finish módszerrel beküldöd a CSR-t a Windows CA-nak, ami a beállított template-k alapján kiállít egy X509 tanúsítványt. A Windows CA-ban ez a tanúsítvány lesz elérhető, letölthető.
4. Az igénylő a Windows beépített metódusain keresztül megkapja a Windows CA-tól a tanúsítványt. Az igénylő a saját tanúsítványtárában (Windows beépített)  összepárosítja a CSR-t, a privát kulcsot és a kiadott tanúsítványt.
5. A tanúsítvány használható. Mindenki boldog.

Hol a hiba a fenti leírásomban? Mi maradt ki? Mi az, amit netalán másképp szeretnél?

1. Feltételeztem, hogy enterprise CA van. Igazad van.

2. Ezért írtam oda korábban: https://hup.hu/comment/2833098#comment-2833098 ("A CA template-nek, enrollment policy-nak mik a beállításai? Abban szerepel, hogy egyáltalán a privát kulcs exportálható legyen?").

Köszönöm a részletes választ.

Azt értem, hogy a felsorolt formátumok mind szabványosak. Ezek egyikére szerettem volna hozni a bináris kulcsot.

Azt értem, hogy a tanúsítványkibocsátó privát kulcsával írja alá a tanúsítványokat, így bocsátja ki azokat. A kiadott tanúsítványban is szerepel egy privát kulcs, ahogy írod is, a CSR-ben, ezt írja alá a CA. Na ezt a kulcsot akartam kimenteni.

TP-Link switchekbe akartam gyártani tanúsítványokat, hogy a böngésző ne panaszkodjon állandóan, hogy nem fogadja el a tanúsítványát. A switchekbe lehet is feltölteni tanúsítványt, de kér privát kulcsot is. Amúgy CSR-t sem lehet gyártani a switchben...

Találtam egy leírást:

https://www.tp-link.com/us/configuration-guides/configuration_guide_for…

Ez nem a windowsos CA-val mutatja be a tanúsítványkészítést. És itt a CA privát kulcsát menti le, dolgozza be a switchbe...

Ami nevetséges, hogy a leírás alapján a végén az új tanúsítvánnyal is ugyanúgy panaszkodik a böngésző a tanúsítványra. Mintha a tanúsítványnak nem lenne root tanúsítványa? A root CA tanúsítványát hiába telepítem magamnak, akkor is panaszkodik a böngésző. Jó helyre telepítem magamnak, más eszközbe is telepítettem már tanúsítványt, ott működik.

"3.2 Using a Self-Signed Certificate"

Igen, mert ez egy önaláírt kulcs, össze van keverve a szezon az izével. És nem nevetséges*, a self signed certekre panaszkodni fog a böngésző.

*ill hát de, mert elég fosul van kezelve az ügy, de az teljesen normális, hogy a self signed certről először megkérdezi, hogy ez mi, mert nem tudja megmondani, hogy megbízható-e, nincs miből.

 

Ez nem a windowsos CA-val mutatja be a tanúsítványkészítést. És itt a CA privát kulcsát menti le, dolgozza be a switchbe...

 

Megnezte a leirast, itt nincs semmifele CA, csak self-signed-et csinal a tool amit a sourceforge-rol toltet le veled. 

 

 A root CA tanúsítványát hiába telepítem magamnak, akkor is panaszkodik a böngésző. Jó helyre telepítem magamnak, más eszközbe is telepítettem már tanúsítványt, ott működik.

Itt tippre nem az lesz a baja, hogy a rootCA rossz / nem ismeri el megbizhatonak, hanem hogy a tanusitvanyban nem a switch IP-cime / neve van benne. 

Egy openssl x509 -noot -text -file abc.crt kimenetet masolj mar be pls. 

"Megnezte a leirast, itt nincs semmifele CA, csak self-signed-et csinal a tool amit a sourceforge-rol toltet le veled. "

Ok, kiindulásként is a windowsos tanúsítványkiállítót akartam használni, nekem elég, ha azzal tudok dolgozni.

"a tanusitvanyban nem a switch IP-cime / neve van benne"

Common Name-ként az van benne.

openssl x509 -noout -text -file abc.cer

x509: Unrecognized flag file

Annyit javítottam a parancson, hogy hiányzott a -noout-ból egy u betű. Base64-esként exportáltam.

Rögtön jobban néz ki:

openssl x509 -noout -text -in abc.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            71:00:00:00:0b:19:07:29:85:53:f3:6f:b6:00:00:00:00:00:0b
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: DC = hu, DC = a, DC = b, CN = Root Certification Authority
        Validity
            Not Before: Sep 23 10:21:23 2022 GMT
            Not After : Sep 23 10:31:23 2038 GMT
        Subject: O = myorg, CN = 1.2.3.4
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ef:...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                72:...
            X509v3 Authority Key Identifier:
                keyid:34:...

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:file:////y.b.a.hu/CertEnroll/Root%20Certification%20Authority.crl

            Authority Information Access:
                CA Issuers - URI:file:////y.b.a.hu/CertEnroll/y.b.a.hu_Root%20Certification%20Authority.crt

            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
         81...

Egyrészt nincs benne subject alternative name, arra mostanában a böngészők már sípolnak, másrészt ezek:

               Full Name:
                  URI:file:////y.b.a.hu/CertEnroll/Root%20Certification%20Authority.crl

            Authority Information Access:
                CA Issuers - URI:file:////y.b.a.hu/CertEnroll/y.b.a.hu_Root%20Certification%20Authority.crt

wtf? file:// ?

Áháá, már így világos. Gyakorlatilag web szerver tanúsítványra van szükséged.

Mi problémák itt felmerülhetnek tanúsítvány oldalról:
- Egyáltalán az eszköz mennyire támogatja a korszerű tanúsítványokat? Előfordulhat, hogy pl: 1024 bitesnél nagyobb RSA kulcsot nem tud kezelni. Akkor pedig csöbörből vödörbe.

Ami neked mindenképp kelleni fog:
- A CA tanúsítványláncát mindenkinek el kell fogadnia. A Tp-link eszközöknek (*), azoknak a gépeknek, ahonnan menedzselni akarod a Tp-linkeket. *: Ez talán megúszható, ha a Tp-linken futó szoftver nem végez valahol tanúsítvány ellenőrzést.

Majd este, ha lesz időm, akkor összedobok itt egy kis leírást, hogy hogyan tudod ezt tisztán windowsos eszközökkel megcsinálni parancssorból - kb. mint Opensslnél. Mert hogy ez Windowson is megtehető, csak kevesen ismerik, használják.

Gyors kérdéseim:
- Van Windows CA-d a rendszerben vagy nincs?
- Ha van, akkor standalone vagy enterprise módban működik?

"az eszköz mennyire támogatja a korszerű tanúsítványokat?"

Firmware frissítés előtt, ha bekapcsoltam a https-t a switchen, akkor a böngésző nem volt hajlandó kapcsolódni hozzá.

"Előfordulhat, hogy pl: 1024 bitesnél nagyobb RSA kulcsot nem tud kezelni."

Az újabb firmware-rel bízom benne, hogy kezeli. Ha "megeszi" a tanúsítványt, akkor az azt jelenti, hogy kezeli?

"- Van Windows CA-d a rendszerben vagy nincs?
- Ha van, akkor standalone vagy enterprise módban működik?"

Igen, és standalone módban működik. Lehetne enterprise-ban is: milyen előnyökkel járna?

"Az újabb firmware-rel bízom benne, hogy kezeli. Ha "megeszi" a tanúsítványt, akkor az azt jelenti, hogy kezeli?"

Igen.

"Igen, és standalone módban működik. Lehetne enterprise-ban is: milyen előnyökkel járna?"

Ha van Windows AD-d, akkor illik a CA-t enterprise módban telepíteni - 2 szint esetén a root CA lehet standalone, az intermediate CA pedig enterprise. Így tudod kihasználni az előnyeit az enterprise módnak.
Az AD integráció itt a magic enterpise módban.
Egy rövid leírás az előnyökről / hátrányokról: https://serverfault.com/questions/826444/difference-between-microsoft-a…
És egy Technet link: https://social.technet.microsoft.com/wiki/contents/articles/53249.activ…

Ha jól tudom, akkor a kettő között nincs átjárás. Tehát nem tudod konvertálni a CA-kat másik típusúra.

Sajnos csak most van időm valamiféle leírást produkálni.
2 út áll előtted: GUI-s leírás vagy parancssoros. Előbbi screenshotok összessége, könnyebb elrontani. Utóbbi könnyebben szkriptelhető.

Parancssoros lépésekhez a certreq és certutil parancsokat kell használnod (segítség: https://learn.microsoft.com/en-us/answers/questions/431223/use-certreq-…, illetve https://learn.microsoft.com/en-us/windows-server/administration/windows…, illetve https://techcommunity.microsoft.com/t5/core-infrastructure-and-security…):
1. Az igénylő gépen csinálj egy policy.inf fájlt. Ez hasonló egy Openssl cnf fájlhoz. Ebben beállítasz mindent, amit a tanúsítványban látni szeretnél.
2. Csinálsz egy CSR-t a template alapján az igénylő gépen.
3. Beküldöd a CSR-t a CA-nak. Itt lehet, hogy át kell másolnod a CSR-t az igénylő gépről a CA gépre, ha az nem elérhető távolról.
4. Aláírod a CSR-t a CA-ban és kiadod a tanúsítványt.
5. A CA-tól kapott tanúsítványt importálod azon a gépen, ahol a CSR-t generáltad.
6. Mindezek után a teljes tanúsítványláncot P12 formátumban exportálod azon a gépen, ahol generáltad a CSR-t és ahol ott van a tanúsítvány is.
7. Megpróbálod ezt megetetni a Tp-link eszközzel.

Hogy hogyan is nézzen ki a template, ahhoz érdemes "puskáznod" már meglévő más webszerver tanúsítványokból. Pl: legyen a SAN meződ kitöltve DNS névvel és IP címmel is. Megnézheted a hup.hu HTTPS tanúsítványát is példának.

Köszönöm. Elszórakoztam vele. Arra jutottam, hogy megoldható a dolog, de jobban jártam volna, ha Linux alatt állok neki openssllel...

Addig rendben van, hogy készítek egy PKCS12-es formátumú tanúsítványt. De hogyan nyerem ki belőle a kulcsot certutillal?

Ezen a linken van egy leírás hozzá. Nem valami elegáns, de a hozzászólók sem tudtak jobbat ajánlani. Ráadásul a szükséges powershell modul nekem települt ugyan, de nem működött.

Letöltöttem az openssl windowsos binárisát, azzal ki tudtam nyerni a kulcsot, és be is tudtam dolgozni így a tanúsítványt és a kulcsot a switchbe. De lehet, hogy átviszem az egész műveletsort openssl-re, mert egyszerűbb lesz vele az élet. A jelenlegi műveletsorra készítettem ugyan egy scriptet, de nyakatekertnek tartom az egészet így.

Amúgy a következő, ahol megakadtam az, hogy a Proxmoxsszal megetessem a tanúsítványt. Pontosabban sikerült megetetnem vele, de nincs tanúsítványlánc, a böngésző így nem tartja megbízhatónak...

( zeller | 2022. 09. 26., h – 16:03 )

A pfx-et odaadva openssl-nek (openssl pkcs12 -in foo.pfx -nodes), megadva a jelszót mit mond?

A windowsos CA csak PKCS7-be exportál. De:

openssl pkcs7 -in foo.p7b
unable to load PKCS7 object
140672936994112:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: PKCS7

Amúgy exportáláskor kiírja, hogy nem teszi bele a kulcsot, amit nem értek, hogy miért...