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

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

• Nepoužívejte 1024 jako klíčovou délku ... NIST ji postupně ukončil v roce 2011, MSFT ji nikdy nepřidá do vašeho Trusted Root CA store , protože nebude splňovat minimální akceptovaná technická kritéria .

• Kořenové CA , které podporují starší aplikace by nikdy neměly být větší než 2048 bitů. Důvod: Podpora MSFT vidí mnoho případů, kdy Java aplikace nebo síťová zařízení podporují pouze klíčové velikosti 2048 bytů . Uložte vyšší bitové délky do CA, které jsou omezeny pro konkrétní účel (Windows vs síťová zařízení) atd.

• NIST doporučuje 2048 nebo 3072 bitů. ECC je podporováno, i když to může způsobit problémy s interoperabilitou zařízení.

• Naplánujte co nejsilnější šifrování (délka klíče) v PKI, jinak očekávejte smíšené bezpečnostní výhody .

• Mobilní klienti mají problémy (vysoký procesor) nebo nekompatibilitu s velkými klíči

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

• Možná budete chtít napodobit Federal PKI Management Authority a nastavit dva kořeny PKI. Jeden moderní SHA-256 pro všechna zařízení, která jej podporují, a jeden starší SHA-1. Poté použijte křížové certifikáty pro mapování mezi těmito dvěma nasazeními.

• Přečtěte si tento seznam kompatibilních SHA-2 pro software společnosti Microsoft

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

• Další informace naleznete v tomto seznamu poskytovatelů

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

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

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

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

• Klienti XP a mnoho systémů jiných než Windows nepodporují tento nový formát podpisu. Toto by mělo být deaktivováno, pokud je třeba podporovat starší klienty. Více informací

• Doporučil bych jej použít, až přejdete k ECC algoritmům pro asymetrické šifrování. ( zdroj )

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