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

Fórumok

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.

Hozzászólások

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.

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.

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).

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.

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...