openssl genrsa -out private.pem mi dává soubor PEM, který obsahuje pouze soukromý klíč
Ve skutečnosti ne. V zásadě může RSA ukládat pouze privatekey bez publickey, ale formát RSAPrivateKey používaný OpenSSL (od PKCS1 aka RFC 2313 2437 3447 8017) ukládá oba. Formáty používané pro jiné asymetrické algoritmy (DSA, DH, ECC) mají také tuto vlastnost, což znamená, že můžete vždy uložit pouze soubor privatekey a stále získat publickey, kdykoli je potřeba. GPG dělá totéž; informace o veřejném klíči jsou vždy obsaženy v „tajném“ klíči, jak jej nazývají z historických důvodů. OpenSSH (většinou) používá formáty OpenSSL, takže to není užitečné pozorování.
openssl rsa -in private.pem -outform PEM -pubout -out public.pem mi dává soubor PEM, který obsahuje veřejný klíč
Který obsahuje pouze veřejný klíč. A je to docela zbytečné, protože (1) je možné jej regenerovat ze souboru privatekey a (2) většina aplikací nepoužívá pouze publickey, ale místo toho certifikát.
Takže po provedení těchto 2 příkazy Mám pár klíčů RS-256 (je to správný název? Pokud je mi známo, klíče jsou 2048 bitů, tak proč RS-256, ne RS-2048?).
Technicky je to pár klíčů, ale jak je uvedeno výše, OpenSSL v zásadě slučuje koncept keypair s privatekey a rozlišuje pouze publickey - což je ten, který je třeba odlišit, protože je veřejný.
Ano, krypto klíče se téměř vždy měří v bitech. Název schématu RS256 (bez pomlčky) se v JSON Web Signature (JWS) a JSON Web Token (JWT) používá k označení podpisu RSA (konkrétně schéma podpisu RSA RSASSA-PKCS1-v1_5 definované PKCS1) s SHA-256 pro hash . To nesouvisí s velikostí klíče RSA a lze jej použít s jakoukoli (implementovanou) velikostí; příklad klíče pro RS256 v RFC7517 je 1024bitový - ačkoli RSA-1024 dnes neposkytuje dostatečnou míru bezpečnosti a je autority jako NIST a CABforum (a tedy většinou webových prohlížečů) již několik let zakázán. Podpis RSA (a také šifrování RSA) se používá v mnoha jiných aplikacích než JWS / JWT.
Mohu považovat 2 soubory, které mám (private.PEM + public.PEM) za certifikát, který již existuje?
Nejprve objasnění: „certifikát“ je obecný pojem používaný v mnoha kontextech. U kryptoměn jsou zájmové certifikáty obvykle certifikáty veřejného klíče, které váží veřejný klíč k identitě (nebo někdy roli) s některými souvisejícími atributy, a nejběžnější jsou zdaleka certifikáty veřejného klíče definované X.509, standard vytvořený v roce 1988 tehdejším CCITT (nyní-ITU-T) a od té doby vylepšený a vyrobený užitečnějším, ale ne zásadně odlišným, mnoha normalizačními organizacemi. Internetové standardy pro certifikáty jsou založeny na X.509 a nazývají se infrastruktura veřejného klíče pomocí X.509, zkráceně PKIX. X.509, stejně jako některé další počítačové standardy, představuje svá data pomocí generické syntaxe s názvem Abstract Syntax Notation 1, zkráceně ASN.1.
S tím bylo řečeno, NE. Certifikát veřejného klíče / X.509 obsahuje publickey, ale nejedná se pouze o publickey. Obsahuje spoustu dalších informací, které jsou pro jeho fungování zásadní se používá, ačkoli publickey je pravděpodobně nejdůležitější jednotlivá informace. Certifikát je vytvořen pro publickey, obvykle zabalený jako žádost o podpis certifikátu aka CSR nebo jen požadavek, entitou zvanou Certifikační autorita nebo CA, která digitálně podepíše certifikát pomocí klíč CA, aby jej nikdo jiný nemohl změnit, a tak mu může důvěřovat jakýkoli program, který jej používá. V zásadě může kdokoli působit jako CA, a zejména program příkazového řádku OpenSSL může provádět technické operace, které CA provádí, jako je vydávání certifikátů. Ve většině situací však hodnota a užitečnost certifikátu závisí na tom, jak dobře a široce je důvěryhodný vydávající certifikační úřad, takže nejúspěšnější certifikační autority jsou ty, které se etablovaly jako důvěryhodné, například Digicert-now-including-Symantec-formerly -Verisign, Comodo, GoDaddy atd.
Jako zvláštní případ je možné mít certifikát s vlastním podpisem, který je podepsán pomocí vlastního klíče namísto klíče CA. Tento certifikát nemůže vyjádřit důvěru jako od skutečného CA, protože NENÍ účinně chráněn před nahrazením, ale lze jej vytvořit, i když nemůžete kontaktovat a / nebo zaplatit CA, a lze jej obvykle zpracovat pomocí manuální schválení nebo přepsání programy, které jsou navrženy tak, aby normálně používaly nebo vyžadovaly certifikát.
Jaký je obsah souborů CER, CRT nebo P12? Nemohu najít žádné skutečné příklady těchto souborů.
CER a CRT jsou (obě) běžně používány jako přípony souboru obsahujícího certifikát X.509 a mohou být v obou případech závislé na souborovém systému. Pro obsah souboru se používají dvě běžná kódování: „DER“, což je binární kódování (Distinguished Encoding Rules) definované v ASN.1; a „PEM“, který převádí binární DER na base64, rozdělené na řádky vhodné velikosti a s přidanými řádky záhlaví a přívěsu, což je pro lidi výhodnější, zejména pro věci, jako je vyjmutí a vložení. PEM je pojmenován proto, že toto kódování bylo původně definováno pro Privacy Enhanced (e) Mail, což je schéma, které bylo nahrazeno jinými e-mailovými a zprávovými technologiemi, ale tento formát se nadále používá. Tato kódování vypadají velmi odlišně, ale obsahují přesně stejné informace (pokud nejsou poškozena) a mnoho programů, které se zabývají certifikáty, dokáže číst obojí. Soubory PEM napsané OpenSSL často obsahují informace o komentáři před záhlaví nebo po upoutávce; programy by to měly ignorovat, ale někdy jsou zmatené a musíte odstranit cizí informace. Ve Windows také opatrně NEPOUŽÍVEJTE formát „UTF-8“, který obvykle přidává Byte Order Mark, který není viditelný na displeji, ale narušuje program, který soubor čte.
Ačkoli je PEM široce používán pro certifikáty a mnoho souborů PEM jsou certifikáty, mějte na paměti, že PEM se používá i pro mnoho dalších věcí. Nepředpokládejte, že soubor PEM je certifikát; místo toho zkontrolujte řádek záhlaví, který pro tento případ pohodlně říká ----- BEGIN CERTIFICATE ----- nebo někdy ----- BEGIN X509 CERTIFICATE ----- . Viz rfc7468, kde najdete mnohem více podrobností.
P12 se běžně používá k identifikaci souborů ve formátu PKCS12 aka PFX, který je zcela odlišný. Ačkoli standard PKCS12 podporuje velké množství možností, obvykle se používá k uložení soukromého klíče PLUS odpovídající certifikát PLUS ve většině případů jeden nebo více „řetězových“ nebo „přechodných“ certifikátů, které jsou potřebné k vytvoření řetězce důvěryhodnosti ověřte certifikát koncového subjektu. V praxi jsou soubory PKCS12 vždy binární, i když neexistuje žádný technický důvod, proč by nemohly být kódovány pomocí PEM nebo jinak vytvořeny s ohledem na lidskou stránku.
Jak generovat CER, CRT nebo P12 z mého Soubory PEM, které mám?
Chcete-li získat certifikát, musíte buď použít CA (buď zavedenou, nebo vlastní DIY) nebo vytvořit certifikát s vlastním podpisem. Pravděpodobně existují stovky variant každého z nich v závislosti na tom, jaký software (a CA, pokud existuje), který používáte, ale u OpenSSL a většiny CA je obvyklý postup:
- Vytvořte CSR pomocí
openssl req -new -key privatekey [... další možnosti] >csr
Podívejte se na manuálovou stránku req pro podrobnosti. Chcete-li použít certifikát pro SSL / TLS včetně HTTPS , zadejte jako „běžný název“ (nebo) název, pod kterým bude server přistupován, což je obvykle jeho plně kvalifikovaný název domény. (FQDN). Pokud chcete certifikát použít pro jiné aplikace, závisí potřebné informace o identitě na aplikacích.
- U skutečné CA odešlete CSR CA (často na webovém formuláři, který PEM umožňuje) spolu s dokladem totožnosti nebo jiným oprávněním a případně platbou , vyžadují.
Na oplátku byste měli obdržet nově vydaný certifikát „koncové entity“ (obsahující vaše publickey a identitu) a obvykle jeden nebo dva certifikáty obsahující publickey (s) a identitu (y) pro zprostředkující CA použité k vytvoření řetězec důvěry. Mohou to být samostatné soubory (buď DER nebo PEM), nebo zřetězení (pouze PEM) nebo konkrétní případ standardu PKCS7 (SignedData bez certifikátů pouze pro data nebo podpisy), který se obvykle nazývá P7B nebo P7C.
2 '. Nebo to udělejte sami. Vytvořte klíč CA a cert (pouze jednou) a poté použijte openssl ca ... nebo openssl x509 -req -CA -CAkey ... ke čtení CSR a vystavit certifikát pod vlastní CA.
Tento certifikát bude použitelný pouze u systémů a programů, které ovládáte sami, nebo lidé, kteří vám implicitně důvěřují a jsou technicky schopni nainstalovat váš certifikát CA, což je obvykle malá skupina , někdy prázdný. Dávejte také pozor, abyste svému certifikačnímu úřadu a certifikační autoritě koncového subjektu nedali stejný název, například přijetím výchozích hodnot v req ; pokud to uděláte, výsledné certifikáty nebudou nikde použitelné.
- Použijte cert společně s privatekey a řetězovými certifikáty podle potřeby. To může zahrnovat jejich kombinace do PKCS12 pomocí
openssl pkcs12 -export .
Jak je uvedeno výše, můžete místo certifikátu vydaného CA vytvořit certifikát s vlastním podpisem. Nahraďte kroky 1 a 2/2 'jediným krokem: openssl req -new -x509 -key privatekey ... >cert
Všimněte si přidání -x509 a na stránce manuálu je popsáno mnoho dalších možností. To má všechny vlastnosti a omezení DIY CA a další: vy (a / nebo vaši přátelé) nemůžete pouze nainstalovat certifikát DIY CA jednou, ale musíte nainstalovat každý certifikát koncového subjektu samostatně a opakovat proces kdykoli na jednom z vaše certifikáty musí být vyměněny, protože vyprší nebo se změnily jakékoli relevantní informace.
Viděl jsem nějaké informace, že soubor P12 lze chránit heslem - jaký je důvod chránit tento soubor heslem - toto heslo musí být znovu někde uloženo, již soubor P12 ukládáme na bezpečné místo, kde nikdo měli byste mít přístup, že?
Heslo nemusí být nutně uloženo; programy to mohou v případě potřeby vyzvat (a zejména program openssl to dělá). Ačkoli se nyní PKCS12 / PFX často používá k ukládání, původně byl určen k přenosu soukromého klíče s cert (y) z jednoho systému do druhého, což je proces, který často není bezpečný. Dokonce i pro úložiště se někdy ukáže, že systémy a místa, která si myslíte, že jsou bezpečná, nejsou a hloubková ochrana šifrování soukromého klíče stojí za to. Ale v některých případech ano, heslo je jen malý kousek práce navíc bez skutečného přínosu.
Viděl jsem nějaký příklad, kdy 1 soubor PEM obsahoval veřejný i soukromý klíč. Neexistuje rozhodnutá struktura PEM? Mohu tam dát nějaké klíče, které chci?
Zda lze číst více než jeden objekt, a tedy se do něj užitečně uložit, jeden soubor PEM, závisí na programu, který provádí čtení. OpenSSL ve většině (ale ne všech) případech to zvládne, takže používání takových souborů s OpenSSL (a programy, které volají knihovnu OpenSSL) je mírně běžné; jiné programy a knihovny se mohou lišit. Jak je uvedeno výše, ukládání publickey jako takového není téměř nikdy užitečné. Ukládání např. užitečný může být privátní klíč a certifikát , nebo všechny certifikáty v řetězci. Programy jako Apache httpd a nginx to podporují (ale nevyžadují to).
Viděl jsem také soubor PEM, který měl „----- BEGIN CERTIFICATE -----“ a „----- END CERTIFICATE -----“. Co je to za certifikát?
Certifikáty obecně viz výše. Chcete-li znát podrobnosti konkrétního certifikátu (jméno vlastníka klíče, nazývaného „předmět“; veřejný klíč; časové období platnosti certifikátu; vydávající CA a jeho sériové číslo atd.), Můžete použít openssl x509 -text <file nebo v závislosti na vašem systému obvykle několik dalších programů dokáže zobrazit podrobnosti certifikátu. V systému Windows pro .cer .crt stačí kliknout na soubor (nebo pojmenujte jej v dialogu „spustit“ nebo v příkazu start v CMD) a objeví se dialogové okno obsahující kartu Podrobnosti.