it-swarm-eu.dev

Kontrolní seznam při vytváření offline kořenové a střednědobé certifikační autority (CA)

Společnost Microsoft umožňuje certifikační autoritě používat kryptografii Next Generation (CNG) a pozorňuje na problémy s nekompatibilito pro klienty, kteří tuto sadu nepodporují.

Zde je obrázek výchozího nastavení kryptografie pro CA 2008 R2. Tento stroj je samostatný nezávislý CA:

Default Cryptography settings

Zde jsou nainstalovaní poskytovatelé. Poskytovatelé CNG jsou označeni znakem #

enter image description here

Mým záměrem je mít k dispozici obecný offline kořenový CA a poté několik zprostředkujících CA, které slouží ke specifickému účelu (pouze MSFT vs Unix vs SmartCards atd.)

Jaká jsou ideální nastavení pro kořenový certifikát s vypršením platnosti 5, 10 a 15 let?

  1. CSP
  2. Podpisový certifikát
  3. Délka klíčového znaku

Protože se jedná o RootCA, udělejte některý z parametrů vliv na CPU s nízkou spotřebou (mobilní zařízení)

25

Poznámka: Toto je (velmi velmi dlouhý) přehled různých doporučení a akcí, které uvedli odborníci společnosti Microsoft, NIST a další dobře respektovaní experti na PKI a kryptografii. Pokud vidíte něco, co vyžaduje i sebemenší revizi, dejte mi vědět.

Než začnu konfigurovat certifikační autoritu a její dílčí část, je dobré vědět, že i když CryptoAPI MSFT vyžaduje kořen s vlastním podpisem, nějaký software, který není MSFT, může následovat RFC 3280 a umožnit kterékoli certifikační autoritě být důvěryhodným kořenem pro účely ověření. Jedním z důvodů může být to, že software, který není MSFT, dává přednost nižší délce klíče.

Zde je několik poznámek o konfiguraci a pokynů pro nastavení CA ROOT a Subs:

Uložení soukromého klíče CA

  • Nejlepší: Uložte klíč na HSM, který podporuje počítání klíčů. Při každém použití soukromého klíče CA se počítadlo zvýší. Tím se zlepší váš profil auditu. Vyhledejte úroveň FIPS140 úrovně 3 nebo 4

  • Dobrý: Uložte soukromý klíč na čipovou kartu. Přestože nevím o žádné inteligentní kartě, která nabízí počítání klíčů, umožňuje počítání klíčů může vám v protokolu událostí poskytnout neočekávané výsledky

  • Přijatelné: Soukromý klíč uložte do Windows DPAPI. Zajistěte, aby tyto klíče a agent pro zápis klíčů neskončily v Roaming Credentials . Viz také: Jak vyjmenovat DPAPI a cestovní údaje

Délka klíče

Expirace

Algoritmus a délka klíče mohou mít vliv na to, jak dlouho chcete, aby byly certifikáty platné, protože efektivně určují, jak dlouho to může trvat crack útočníka, tj. Čím silnější kryptografie, tím déle budete připraveni mít certifikáty platné pro

Jedním přístupem je zjistit, jaká je nejdelší platnost, kterou budete požadovat pro certifikáty koncových entit, zdvojnásobit je pro vydávající ca a poté jej znovu zdvojnásobit pro root ca (ve dvou úrovních). S tímto přístupem byste pravidelně obnovovali každý certifikát ca, když byla dosažena polovina jeho životnosti - je to proto, že nemůže vydat certifikáty s datem ukončení po datu platnosti samotného certifikátu ca.

Vhodné hodnoty mohou skutečně určit pouze vaše organizace a zásady zabezpečení, ale kořenový adresář by obvykle měl životnost certifikátu 10 nebo 20 let.

Pokud máte obavy o kompatibilitu, nastavte datum vypršení platnosti pod 2038. Je to kvůli systémům, které od 1. ledna 1970 kódují data v sekundách přes podepsané 32bitové celé číslo. Přečtěte si více o tomto problému zde.

Výběr hash

Zejména:

  • Windows 2003 a Klienti XP mohou potřebovat opravu algoritmů SHA2 , které zahrnují SHA256, SHA384 a SHA512. Viz další technické informace

  • Ověřování a S/MIME s hashováním SHA2 není podporováno na XP nebo 2003

  • "Pokud jde o podporu SHA-224, nabízí SHA-224 menší zabezpečení než SHA-256, ale zabírá stejné množství prostředků. SHA-224 se protokoly a aplikace také obecně nepoužívají. Standardy NSA Suite B ji také nezahrnují." zdroj

  • "Nepoužívejte sadu SHA2 nikde v hierarchii CA, pokud máte v úmyslu mít XP buď důvěryhodný certifikát, ověření certifikátu, použití certifikátu při ověřování řetězce nebo obdržení certifikátu od CA. Přestože XP SP3 umožňuje ověření certifikátů, které používají SHA2 v hierarchii CA, a KB 968730 umožňuje omezený zápis certifikátů, které jsou podepsány CA pomocí SHA2, jakékoli použití diskrétních podpisových bloků out = XP úplně. "( zdroj )

Výběr kryptografického poskytovatele

Povolit generování náhodných sériových čísel

Od roku 2012 je to nutné, pokud používáte MD5 jako hash. Je to stále dobrý nápad, pokud je použit SHA1 nebo vyšší . Viz také tento Windows 2008R2 "jak" pro více informací.

Vytvořte prohlášení o praktikování certifikátů

Prohlášení o praxi certifikátů je prohlášení o postupech, které IT používá ke správě certifikátů, které vydává. Popisuje, jak je interpretována certifikační politika organizace v kontextu systémové architektury organizace a jejích operačních postupů. IT oddělení odpovídá za přípravu a udržování prohlášení o praxi certifikátů. ( zdroj )

POZNÁMKA: V některých situacích, například při používání digitálních podpisů ve závazných smlouvách, lze prohlášení o praktikách certifikace považovat také za právní prohlášení o úrovni poskytované bezpečnosti a zárukách, které se používají ke stanovení a udržování úrovně zabezpečení. .

Pro pomoc s napsáním prohlášení CPS zde je Microsoft „Job Aid“ vytvořený společností Microsoft

Doporučené postupy: Ačkoli je možné do tohoto pole vložit text volného tvaru (viz notice níže), ideálním řešením je použít adresu URL. To umožňuje aktualizaci zásady bez opětovného vydávání certifikátů, zabraňuje také zbytečnému nadýmání úložiště certifikátů.

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.Microsoft.com/policy/isspolicy.asp"

Zásady certifikace

Také známý jako zásady vydávání nebo zásady ověřování (v MSFT), jedná se o vlastní definici OID), která popisuje míru důvěry, kterou byste měli do certifikátu vložit (vysoká, střední, nízká atd.) . Viz odpověď StackExchange , jak správně používat toto pole.

Zajistěte, aby se zásady aplikace a zásady EKU shodovaly

Zásady aplikace je volitelná úmluva společnosti Microsoft. Pokud vydáváte certifikáty, které obsahují aplikační zásady i rozšíření EKU, ujistěte se, že obě rozšíření obsahují identické identifikátory objektu.

Povolit kontrolu CRL

Před vydáním certifikátu koncové entity obvykle certifikační autorita Windows Server 2003 vždy zkontroluje zrušení všech certifikátů v hierarchii PKI (kromě kořenového certifikátu CA). Chcete-li tuto funkci zakázat, použijte následující příkaz v CA a potom restartujte službu CA:

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

Distribuční bod CRL

Zvláštní pokyny pro kořenové CA

  • Toto je volitelné v kořenové CA, a pokud je provedeno nesprávně může vystavit váš soukromý klíč .

  • Veškerá publikace CRL se provádí ručně z offline RootCA do všech ostatních sub-CA. Alternativou je použijte audio kabel pro usnadnění jednosměrné komunikace z kořenových adres do sub-CA

  • Je naprosto přijatelné, aby kořenová CA vydávala různá umístění CRL pro každý vydaný certifikát k podřízeným CA.

  • Mít CRL v kořenovém adresáři je nejlepší postup, pokud si dva PKI navzájem důvěřují a je provedeno mapování politik. To umožňuje odvolání certifikátu.

Získání správného CRL je docela důležité, protože je na každé aplikaci, aby provedla kontrolu CRL. Například přihlašování pomocí inteligentních karet v řadičích domény vždy vynucuje kontrolu odvolání a odmítne přihlašovací událost, pokud nelze zrušit kontrolu.

Poznámka: Nelze-li ověřit žádný certifikát v řetězci nebo se zjistí, že je zrušen, převezme status celého certifikátu celý řetězec.

  • Kořenový CA s vlastním podpisem by neměl obsahovat žádné CDP. Většina aplikací systému Windows nepovoluje příznak CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT, a proto ignoruje CDP ( toto je výchozí režim ověření ). Pokud je příznak povolen a CDP je pro kořenový certifikát s vlastním podpisem prázdný, nevrací se žádná chyba.

  • Nepoužívejte HTTPS a LDAPS. Tyto adresy URL již nejsou podporovány jako odkazy na distribuční body. Důvodem je to, že adresy URL HTTPS a LDAPS používají certifikáty, které mohou nebo nemusí být zrušeny. Proces kontroly odvolání může mít za následek smyčky odvolání, pokud jsou použity adresy HTTPS nebo LDAPS. Chcete-li zjistit, zda je certifikát odvolán, je nutné získat seznam CRL. CRL však nelze načíst, dokud není stanoven stav odvolání certifikátů používaných HTTPS nebo LDAPS.

  • Zvažte použití HTTP namísto LDAP - Ačkoli AD DS umožňuje publikování CRL pro všechny řadiče domény v doménové struktuře, implementujte HTTP místo LDAP pro publikování informací o odvolání. Pouze HTTP umožňuje použití ETag a Cache-Control: Max-age záhlaví poskytující lepší podporu pro servery proxy a včasnější informace o odvolání. Kromě toho HTTP poskytuje lepší heterogenní podporu, protože HTTP je podporován většinou klientů Linux, UNIX a síťových zařízení.

  • Dalším důvodem, proč nepoužít LDAP, je, že okno pro zrušení musí být menší. Při použití služby AD LDAP k replikaci informací o certifikační autoritě nemohlo být okno odvolání kratší než čas pro všechny weby v AD k získání aktualizace CA. Tato replikace může často trvat až 8 hodin ... to je 8 hodin, než bude přístup uživatele karty smartcard zrušen. "Todo: nový doporučený čas obnovení CRL je: ?????"

  • Zajistěte, aby byly všechny adresy URL vysoce dostupné (aka nezahrnují LDAP pro externí hostitele). Windows zpomalí proces ověření až na 20 sekund a opakujte neúspěšné připojení opakovaně alespoň tak často, jako každých 30 minut. Mám podezření, že Předběžné načítání způsobí, že k tomu dojde, i když uživatel stránku aktivně nepoužívá.

  • Sledujte velikost CRL. Pokud je objekt CRL tak velký, že CryptoAPI není schopen objekt stáhnout v rámci přiděleného maximálního limitu časového limitu, je vrácena chyba „odvolání offline“ a stahování objektu je ukončeno.

Poznámka: Distribuce CRL přes HTTP s podporou ETAG může způsobit problémy s IE6 při používání Windows 2003/IIS6, kde je připojení TCP) neustále obnovováno.

  • (Volitelné) Povolit nejčerstvější CRL : Toto nekritické rozšíření obsahuje seznam emitentů a umístění, z nichž lze získat delta CRL. Pokud atribut „Nejčerstvější CRL“ není přítomen ani v CRL, ani v certifikátu, bude se se základním CRL zacházet jako s běžným CRL, nikoli jako s částí základního páru CRL/delta CRL.

Certifikační autorita společnosti Microsoft neuvedla rozšíření „Freshest CRL“ do vydaných certifikátů. K vydanému certifikátu je však možné přidat rozšíření „Freshest CRL“. Budete muset napsat kód, abyste jej mohli přidat do žádosti, napsat vlastní modul zásad nebo použít certutil –setextension na čekající žádost. Další informace o pokročilém zápisu certifikátů naleznete v dokumentaci „Pokročilé registrace a správa certifikátů“ na web společnosti Microsoft

Varování Pokud jsou v CA povoleny delta CRL, musí být pro zjištění stavu odvolání certifikátu zkontrolován jak základní CRL, tak i Delta CRL. Pokud jeden nebo dva z nich nejsou k dispozici, motor řetězu oznámí, že stav zrušení nelze určit, a aplikace může certifikát odmítnout.

CRL Dimenzování a údržba (rozdělení CRL)

CRL poroste 29 bajtů za každý zrušený certifikát. Odvolané certifikáty budou tedy z CRL odstraněny, jakmile certifikát dosáhne svého původního data vypršení platnosti.

Protože obnovení certifikátu CA způsobuje generování nového/prázdného seznamu CRL, vydávající certifikační autority mohou zvážit obnovení certifikačního úřadu novým klíčem každých 100–125 kB certifikátů, aby udržovaly přiměřenou velikost CRL. Toto číslo je založeno na předpokladu, že přibližně 10 procent vydaných certifikátů bude zrušeno před jejich přirozeným datem expirace. Pokud je skutečná nebo plánovaná míra odvolání pro vaši organizaci vyšší nebo nižší, upravte odpovídajícím způsobem strategii obnovení. Více informací

Rovněž zvažte častější rozdělení CRL, pokud vypršení platnosti je více než 1 nebo 2 roky, protože pravděpodobnost odvolání se zvyšuje.

Nevýhodou je prodloužení doby spuštění, protože každý certifikát je ověřen serverem.

Bezpečnostní opatření CRL

Pokud používáte CRL, nepodepisujte CRL pomocí MD5. Je také dobré přidat randomizaci do podpisového klíče CRL.

Přístup k informacím o autoritě

Toto pole umožňuje subsystému ověření certifikátů stáhnout další certifikáty podle potřeby, pokud nejsou rezidenty v místním počítači.

  • Kořenový CA s vlastním podpisem by neměl uvádět žádná umístění AIA ( viz důvod zde )

  • V rozšíření AIA je povoleno maximálně pět adres URL pro každý certifikát v řetězci certifikátů. Kromě toho je také podporováno maximálně 10 adres URL pro celý řetěz certifikátů. Toto omezení počtu adres URL bylo přidáno, aby se zmírnilo možné použití odkazů „Authority Info Access“ při odmítnutí servisních útoků.

  • Nepoužívejte HTTP [~ # ~] s [~ # ~] a LDAP [~ # ~] s [~ # ~] . Tyto adresy URL již nejsou podporovány jako odkazy na distribuční body. Důvodem je to, že adresy URL HTTPS a LDAPS používají certifikáty, které mohou nebo nemusí být zrušeny. Proces kontroly odvolání může mít za následek smyčky odvolání, pokud jsou použity adresy HTTPS nebo LDAPS. Chcete-li zjistit, zda je certifikát odvolán, je nutné získat seznam CRL. CRL však nelze načíst, dokud není stanoven stav odvolání certifikátů používaných HTTPS nebo LDAPS.

Povolit OCSP ověření

Odpověď OCSP je obvykle umístěna na adrese: http://<fqdn of the ocsp responder>/ocsp. Tato adresa URL musí být povolena v AIA. Viz tyto pokyny pro Windows.

Uvědomte si, že ve výchozím nastavení je úplná validace OCSP (i když by měla být pro EV EV podle specifikace) „zapnutá“. Kromě toho povolení kontroly OCSP přidává latenci k počátečnímu připojení

Bezpečnější systémy budou chtít povolit monitorování OCSP na straně klienta nebo server

Trvání mezipaměti OCSP

Všechny akce OCSP probíhají přes protokol HTTP, a proto podléhají typickým pravidlům HTTP proxy cache cache.

Konkrétně Max-age header definuje maximální dobu, po kterou bude proxy server nebo klient ukládat do mezipaměti odpověď CRL nebo OCSP před použitím podmíněného GET k určení, zda se objekt změnil. Pomocí těchto informací nakonfigurujte webový server tak, aby nastavil příslušné záhlaví. Vyhledejte jinde na této stránce konkrétní příkazy AD-IIS.

Definujte zásadu v vydaných certifikátech

Nadřazený CA definuje, zda povolit nebo zakázat zásady certifikátů CA z podřízených CA. Toto nastavení je možné definovat, když je třeba do dílčího CA zahrnout politiku emitenta nebo aplikace.

Příklady politik zahrnují EKU pro SmartCards, autentizaci nebo SSL/Server autentizaci.

  • Dejte si pozor na certifikáty bez Certificate Policies rozšíření, protože může komplikovat Strom zásad. Viz RFC 5280 pro více informací

  • Vězte, že mapování politik může nahradit jiné zásady na cestě

  • Existuje zvláštní zásada nazvaná anypolicy, která mění zpracování

  • Existují rozšíření, která mění anypolicy

  • Pokud používáte zásady certifikátů, nezapomeňte je označit jako critical jinak vypočtené valid_policy_tree se stane prázdným, z politiky se stane slavný komentář.

Sledujte vynucení délky DN

Původní specifikace CCITT pro pole OU říká, že by měla být omezena na 64 znaků. Obvykle CA vynucuje standardy délky názvu x.500 pro rozšíření předmětu certifikátů pro všechny požadavky. Je možné, že hluboké cesty OU mohou překročit omezení normální délky.

Distribuční body křížových certifikátů

Tato funkce pomáhá tam, kde prostředí musí mít nainstalované dva PKI, jeden pro starší hardware/software, který nepodporuje moderní kryptografii, a další PKI pro modernější účely.

Omezte EKU

Na rozdíl od dokumentu RFC 5280, který uvádí „obecně, [sic] se rozšíření EKU objeví pouze v certifikátech koncových entit.“ Je dobré dát omezení použití klíče CA .

Typický samostatný certifikát CA bude obsahovat oprávnění k vytváření digitálních podpisů, podpisů certifikátů a podepisování CRL jako klíčových hodnot. Toto je část problému s problémem zabezpečení FLAME.

Implementace čipové karty MSFT vyžaduje některou z následujících EKU a případně opravu hotfix

  • Inteligentní karta Microsoft EKU
  • Kryptografie s veřejným klíčem pro klienta s prvotní autentizací (PKINIT) Ověřování EKU, jak je definováno v PKINIT RFC 4556

Má také zajímavá omezení ohledně ověřování EKU (odkaz tbd).

Pokud vás zajímají nějaká omezení EKU, měli byste vidět tato odpověď týkající se OID a to týkající se omezených certifikátů

Buďte opatrní se základními omezeními „Cesta“

Základní omezení mělo by být popsáno, zda je certifikát „koncová entita“ . Přidání omezení cesty do zprostředkujícího CA nemusí fungovat podle očekávání, protože se jedná o neobvyklou konfiguraci a klienti ji nemusí dodržovat.

Kvalifikovaná podřízenost pro zprostředkující CA

  • Chcete-li omezit typy certifikátů, které může subCA nabídnout, viz tento odkaz a tento

  • Pokud je provedena kvalifikovaná podřízenost, může být odvolání kořene s křížovým podpisem obtížné, protože kořeny neaktualizují CRL často.

Identifikátor autorizačního klíče/identifikátor klíče subjektu

Poznámka: Pokud rozšíření AKI certifikátu obsahuje identifikátor KeyID, vyžaduje CryptoAPI, aby certifikát vydavatele obsahoval odpovídající SKI. To se liší od RFC 3280, kde SKI a AKI shoda je volitelné . (todo: Proč by se někdo rozhodl toto implementovat?)

AKI matching to find key parent

Pojmenujte Root a CA smysluplné jméno

Lidé budou s vaším certifikátem spolupracovat při importu, kontrole importovaných certifikátů a odstraňování problémů. Doporučená praxe MSFT a požadavek je, že kořen má smysluplné jméno, které identifikuje vaši organizaci, a ne něco abstraktního a běžného, ​​jako je CA1.

Tato další část se týká názvů zprostředkujících/subCA, které budou omezeny pro konkrétní účel: Ověřování vs. Podepisování vs. Šifrování

Je překvapivé, že koncoví uživatelé a technici, kteří nerozumí nuancím PKI, budou interagovat s názvy serverů, které vyberete častěji, než si myslíte, pokud používáte S/MIME nebo digitální podpisy (atd.).

Osobně si myslím, že je dobré přejmenovat vydávající certifikáty na uživatelsky přívětivější, například "Company Signer 1" kde mohu na první pohled říct

  • Od koho bude podpis pocházet (Texas A&M nebo jejich soupeř)
  • Na co se používá? Šifrování vs. podpisování

Je důležité rozlišit mezi zprávou, která byla šifrována mezi dvěma stranami, a zprávou, která byla podepsána. Jedním z příkladů, kde je to důležité, je, když mohu přimět příjemce, aby zopakoval prohlášení, které jim pošlu. Uživatel A mohl říct uživateli B „A, dlužím ti 100 $“. Pokud B odpověděl ozvěnou této zprávy nesprávným klíčem, efektivně digitálně notarizoval (vs pouze šifroval) fiktivní dluh 100 USD.

Zde je ukázka uživatelského dialogu pro S/MIME . Očekávejte podobná uživatelská rozhraní pro certifikáty založené na Brower. Všimněte si, jak jméno Emitenta není uživatelsky přívětivé.

Select a SMIME certificate.. really?

Alternativní kódování

Poznámka: Když už mluvíme o jménech, pokud jakýkoli odkaz v řetězci používá alternativní kódování, pak klienti nemusí být schopni ověřit vydavatelské pole subjektu. Systém Windows během porovnávání tyto řetězce normalizuje, proto se ujistěte, že názvy certifikačního úřadu jsou identické z binární perspektivy (na rozdíl od doporučení RFC).

Name matching to find key parent

Nasazení vysokého zabezpečení/sady B

  • Zde je informace týkající se algoritmů Suite B podporovaných ve Windows 2008 a R2

    ALGORITHM SECRET TOP SECRET

    Šifrování: Advanced Standard (AES) 128 bitů 256 bitů

    Digitální podpis: Algoritmus digitálního podpisu eliptické křivky (ECDSA) 256 bitová křivka. 384 bitová křivka

    Výměna klíčů: Eliptická křivka Diffie-Hellman (ECDH) 256 bitová křivka. 384 bitová křivka

    Hashing: Secure Hash Algorithm (SHA) SHA-256 SHA-384

  • Pro soulad sady B je ECDSA_P384#Microsoft Software Key Service Provider stejně jako 384 velikost klíče a SHA384 jako hashovací algoritmus lze také vybrat, pokud je požadovaná úroveň klasifikace přísně tajná. Měla by být použita nastavení odpovídající požadované úrovni klasifikace. ECDSA_P521 je také k dispozici jako možnost. Zatímco použití křivky ECC 521 bitů může překročit kryptografické požadavky sady B, v důsledku nestandardní velikosti klíče, 521 není součástí oficiální specifikace sady B.

PKCS # 1 v2.1

Ochrana portů Microsoft CA DCOM

Úředník Windows Server 2003 ve výchozím nastavení nevynucuje šifrování na rozhraních ICertRequest nebo ICertAdmin DCOM. Toto nastavení se obvykle nevyžaduje, s výjimkou zvláštních provozních scénářů, a nemělo by být povoleno. Šifrování DCOM na těchto rozhraních standardně podporují pouze počítače se systémem Windows Server 2003. Například Windows XP klienti ve výchozím nastavení nebudou vynucovat šifrování na žádost o certifikát do Windows Server 2003 CA. zdroj

úložiště soukromého klíče CNG vs. úložiště CSP

Pokud zaregistrujete šablonu certifikátu v3, soukromý klíč přejde do úložiště soukromých klíčů CNG v klientském počítači. Pokud zaregistrujete šablonu certifikátu v2 nebo v1, soukromý klíč přejde do úložiště CSP. Certifikáty budou viditelné pro všechny aplikace v obou případech, ale ne pro jejich soukromé klíče - takže většina aplikací zobrazí certifikát jako dostupný, ale nebude moci podepsat nebo dešifrovat data přidruženým soukromým klíčem, pokud nepodporují úložiště CNG.

Pomocí úložiště CNG a CSP nelze rozlišit pomocí certifikátu MMC. Pokud chcete vidět, jaké úložiště konkrétní certifikát používá, musíte použít CERTUTIL -repairstore my * (nebo CERTUTIL -user -repairstore my *) a podívejte se do pole Poskytovatel. Pokud se říká „... Poskytovatel úložiště klíčů“, pak je to CNG, zatímco všichni ostatní poskytovatelé jsou CSP.

Pokud vytvoříte počáteční žádost o certifikát ručně (Vytvořit vlastní požadavek v MMC), můžete si vybrat mezi „úložiště CNG“ a „Legacy Key“, kde odkaz znamená CSP. Toto je můj seznam zkušeností, který nepodporuje CNG - nemůžete najít autoritativní seznam nikde, takže to vyplývá z mých vyšetřování v průběhu času:

  • EFS Není podporováno ve Windows 2008/Vista, Podporováno ve Windows 7/2008R2
  • šifrovací certifikáty uživatele
  • Klient VPN/WiFi (EAPTLS, PEAP klient)

  • Windows 2008/7 Není podporováno ověřováním uživatelských nebo počítačových certifikátů

  • Certifikáty serveru TMG 2010 na webových posluchačích
  • E-mailové certifikáty uživatelů aplikace Outlook 2003 pro podpisy nebo šifrování
  • Kerberos Windows 2008/Vista- DC certifikáty
  • System Center Operations Manager 2007 R2
  • System Center Configuration Manager 2007 R2
  • SQL Server 2008 R2-
  • Forefront Identity Manager 2010 Správa certifikátů

Další informace o kompatibilitě s CNG jsou uvedeny zde (česky, i když Chrome dobře zpracovává automatický překlad)

Chytré karty a vydávající certifikační autority

Pokud plánujete poskytnout uživatelům druhou inteligentní kartu k ověření, použijte k tomu druhou certifikační autoritu vydavatele. Důvod: Požadavky Windows 7

Použijte příkaz Windows CERTUTIL -viewstore -enterprise NTAuth pro odstraňování problémů s přihlášením pomocí Smartcard. Místní úložiště NTAuth je výsledkem posledního stahování zásad skupiny z úložiště NTAuth služby Active Directory. Jedná se o obchod používaný při přihlášení pomocí čipové karty, takže zobrazení tohoto obchodu může být užitečné při řešení problémů se selháním přihlašování pomocí inteligentních karet.

Vyřazení stromu PKI z provozu

Pokud nasadíte dva stromy PKI, s cílem vyřadit z provozu starší strom v určitém okamžiku (kde jsou všechna stará zařízení zastaralá nebo upgradovaná), může být vhodné nastavit pole CRL Next Update na Null. Tím se zamezí (mělo by?) Neustálému dotazování nových CRLS na klienty. Důvodem je to, že jakmile bude PKI vyřazeno z provozu, nebude již žádná administrace a žádné zrušené certifikáty. Všechny zbývající cereálie prostě vyprší.

Více informací o vyřazování PKI z provozu najdete zde

39

AD CS Specifické příkazy

Toto je seznam příkazů důležitých pro konfiguraci serveru Windows 2008 R2 CA Server. Odstranil jsem je z jiného příspěvku, protože ten informativní čas byl příliš dlouhý, a ne všechny příkazy se přímo týkají nastavení CA.

Toto je spíše část Jak na to, spíše „co a proč“. Zahrnuje také rozdíly specifické pro jednotlivé verze CA (2000 vs 2003, vs 2008)


Uveďte, jaké příznaky úpravy zásad zápisu

Některé požadavky klienta mohou být automaticky odstraněny na základě těchto nastavení skrytého serveru.

C:\Users\ChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:\Windows\system32\CertLog
  DBLogDirectory           REG_SZ = C:\Windows\system32\CertLog
  DBTempDirectory          REG_SZ = C:\Windows\system32\CertLog
  DBSystemDirectory        REG_SZ = C:\Windows\system32\CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:\Users\ChrisLamont>certutil -getreg policy\editflags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

Řešením je spustit příkaz certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE což se zase aktualizuje

     Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

Jak definovat zásadu na základě podle CA

Chcete-li do vydaných certifikátů zahrnout zásadu, zadejte do příkazového řádku následující příkazy:

 certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

Nastavení můžete zakázat pomocí

  certutil -v -setreg policy\EnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

Jak definovat trvání vyrovnávací paměti OCSP

Následující příkazy umožňují nastavit, upravit a odstranit nastavení záhlaví Max-Age.

  appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']

Zobrazení aktuálních vlastních záhlaví httpProtocol

  appcmd list config /section:httpProtocol

Jak importovat offline CA certifikáty do AD

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

Jak povolit PKCS # 1 v1.21

To je povoleno, když má soubor CAPolicy.inf AlternateSignatureAlgorithm=1. Nezapomeňte na problémy s kompatibilitou.

Nakonec bychom měli vědět, že instalace služby AD Certificate Services není tak jednoduchá jako přidání role. Měli byste zkontrolovat tento instalační skript VBS a zajistit, aby soubor CAPolicy.inf měl být upraven podle potřeby pro vaše prostředí

Jak definovat bod distribuce křížových certifikátů

Certifikační služba Windows AD to umožňuje v souboru CAPolicy.info pomocí [CrossCertificateDistributionPointsExtension] záznam

Různé: rozdíly AIA při upgradu CA systému Windows 2000 na Windows 2003

Všimněte si, že došlo ke změně chování mezi certifikační autority Windows 2000 a 2003. Rozšíření AKI certifikátů vydaných certifikační autoritou Windows se liší mezi systémy Windows 2000 a Windows Server 2003. Ve výchozím nastavení jsou následující informace uloženy v rozšíření AIA vydaných certifikátů.

  • Windows 2000 Rozšíření certifikátů AIA vydaných certifikačním úřadem zahrnuje LDAP DN vydávajícího certifikačního úřadu (jméno emitenta), sériové číslo certifikátu vydávajícího CA a hash klíče veřejného klíče certifikátu CA.

  • Windows Server 2003 Rozšíření certifikátů AIA vydaných certifikační autoritou zahrnuje pouze hash veřejného klíče vydávající certifikační autority, známý také jako Key-ID.

Změna chování je způsobena chybami řetězení, ke kterým může dojít při obnovení certifikátu CA. Výchozí chování systému Windows 2000 může vést k neúplným řetězcům, pokud klientský certifikát CA použitý k podpisu vydaného certifikátu nebyl k dispozici. Při výchozím chování systému Windows Server 2003, pokud byla certifikační autorita obnovena se stejným párem klíčů, by do certifikačního řetězce mohl být zahrnut jakýkoli certifikát CA pro vydávající CA, který používá stejný pár klíčů.

Tímto příkazem můžete napodobit staré chování

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Výpis certifikátů v AD

Tento příkaz zobrazí seznam certifikátů publikovaných ve službě Active Directory.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

Kompatibilita s ISIS MTT v1.1 PKI

Viz tento postupy pro článek KB , také zde je alternativní metoda CAPolicy.inf pro ISIS MTT v1.1

4

jeden bod na kontrolním seznamu často chybí:

  • ZÁLOHY
  • ZÁLOHY
  • ZÁLOHY

esp. pokud implementujete CA.

Při předchozí odpovědi mi došel nedostatek místa, ale myslím, že se jedná o platné a užitečné informace:

Zrušení

Několik následujících oddílů pojednává o CRL a certifikátech, ale než se dostanete příliš daleko, chci vás upozornit na problém, který může ovlivnit produkci a provoz PKI: Pokud si myslíte, že váš PKI zruší dvakrát stejný certifikát s PKI (Active Directory Certificate) společnosti Microsoft Služby), bude datem odvolání datum druhého odvolání, nikoli první. Pokud však spravujete certifikáty na čipových kartách pomocí produktu FIM CM společnosti Microsoft (Forefront Identity Management - Správa certifikátů), provedete duplicitní odvolání. zdroj

1