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.
- 773 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Arra gondoltam, hogy azért használom a M$ megoldását, mert az kattintgatós, kollégáim talán jobban fogják szeretni. Ehhez képest már a tanúsítvány érvényességi idejét is csak registryben lehet átállítani.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Csak két gondolat:
1. Template csak enterprise CA-ban van (ehhez AD kell).
2. Ha template van (és Enterprise CA), akkor a private key exportot a template-n kell engedélyezni, a CSR-ben hiába adod meg.
Jalos
- A hozzászóláshoz be kell jelentkezni
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?").
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Illetve kicsit pontosabban: sem a csr-ben sem a cert-ben nincs privát kulcs. Viszont cert-et összecsomagolhatjuk a privátkulccsal pl. egy *.p12 (vagy *.pkcs, *.pfx) fájlba.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
"a self signed certekre panaszkodni fog a böngésző"
Kivéve, ha a gyökértanúsítványát telepítem magamnak, mert onnantól kezdve megbízhatónak tartja. De mégsem működik, így sem...
- A hozzászóláshoz be kell jelentkezni
mert ott önmaga a gyökértanusítvány, az szopi. Lehet saját CA, amivel aláírod, és a akkor menni fog.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
azok az openssl-ek amiket én ismerek a "file" helyett "in"-t szeretnek:
openssl x509 -noout -text -in abc.cer
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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:// ?
- A hozzászóláshoz be kell jelentkezni
Ez most az 1.2.3.4 nevű gépre lenne jó (tehát nem IP-című, nevű), de valóban, ma már a SAN (is) elvárt.
Valamint a lejárati idő is meghaladja a manapság divatos 13 hónapot.
- A hozzászóláshoz be kell jelentkezni
jogos, fejbol irtam a parancsot :)
- A hozzászóláshoz be kell jelentkezni
Á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?
- A hozzászóláshoz be kell jelentkezni
"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?
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
A láncot (cert-chain) a CA-tól kell elkérni, tipikusan két elemű: IntermediateCA certje és RootCA certje. Ugyanabba a fájlba (.pfx, .cert.pem) lehet tenni, ahol maga az EE (EndEntity) certje van.
- A hozzászóláshoz be kell jelentkezni
A pfx-et odaadva openssl-nek (openssl pkcs12 -in foo.pfx -nodes), megadva a jelszót mit mond?
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
8 vagy 12 az, ami cert/kulcs+cert tárolására való, ha jól rémlik...
- A hozzászóláshoz be kell jelentkezni
pkcs8 csak kulcs, a pkcs12 (pfx) a kombinált cert+kulcs formátumra való.
- A hozzászóláshoz be kell jelentkezni