Vytváření vlastního CA pro intranet

Pokud je vaše infrastruktura malá , většinu podrobností o spuštění CA (např. CRL a podobně) lze pravděpodobně ignorovat. Místo toho se musíte starat pouze o podepisování certifikátů.

Existuje spousta nástrojů, které tento proces za vás zvládnou. Dokonce jsem jeden napsal už před mnoha lety. Ale ten, který doporučuji, pokud chcete něco opravdu jednoduchého, je easy-rsa z projektu OpenVPN. Je to velmi tenký obal kolem nástroje příkazového řádku OpenSSL. Pokud se chystáte spravovat MNOHO certifikátů a skutečně se zabývat odvoláním a takovými věcmi, budete potřebovat mnohem složitější a komplexnější nástroj. Existuje již více než dost návrhů, takže místo toho se budu držet pouze základů toho, čeho se snažíte dosáhnout.

Ale tady je základní postup. Vysvětlím to pomocí OpenSSL , ale jakýkoli systém to udělá.

Začněte vytvořením vaší „kořenové“ CA – bude to certifikát podepsaný svým držitelem. Existuje několik způsobů, jak to udělat; toto je jeden. máme 10letý certifikát s 2048bitovým klíčem.Podle potřeby upravte čísla. Zmínil jste, že se obáváte algoritmu hašování, a proto jsem přidal -sha256, abych zajistil, že je podepsán něčím přijatelným. Šifruji klíč pomocí AES-256, ale to je volitelné Budete požádáni o vyplnění názvu certifikátu a podobně; tyto podrobnosti nejsou zvlášť důležité pro kořenovou CA.

# First create the key (use 4096-bits if that"s what floats your boat) openssl genrsa -aes256 -out root.key 2048 # Then use that key to generate a self-signed cert openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256 

Pokud jste klíč zašifrovali v prvním kroku, budete muset zadat heslo pro použijte jej ve druhém. Zkontrolujte svůj vygenerovaný certifikát a ujistěte se, že v části „Základní omezení“ vidíte „CA: TRUE“. To je opravdu jediný důležitý kousek, se kterým si musíte dělat starosti:

openssl x509 -text < root.cer 

Super. Dobře, teď nechme podepsat certifikát. Budeme potřebovat další klíč a tentokrát požadavek. Budete znovu požádáni o vaše jméno a adresu. Jaká pole vyplníte a co zadáte, záleží jen na vás a vaší aplikaci, ale nejdůležitější je pole „Obecný název“. Zde zadáte své hostitelské jméno nebo přihlašovací jméno nebo cokoli jiného, co tento certifikát osvědčí.

# Create new key openssl genrsa -aes256 -out client1.key 2048 # Use that key to generate a request openssl req -new -key client1.key -out client1.req # Sign that request to generate a new cert openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key -sha256 -CAcreateserial 

Všimněte si, že se tak vytvoří soubor s názvem root.srl to udržujte naše sériová čísla na rovinu. Příznak -CAcreateserial říká openssl, aby vytvořil tento soubor, takže jej zadáte pro první požadavek, který podepíšete, a pak už nikdy. A ještě jednou vidíte, kde přidat argument -sha256.

Tento přístup – dělá vše ručně – podle mého názoru není nejlepší nápad. Pokud provádíte rozsáhlou operaci , pak pravděpodobně budete potřebovat nástroj, který za vás bude moci sledovat všechny vaše certifikáty.

Místo toho jsem chtěl ukázat, že požadovaný výstup – certifikáty podepsaly tak, jak chcete je – není závislé na nástrojích, které používáte, ale spíše na možnostech, které těmto nástrojům poskytujete. Většina nástrojů může generovat širokou škálu konfigurací, silných i slabých, a je na vás, abyste zadali čísla, která určíte m vhodné. Zastaralé výchozí hodnoty jsou pro kurz stejné.

Komentáře

• Je ‚ důležité si uvědomit, že když podepíšete certifikát klienta, jedná se pouze o veřejnou část. CA by neměla přenášet ani generovat žádný soukromý klíč.
• Můžete prosím rozšířit svoji odpověď na vytvoření zprostředkujícího certifikačního úřadu? Děkujeme.
• @Andr é Intermediální certifikáty jsou jen normální certifikáty s basicConstraints = CA:TRUE nastavenými v rozšířených atributech. Nic kouzelného, jen další certifikát.
• @tylerl Kamaráde, ty houpáš.
• Tato odpověď je FANTASTICKÁ a byla velmi užitečná, ale musím přidat aktualizaci z roku 2017. Chrome a další nyní vyžadují rozšíření x509v3 subjectAlternativeName; jinak považují certifikát za neplatný, i když je v systému správně nainstalován kořenový certifikát CA. Nějakou dobu jsem se snažil přijít se správným řešením. Tato stránka byla pro mě neocenitelná a vyřešila pro mě poslední část skládačky: cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO, přidání SAN při podpisu, na rozdíl od požadavku, je jak jednodušší, tak spíš jako to, co veřejné CA ve skutečnosti dělají.

Pokud si opravdu přejete být CA, věnujte pozornost bezpečnostním důsledkům toho.

1. Soukromý klíč použitý ke generování kořenové CA pro váš intranet by měl doslova být uzamčen v trezoru. A přístup k uvedenému trezoru by měl být fyzicky monitorován.
2. Použití kořenové certifikační autority s vlastním podpisem nutí vaše uživatele nejen věřit, že provádíte due diligence s bezpečnou ochranou klíčů, ale také vložit původně nedůvěryhodný root může do svého řetězce certifikátů.
3. Tím se také rozbije funkce sešívání OSCP, pokud jde o externí ověření řetězce certifikátů, což je důvod, proč vůbec existují služby správy identit.

Docela málo by argumentovalo důvody, které stojí za správou vaší vlastní CA, jako například; je určen pro podnikový intranet, kde část našich sestavení pro stolní počítače zahrnuje root nebo je pro malý počet uživatelů.

I když to není nutně špatné, může si to dovolit některé výhody, ale dělá to negovat ověřovací řetězec, pro který byla vytvořena správa identit založená na certifikátu.

Pokud se rozhodnete implementovat svůj vlastní root ca, ujistěte se, že budete dodržovat stejné bezpečnostní postupy jako jakékoli jiné použití root root. Jako společnost poslední věcí, kterou byste chtěli, je, aby někdo prolomil soukromý klíč používaný pro váš root ca a začal podepisovat certifikáty pro phishingové kampaně proti vašim klientům.

K dispozici je spousta průvodců osvědčenými postupy, NIST ( National Institute for Standards and Technology) je spolupracující skupina, která pomáhá při různých standardech pro témata počítačové bezpečnosti.

Doporučené čtení:
Audit (PDF)
Obnova po katastrofě (PDF)
Systémy veřejného klíče (PDF)
Institut Sans týkající se menší nasazení PKI

Dobře, vidím, že jste aktualizovali svoji otázku tak, aby byla konkrétnější.

Dva dokumenty pro konfiguraci vašeho souboru openssl.cnf pro specifika CA:

https://www.openssl.org/docs/apps/ca.html

https://www.openssl.org/docs/apps/config.html

Uvědomuji si, že to nemusí být odpověď, kterou chcete, ale protože prostředí a požadavky každého člověka se liší, pro dobrý příklad konfigurace musíte definovat rozsah své implementace CA.

Komentáře

• Tam ‚ není důvod, proč vaše vlastní CA nemůže ‚ provést OCSP. Dokonce to zvládne i příkazový řádek OpenSSL a to ‚ s o nejnižší možné liště.
• Odkazy openssl jsou nyní 404

Tady není způsob, jak to udělat jednoduše. existuje několik nástrojů, které vám pomohou snadno začít.

líbí se:

• XCA
• EJBCA
• openssl

žádný z nich není plná PKI kromě možná EJBCA, ale to není triviální pro nastavení.

• XCA je malý frontendový nástroj pro získání grafického rozhraní pro generování, podepisování a odvolávání certifikátů.
• EJBCA nebo Enterprise Java Beans Certifikační autorita je JBOSS / Jetty Webapp, který dokáže udělat plnou infrastrukturu PKI pro podnik.
• openssl je základní nástroj příkazového řádku. může provádět všechny offline bity CA, ale žádné z ověření (mimo krabici). můžete si s ním vytvořit svůj vlastní OCSP Verifikátor, ale musíte si pro něj vytvořit „online“ kód sami.

Pokud vše, co hledáte, je správná konfigurace openssl. XCA vám může pomoci je generovat. (má funkci exportu konfigurace openssl

Komentáře

• EJBCA má nyní obrázek VM, který můžete použít. Jinak “ není triviální k nastavení “ lze považovat za podhodnocení. Je to v zásadě obrovský ant skript, který se pokouší nakonfigurovat ( JBoss) aplikační server, který může (a v mém případě bude ) se rozbít.
• obraz VM je nebo pro účely vyhodnocení, takže bych jej nedoporučoval pro produkční server.
• Mohu se podívat do XCA. EJBCA rozhodně není ‚ t možnost – webové rozhraní přidává zbytečnou útočnou plochu a je obtížnější jej nastavit. Rozhodně dávám přednost použití jen openssl.
• @Andr é pokud jde o EJBCA, lze jej použít také z příkazového řádku, takže jste vyhráli ‚ nemusí vystavit webové rozhraní. Ale ‚ je to věc na podnikové úrovni a pravděpodobně je to pro vaše účely přehnané es (a říkám to jako někoho, kdo se tím živí).

Pro některé dobré zázemí, přečtěte si moji prezentaci Jak vytvořit a provozovat své vlastní Centrum správy certifikátů průměrnosti . Podstata prezentace spočívá v tom, že nejpotřebnější není seznam příkazů, které se mají spustit, ale spíše hluboké pochopení všech různých ovládacích prvků, které vstupují do provozu komerční CA, jejich vzájemné interakce, přesného dopadu odstranění všech jeden z nich, kumulativní dopad odebrání několika z nich a zmírňující kontroly nezbytné k vyrovnání snížené bezpečnosti.

Proto neexistuje žádná „kanonická odpověď ohledně nastavení jednoduchého CA.“ Buď vydáte se celou cestou ISO, počínaje klíčovou podepisující stranou, přes duplikované kořenové certifikáty s mezerami a klenbami, více podepisujících zprostředkovatelů, odvolací servery atd. atd., nebo musíte vymyslet nějaký kompromis založený na jedinečné ceně / přínosu a riziku profil, který je firma ochotná přijmout. Každý, kdo má dostatečné dovednosti a zkušenosti k tomu, aby provedl toto hodnocení, nepotřebuje podvod. Mohou analyzovat správnou syntaxi příkazu na základě hlubokého pochopení obchodní funkce, která má být provedena, a bezpečnostních primitiv použitých k implementaci tohoto požadavku.

V prezentaci jsou příběhy ze skutečných střetnutí obchodů, které se vydaly touto cestou a strašně se zmýlily. V některých případech mé hodnocení uvádělo, že absolutně nic, co mohu s vaším zabezpečením middlewaru udělat, může překonat inherentní slabosti interního CA. Kdokoli v USA by si měl uvědomit, že pravděpodobně nakupuje služby alespoň od jednoho z prodejců, kterého se prezentace týká. Jedná se o banky, družstevní záložny, zdravotní pojišťovny, maloobchodníky a další.

Protože doporučení jsou správná, vyžaduje, aby odpovědný pracovník učinil hlavní předpoklady o vašich přijatelných rizikových profilech, a vy, abyste učinili hlavní předpoklady, do jaké míry jsou vaše a jejich představy o riziku sladěny a synchronně je samotný návrh na první pohled riskantní. Ve většině takových případů má posouzení vhodnosti poskytovaných výukových programů více společného s prezentací než s efektivní úrovní zabezpečení vyplývající z dodržování jejich postupů. Pokud je dobře organizovaná a jasně formulovaná, záleží na tom mnohem více, než zda je efektivní. Vybíráme kanonický podvod, který vypadá nám nejlépe.

Z těchto důvodů si nemyslím, že by vám věrohodný odborník poskytl „správné a aktuální openssl.cnf files“, ale spíše by mohl přinejlepším poskytnout proces hodnocení k úplnějšímu posouzení požadavků a přijatelného rizika. Jelikož sázíte na výsledek, žádný důvěryhodný odborník by to mimo ochranu smlouva. Jakákoli doporučení, která získáte, by téměř ze své podstaty musela být od in důvěryhodného odborníka. Hodně štěstí.

Komentáře

• I pro intranet pro interní zdroje? Můžete také označit, že prezentace je vaše vlastní.
• “ I pro intranet pro interní zdroje? “ Speciálně pro intranet, protože ‚ s tam, kde dochází k největšímu narušení dat. “ Můžete také označit že prezentace je vaše vlastní. “ Myslel jsem, že jsem měl při popisu své zkušenosti s prováděním hodnocení, ale bod vzat. Aktualizoval jsem ji ‚.

Postupujte podle těchto pokynů pokyny ke konfiguraci certifikační autority založené na systému Windows . Protože vydáváte klientské certifikáty, mějte na paměti, že hash SHA2 není v systému XP podporován.

Jednoduchá odpověď je:

1. Nainstalovat AD
2. Nainstalujte Enterprise CA na řadič domény
3. Upravte šablonu certifikátu tak, aby vydávala certifikáty koncového uživatele (nastavte oprávnění pro vlastní registraci uživatelů nebo přejděte na webovou stránku)
4. Nasadit veřejný klíč kořenového certifikátu na všechny servery, které ověřují uživatele
5. Pokud jsou uživatelé ve službě AD, povolte automatický zápis pomocí GPO