it-swarm.dev

Elenco di controllo per la creazione di un'autorità di certificazione principale (CA) e radice non in linea

Microsoft consente a un'autorità di certificazione di utilizzare Cryptography Next Generation (CNG) e segnala problemi di incompatibilità per i client che non supportano questa suite.

Ecco un'immagine delle impostazioni di crittografia predefinite per una CA 2008 R2. Questa macchina è una CA autonoma connessa non di dominio:

Default Cryptography settings

Ecco i provider installati. I fornitori di metano sono contrassegnati con un segno #

enter image description here

Il mio intento è di avere una CA-radice offline per uso generico e quindi diverse CA intermedie che servono a uno scopo specifico (solo MSFT vs Unix vs SmartCard ecc.)

Quali sono le impostazioni ideali per un certificato radice con una scadenza di 5, 10 e 15 anni?

  1. CSP
  2. Certificato di firma
  3. Lunghezza carattere chiave

Poiché si tratta di un RootCA, i parametri influenzano la CPU a basso consumo (dispositivi mobili)

25

Nota: questo è un compendio (molto lungo) di varie raccomandazioni e azioni che Microsoft, NIST e altri esperti di crittografia e PKI molto rispettati hanno affermato. Se vedi qualcosa che richiede anche la minima revisione, fammelo sapere.

Prima di iniziare a configurare la CA e i suoi sottotitoli, è bene sapere che anche se CryptoAPI di MSFT richiede una radice autofirmata, alcuni software non MSFT possono seguire RFC 3280 e consentire a qualsiasi CA di essere la radice attendibile ai fini della convalida. Un motivo potrebbe essere che il software non MSFT preferisce una lunghezza della chiave inferiore.

Ecco alcune note di configurazione e indicazioni sulla configurazione di un CA ROOT e dei Sottotitoli:

Memorizzazione della chiave privata della CA

  • Migliore: conservare la chiave su un HSM che supporti il ​​conteggio delle chiavi. Ogni volta che viene utilizzata la chiave privata della CA, il contatore verrà aumentato. Questo migliora il tuo profilo di audit. Cerca FIPS140 Livello 3 o 4

  • Buono: conservare la chiave privata su una smart card. Sebbene non sia a conoscenza di alcuna Smart Card che offra il conteggio delle chiavi, abilitando il conteggio delle chiavi potrebbe darti risultati imprevisti nel registro eventi

  • Accettabile: archivia la chiave privata in Windows DPAPI. Assicurarsi che queste chiavi e l'agente di registrazione delle chiavi non finiscano in Credenziali di roaming . Vedi anche: Come elencare DPAPI e credenziali di roaming

Lunghezza chiave

scadenza

L'algoritmo e la lunghezza della chiave possono influire sul tempo in cui si desidera che i certificati siano validi, poiché determinano in modo efficace quanto tempo potrebbe richiedere un crack dell'attaccante, vale a dire più forte è la crittografia, più tempo si potrebbe essere pronti ad avere certificati validi per

Un approccio consiste nello stabilire qual è la validità più lunga necessaria per i certificati delle entità finali, raddoppiarla per i certificati di emissione e quindi raddoppiarla nuovamente per i certificati di root (in due livelli). Con questo approccio rinnoveresti regolarmente ogni certificato ca quando viene raggiunta la metà della sua durata - questo perché un ca non può emettere certificati con una data di scadenza successiva a quella del certificato ca stesso.

Valori adeguati possono essere determinati solo dalla propria organizzazione e dalla politica di sicurezza, ma in genere un root ca avrebbe una durata del certificato di 10 o 20 anni.

Se sei preoccupato per la compatibilità, imposta la data di scadenza al di sotto del 2038. Ciò è dovuto ai sistemi che codificano un dato come secondi dal 1 ° gennaio 1970 su un numero intero a 32 bit con segno. Leggi di più su questo problema qui.

Scelta di un hash

In particolare:

  • Windows 2003 e i client XP potrebbero aver bisogno di una patch per gli algoritmi SHA2 che includono SHA256, SHA384 e SHA512. Vedi maggiori informazioni tecniche

  • Authenticode e S/MIME con hashing SHA2 non sono supportati su XP o 2003

  • "Per quanto riguarda il supporto SHA-224, SHA-224 offre meno sicurezza rispetto a SHA-256 ma richiede la stessa quantità di risorse. Inoltre SHA-224 non viene generalmente utilizzato da protocolli e applicazioni. Anche gli standard Suite B dell'NSA non lo includono." fonte

  • "Non utilizzare la suite SHA2 in nessun punto della gerarchia della CA se si prevede di avere XP fidarsi del certificato, convalidare il certificato, utilizzare il certificato nella convalida a catena o ricevere un certificato dalla CA. Anche se XP SP3 consente la convalida dei certificati che utilizzano SHA2 nella gerarchia della CA e KB 968730 consente la registrazione limitata di certificati firmati da una CA utilizzando SHA2, qualsiasi utilizzo di firme discrete blocca = XP interamente. "( fonte )

Scelta di un provider crittografico

Abilita generazione casuale di numeri di serie

A partire dal 2012, questo è necessario se si utilizza MD5 come hash. È ancora un buona idea se viene utilizzato SHA1 o superiore . Vedi anche questo Windows 2008R2 "come fare" per maggiori informazioni.

Crea una dichiarazione di pratica del certificato

Una dichiarazione di pratica del certificato è una dichiarazione delle pratiche che l'IT utilizza per gestire i certificati che emette. Descrive come la politica di certificazione dell'organizzazione viene interpretata nel contesto dell'architettura di sistema dell'organizzazione e delle sue procedure operative. Il dipartimento IT è responsabile della preparazione e della manutenzione della dichiarazione di pratica del certificato. ( fonte )

NOTA: in alcune situazioni, ad esempio quando si utilizzano firme digitali su contratti vincolanti, la dichiarazione di pratica del certificato può anche essere considerata una dichiarazione legale relativa al livello di sicurezza fornito e alle garanzie utilizzate per stabilire e mantenere il livello di sicurezza .

Per assistenza nella scrittura di una dichiarazione CPS, ecco un "Job Aid" prodotto da Microsoft

Best practice: sebbene sia possibile inserire testo a mano libera in questo campo (vedere notice di seguito), la soluzione ideale è utilizzare un URL. Ciò consente di aggiornare la politica senza riemettere i certificati e impedisce anche il gonfiore non necessario dell'archivio certificati.

[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"

Politiche del certificato

Conosciute anche come politiche di emissione o politiche di assicurazione (in MSFT), si tratta di un auto definito OID che descrive la quantità di fiducia che si dovrebbe mettere nel proprio certificato (alta, media, bassa, ecc.) Vedi questa risposta StackExchange per come usare correttamente questo campo.

Assicurati che le politiche applicative e le politiche EKU corrispondano

Politiche applicative è una convenzione Microsoft opzionale. Se si stanno emettendo certificati che includono sia la politica dell'applicazione che le estensioni EKU, assicurarsi che le due estensioni contengano identificatori di oggetti identici.

Abilita controllo CRL

Normalmente, una CA di Windows Server 2003 controlla sempre la revoca su tutti i certificati nella gerarchia PKI (tranne il certificato della CA principale) prima di emettere un certificato dell'entità finale. Per disabilitare questa funzione, utilizzare il comando seguente sulla CA, quindi riavviare il servizio CA:

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

Punto di distribuzione CRL

Guida speciale per le CA principali

  • Questo è facoltativo in una CA principale e, se fatto in modo errato, può esporre la tua chiave privata .

  • Tutta la pubblicazione CRL viene eseguita manualmente da un RootCA offline a tutte le altre CA secondarie. Un'alternativa è tilizzare un cavo audio per facilitare la comunicazione unidirezionale dalla radice alla CA secondaria

  • È perfettamente accettabile che la CA principale emetta posizioni CRL diverse per ciascun certificato emesso a CA subordinate.

  • Avere un CRL alla radice è una buona pratica se due PKI si fidano reciprocamente e viene eseguita la mappatura delle politiche. Ciò consente di revocare il certificato.

Ottenere il CRL "giusto" è piuttosto importante poiché spetta ad ogni applicazione fare il controllo CRL. Ad esempio, l'accesso con smart card sui controller di dominio impone sempre il controllo di revoca e rifiuta un evento di accesso se il controllo di revoca non può essere eseguito o ha esito negativo.

Nota Se un certificato nella catena non può essere convalidato o viene trovato come revocato, l'intera catena assume lo stato di quel certificato.

  • Una CA radice autofirmata non dovrebbe elencare alcun CDP. La maggior parte delle applicazioni Windows non abilita il flag CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT e quindi ignora il CDP ( questa è la modalità di validazione predefinita ). Se il flag è abilitato e il CDP è vuoto per il certificato root autofirmato, non viene restituito alcun errore.

  • Non utilizzare HTTPS e LDAPS. Questi URL non sono più supportati come riferimenti ai punti di distribuzione. Il motivo è che gli URL HTTPS e LDAPS utilizzano certificati che possono essere revocati o meno. Il processo di controllo della revoca può comportare cicli di revoca quando vengono utilizzati URL HTTPS o LDAPS. Per determinare se il certificato viene revocato, è necessario recuperare il CRL. Tuttavia, il CRL non può essere recuperato se non viene determinato lo stato di revoca dei certificati utilizzati da HTTPS o LDAPS.

  • Prendi in considerazione l'utilizzo di HTTP anziché LDAP: sebbene AD DS abilita la pubblicazione di elenchi CRL in tutti i controller di dominio nella foresta, implementa HTTP anziché LDAP per la pubblicazione delle informazioni di revoca. Solo HTTP abilita l'uso di ETag e Cache-Control: Max-age intestazioni che forniscono un migliore supporto per i proxy e informazioni di revoca più tempestive. Inoltre, HTTP fornisce un supporto eterogeneo migliore poiché HTTP è supportato dalla maggior parte dei client Linux, UNIX e dei dispositivi di rete.

  • Un altro motivo per non usare LDAP è perché la finestra di revoca deve essere più piccola. Quando si utilizza AD LDAP per replicare le informazioni della CA, la finestra di revoca non può essere inferiore al tempo per tutti i siti in AD per ottenere l'aggiornamento della CA. Spesso questa replica può richiedere fino a 8 ore ... ovvero 8 ore prima che venga revocato l'accesso dell'utente di una smart card. 'Todo: il nuovo tempo di aggiornamento CRL consigliato è: ????? `

  • Rendi tutti gli URL altamente disponibili (ovvero non includere LDAP per host esterni). Windows rallenterà il processo di convalida per un massimo di 20 secondi e riprovare la connessione non riuscita ripetutamente almeno ogni 30 minuti. Ho il sospetto che Pre-fetching provocherà ciò anche se l'utente non sta attivamente utilizzando il sito.

  • Monitora le dimensioni del tuo CRL. Se l'oggetto CRL è così grande che CryptoAPI non è in grado di scaricare l'oggetto entro la soglia massima di timeout assegnata, viene restituito un errore di "revoca offline" e il download dell'oggetto viene terminato.

Nota: la distribuzione CRL su HTTP con supporto ETAG può causare problemi con IE6 quando si utilizza Windows 2003/IIS6, dove la connessione TCP viene continuamente reimpostata.

  • (Facoltativo) Abilita CRL più recente : questa estensione non critica elenca gli emittenti e le posizioni da cui recuperare i CRL delta. Se l'attributo "Freshest CRL" non è presente né nel CRL né nel certificato, il CRL di base verrà trattato come un CRL normale, non come parte di una coppia CRL/delta CRL di base.

La CA Microsoft non inserisce l'estensione "Freshest CRL" nei certificati emessi. Tuttavia, è possibile aggiungere l'estensione "Freshest CRL" a un certificato emesso. Dovresti scrivere il codice per aggiungerlo alla richiesta, scrivere un modulo di criteri personalizzato o utilizzare certutil –setextension su una richiesta in sospeso. Per ulteriori informazioni sulla registrazione avanzata dei certificati, consultare la documentazione "Registrazione e gestione avanzata dei certificati" sul sito Web Microsoft

Avviso Se i CRL delta sono abilitati presso un'autorità di certificazione, sia il CRL di base che il CRL delta devono essere ispezionati per determinare lo stato di revoca del certificato. Se uno dei due, o entrambi, non sono disponibili, il motore di concatenamento segnalerà che lo stato di revoca non può essere determinato e un'applicazione può rifiutare il certificato.

Dimensionamento e manutenzione CRL (partizionamento CRL)

Il CRL aumenterà di 29 byte per ogni certificato revocato. Di conseguenza, i certificati revocati verranno rimossi dal CRL quando il certificato raggiunge la data di scadenza originale.

Poiché il rinnovo di un certificato CA provoca la generazione di un CRL nuovo/vuoto, le CA emittenti possono prendere in considerazione il rinnovo della CA con una nuova chiave ogni 100-125 K certificati per mantenere una dimensione CRL ragionevole. Questo numero di emissione si basa sul presupposto che circa il 10 percento dei certificati emessi verrà revocato prima della data di scadenza naturale. Se la percentuale di revoca effettiva o pianificata è superiore o inferiore per la propria organizzazione, modificare di conseguenza la strategia di rinnovo chiave. lteriori informazioni

Considerare anche il partizionamento dell'LCR più frequentemente se la scadenza è superiore a 1 o due anni, poiché aumenta la probabilità di revoca.

Lo svantaggio di questo è un aumento dei tempi di avvio, poiché ogni certificato è convalidato dal server.

Precauzioni di sicurezza CRL

Se si utilizza un CRL, non firmare il CRL con MD5. È anche una buona idea aggiungere randomizzazione alla chiave di firma CRL.

Accesso alle informazioni dell'autorità

Questo campo consente al sottosistema di convalida dei certificati di scaricare certificati aggiuntivi, se necessario, se non sono residenti sul computer locale.

  • Una CA radice autofirmata non deve elencare alcuna posizione AIA ( vedi motivo qui )

  • Nell'estensione AIA sono consentiti al massimo cinque URL per ogni certificato nella catena di certificati. Inoltre, è supportato un massimo di 10 URL per l'intera catena di certificati. Questa limitazione sul numero di URL è stata aggiunta per mitigare il potenziale utilizzo dei riferimenti di "Accesso alle informazioni dell'autorità" negli attacchi denial of service.

  • Non utilizzare HTTP [~ # ~] s [~ # ~] e LDAP [~ # ~] s [~ ~ #] . Questi URL non sono più supportati come riferimenti ai punti di distribuzione. Il motivo è che gli URL HTTPS e LDAPS utilizzano certificati che possono essere revocati o meno. Il processo di controllo della revoca può comportare cicli di revoca quando vengono utilizzati URL HTTPS o LDAPS. Per determinare se il certificato viene revocato, è necessario recuperare il CRL. Tuttavia, il CRL non può essere recuperato se non viene determinato lo stato di revoca dei certificati utilizzati da HTTPS o LDAPS.

Abilita convalida OCSP

Il risponditore OCSP si trova in modo convenzionale in: http://<fqdn of the ocsp responder>/ocsp. Questo URL deve essere abilitato nell'AIA. Vedi queste istruzioni per Windows.

Sappi che la convalida OCSP completa è disattivata per impostazione predefinita (anche se dovrebbe essere "attiva" per certificati EV in base alle specifiche). Inoltre, abilitando il controllo OCSP aggiunge latenza alla connessione iniziale

I sistemi più sicuri vorranno abilitare il monitoraggio OCSP sul client o sul lato server

Durata cache OCSP

Tutte le azioni OCSP si verificano tramite il protocollo HTTP e pertanto sono soggette alle regole tipiche della cache del proxy HTTP.

In particolare il Max-age header definisce il tempo massimo che un server proxy o client memorizzerà nella cache una risposta CRL o OCSP prima di utilizzare un GET condizionale per determinare se l'oggetto è stato modificato. Utilizzare queste informazioni per configurare il server Web per impostare le intestazioni appropriate. Cerca altrove in questa pagina i comandi specifici di AD-IIS per questo.

Definire una politica nei certificati emessi

La CA principale definisce se consentire o meno i criteri di certificazione CA dalle CA secondarie. È possibile definire questa impostazione quando un emittente o un criterio applicativo devono essere inclusi in una CA secondaria.

Le politiche di esempio includono un EKU per SmartCard, autenticazione o autenticazione SSL/Server.

  • Attenzione ai certificati senza il Certificate Policies estensione in quanto può complicare l'albero delle politiche. Vedere RFC 5280 per ulteriori informazioni

  • Sappi che i mapping delle politiche possono sostituire altre politiche nel percorso

  • Esiste una politica speciale chiamata anypolicy che modifica l'elaborazione

  • Esistono estensioni che modificano anypolicy

  • Se usi i criteri di certificazione, assicurati di contrassegnarli come critical altrimenti calcolati valid_policy_tree diventa vuoto, trasformando la politica in un commento glorificato.

Monitora l'applicazione della lunghezza DN

Le specifiche CCITT originali per il campo OU indicano che dovrebbe essere limitato a 64 caratteri. Normalmente, la CA applica standard di lunghezza del nome x.500 sull'estensione soggetto dei certificati per tutte le richieste. È possibile che percorsi di unità organizzative profonde possano superare le normali restrizioni di lunghezza.

Punti di distribuzione certificati incrociati

Questa funzione aiuta dove gli ambienti devono avere due PKI installati, uno per hardware/software legacy che non supporta la crittografia moderna e un altro PKI per scopi più moderni.

Limita l'EKU

A differenza di RFC 5280 che afferma "in generale, [sic] l'estensione EKU verrà visualizzata solo nei certificati di entità finale." È una buona idea mettere vincoli sull'uso della chiave CA .

Un tipico certificato CA autonomo conterrà le autorizzazioni per la creazione di firme digitali, firma certificato e firma CRL come valori chiave. Questo è parte del problema con il problema di sicurezza di FLAME.

L'implementazione della smart card MSFT richiede una delle seguenti EKU e possibilmente un hotfix

  • Smart card Microsoft EKU
  • Crittografia a chiave pubblica per l'EKU di autenticazione client PKINIT (Initial Authentication), come definito in PKINIT RFC 4556

Presenta inoltre interessanti vincoli alla convalida dell'EKU (link tbd).

Se sei interessato ad avere restrizioni EKU, dovresti vedere questa risposta per quanto riguarda gli OID e questo per quanto riguarda i certificati in violazione

Prestare attenzione con i Vincoli di base "Percorso"

Il vincolo di base dovrebbe descrivere se il certificato è "un'entità finale" o meno . Aggiunta di un vincolo di percorso a una CA intermedia potrebbe non funzionare come previsto poiché si tratta di una configurazione non comune e i client potrebbero non rispettarla

Sottoordinazione qualificata per CA intermedie

  • Per limitare i tipi di certificati che un subCA può offrire vedi questo link e questo

  • Se viene eseguita una subordinazione qualificata, la revoca di una radice con segno incrociato può essere difficile poiché le radici non aggiornano frequentemente i CRL.

Identificatore chiave autorità/Identificatore chiave soggetto

Nota Se l'estensione AKI di un certificato contiene un KeyID, CryptoAPI richiede che il certificato dell'emittente contenga uno SKI corrispondente. Ciò differisce da RFC 3280 dove la corrispondenza SKI e AKI è opzionale . (todo: Perché qualcuno dovrebbe scegliere di implementarlo?)

AKI matching to find key parent

Assegna un nome significativo a Root e CA

Le persone interagiranno con il certificato durante l'importazione, la revisione dei certificati importati e la risoluzione dei problemi. La pratica raccomandata da MSFT e requisito è che la radice abbia un nome significativo che identifica la tua organizzazione e non qualcosa di astratto e comune come CA1.

Questa parte successiva si applica ai nomi di Intermedia/subCA che saranno vincolati per uno scopo particolare: Autenticazione vs Firma vs Crittografia

Sorprendentemente, gli utenti finali e i tecnici che non comprendono le sfumature di PKI interagiranno con i nomi dei server che scegli più spesso di quanto pensi se usi S/MIME o firme digitali (ecc.).

Personalmente penso che sia una buona idea rinominare i certificati di rilascio in qualcosa di più user friendly come "Company Signer 1" dove posso dire a colpo d'occhio

  • Da chi verrà la firma (Texas A&M o il loro rivale)
  • A cosa serve? Crittografia vs firma

È importante dire la differenza tra un messaggio che è stato crittografato tra due parti e uno che è stato firmato. Un esempio in cui questo è importante è se riesco a fare in modo che il destinatario faccia eco a una dichiarazione che gli invio. L'utente A potrebbe dire all'utente B "A, ti devo $ 100". Se B ha risposto con un'eco di quel messaggio con la chiave sbagliata, ha effettivamente autenticato digitalmente (rispetto alla semplice crittografia) un debito fittizio di $ 100.

Ecco una finestra di dialogo utente di esempio per S/MIME . Aspettatevi interfacce utente simili per i certificati basati su Brower. Si noti come il nome dell'Emittente non sia facile da usare.

Select a SMIME certificate.. really?

Codifiche alternative

Nota: parlando di nomi, se qualsiasi collegamento nella catena utilizza una codifica alternativa, i clienti potrebbero non essere in grado di verificare il campo dell'emittente sull'oggetto. Windows non normalizza queste stringhe durante un confronto, quindi assicurati che i nomi della CA siano identici da una prospettiva binaria (al contrario della raccomandazione RFC).

Name matching to find key parent

Distribuzioni ad alta sicurezza/Suite B

  • Ecco informazioni relative agli algoritmi Suite B supportati in Windows 2008 e R2

    ALGORITMO SEGRETO TOP SECRET

    Crittografia: Advanced Standard (AES) 128 bit 256 bit

    Firma digitale: Curva ellittica Digital Signature Algorithm (ECDSA) Curva a 256 bit. Curva a 384 bit

    Scambio chiave: curva ellittica Diffie-Hellman (ECDH) curva a 256 bit. Curva a 384 bit

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

  • Per la conformità Suite B, il ECDSA_P384#Microsoft Software Key Service Provider così come il 384 dimensione chiave e SHA384 poiché l'algoritmo hash può anche essere selezionato se il livello di classificazione desiderato è Top Secret. Devono essere utilizzate le impostazioni che corrispondono al livello richiesto di classificazione. ECDSA_P521 è disponibile anche come opzione. Mentre l'uso di una curva ECC a 521 bit può superare i requisiti crittografici della Suite B, a causa delle dimensioni della chiave non standard, 521 non fa parte delle specifiche ufficiali della Suite B.

PKCS # 1 v2.1

Proteggi le porte DCOM Microsoft CA

La CA di Windows Server 2003 non impone la crittografia sulle interfacce DCOM ICertRequest o ICertAdmin per impostazione predefinita. Normalmente, questa impostazione non è richiesta se non in scenari operativi speciali e non dovrebbe essere abilitata. Solo le macchine Windows Server 2003 supportano per impostazione predefinita la crittografia DCOM su queste interfacce. Ad esempio, Windows XP per impostazione predefinita non impongono la crittografia sulla richiesta di certificato a una CA di Windows Server 2003. origine

Archiviazione chiave privata CNG vs archiviazione CSP

Se si registra il modello di certificato v3, la chiave privata viene archiviata nella memoria della chiave privata CNG sul computer client. Se si registra il modello di certificato v2 o v1, la chiave privata passa all'archivio CSP. I certificati saranno visibili a tutte le applicazioni in entrambi i casi, ma non alle loro chiavi private, quindi la maggior parte delle applicazioni mostrerà il certificato come disponibile, ma non sarà in grado di firmare o decrittografare i dati con la chiave privata associata a meno che non supportino l'archiviazione CNG.

Non è possibile distinguere tra archivi CNG e CSP utilizzando il MMC certificato. Se vuoi vedere quale archivio utilizza un determinato certificato, devi utilizzare CERTUTIL -repairstore my * (o CERTUTIL -user -repairstore my *) e dai un'occhiata al campo Provider. Se sta dicendo "... Key Storage Provider", allora è CNG mentre tutti gli altri provider sono CSP.

Se si crea manualmente la richiesta di certificato iniziale (Crea richiesta personalizzata in MMC), è possibile selezionare tra "Memoria CNG" e "Chiave legacy" dove legacy significa CSP. Quello che segue è il mio elenco basato sull'esperienza di ciò che non supporta il metano: non è possibile trovare un elenco autorevole da nessuna parte, quindi questo si allontana dalle mie indagini nel tempo:

  • EFS Non supportato in Windows 2008/Vista, Supportato in Windows 7/2008R2
  • certificati di crittografia utente
  • Client VPN/WiFi (EAPTLS, client PEAP)

  • Windows 2008/7 Non supportato con l'autenticazione con certificato utente o computer

  • Certificati server TMG 2010 su listener Web
  • Certificati di posta elettronica utente Outlook 2003 per firme o crittografia
  • Kerberos Windows 2008/Vista- DC
  • System Center Operations Manager 2007 R2
  • System Center Configuration Manager 2007 R2
  • SQL Server 2008 R2-
  • Gestione certificati Forefront Identity Manager 2010

lteriori informazioni sulla compatibilità del metano sono elencate qui (in ceco, tuttavia Chrome gestisce bene la traduzione automatica)

Smart card e CA di emissione

Se si prevede di fornire agli utenti una seconda smart card per l'autenticazione, utilizzare una seconda autorità di certificazione emittente. Motivo: requisiti di Windows 7

Utilizza il comando di Windows CERTUTIL -viewstore -enterprise NTAuth per la risoluzione dei problemi relativi agli accessi con smartcard. L'archivio NTAuth locale è il risultato dell'ultimo download di Criteri di gruppo dall'archivio NTAuth di Active Directory. È l'archivio utilizzato dall'accesso con smart card, quindi la visualizzazione di questo archivio può essere utile quando si risolvono errori di accesso con smart card.

Messa fuori servizio di un albero PKI

Se si distribuiscono due alberi PKI, con l'intento di smantellare l'albero legacy ad un certo punto (dove tutti i vecchi dispositivi sono diventati obsoleti o aggiornati), potrebbe essere una buona idea impostare il campo CRL Next Update su Null. Questo (dovrebbe?) Impedire il continuo polling per i nuovi CRLS ai clienti. Il ragionamento è che una volta che la PKI è stata ritirata, non ci sarà più amministrazione e non saranno più revocati i certificati. Tutte le rimanenti certificati vengono semplicemente lasciate scadere.

lteriori informazioni sulla disattivazione di PKI disponibili qui

39

Comandi specifici di Servizi di dominio Active Directory

Questo è un elenco di comandi rilevanti per la configurazione di un server CA Windows 2008 R2. Li ho rimossi dall'altro post poiché quell'informazione stava diventando troppo lunga e non tutti i comandi si riferiscono direttamente alla configurazione di una CA.

Questo è più della sezione Come, piuttosto il "cosa e perché". Include anche differenze specifiche della versione tra le versioni CA (2000 vs 2003, vs 2008)


Elenca quali flag di iscrizione alla politica di iscrizione

Alcune richieste dal client potrebbero essere rimosse automaticamente in base a queste impostazioni del server nascosto.

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.

La soluzione è eseguire il comando certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE che a sua volta si aggiorna

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

Come definire un criterio in base alla CA

Per includere una politica nei certificati emessi, immettere i seguenti comandi al prompt dei comandi:

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

È possibile disabilitare l'impostazione con

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

Come definire la durata della cache OCSP

I seguenti comandi consentono di impostare, modificare ed eliminare l'impostazione dell'intestazione Max-Age.

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

Per visualizzare le intestazioni personalizzate correnti di HTTPProtocol

  appcmd list config /section:httpProtocol

Come importare certificati CA offline in 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

Come abilitare PKCS # 1 v1.21

Questo è abilitato quando il file CAPolicy.inf ha AlternateSignatureAlgorithm=1. Assicurati di essere consapevole dei problemi di compatibilità.

Infine, si dovrebbe sapere che l'installazione di Servizi certificati AD non è semplice come aggiungere il ruolo. Dovresti controllare questo VBS Installation script e assicurarti che il file CAPolicy.inf debba essere modificato secondo necessità per il tuo ambiente

Come definire un punto di distribuzione tra certificati

Servizi certificati Windows AD abilitare ciò nel file CAPolicy.info con il [CrossCertificateDistributionPointsExtension] voce

Varie: differenze AIA durante l'aggiornamento da CA 2000 Windows a Windows 2003

Si noti che c'è un cambiamento nel comportamento tra le CA di Windows 2000 e 2003. L'estensione AKI dei certificati emessi dalle CA di Windows differisce tra Windows 2000 e Windows Server 2003. Per impostazione predefinita, le seguenti informazioni sono archiviate nell'estensione AIA dei certificati emessi.

  • Windows 2000 L'estensione AIA dei certificati emessi dalla CA include il DN LDAP della CA emittente (nome dell'emittente), il numero seriale del certificato della CA emittente e l'hash della chiave della chiave pubblica del certificato CA.

  • Windows Server 2003 L'estensione AIA dei certificati emessi dalla CA include solo un hash della chiave pubblica della CA di emissione, noto anche come ID chiave.

Il cambiamento nel comportamento è dovuto a errori concatenati che potrebbero verificarsi quando il certificato di una CA veniva rinnovato. Il comportamento predefinito di Windows 2000 potrebbe provocare catene incomplete se il certificato CA utilizzato per firmare il certificato emesso non fosse disponibile per il client. Con il comportamento predefinito di Windows Server 2003, se la CA è stata rinnovata con la stessa coppia di chiavi, è possibile includere nella catena di certificati qualsiasi certificato CA per la CA di emissione che utilizza la stessa coppia di chiavi.

Puoi imitare il vecchio comportamento eseguendo questo comando

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

Elenco dei certificati in AD

Questo comando elencherà i certificati pubblicati in Active Directory.

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

Compatibilità ISK MTT v1.1 PKI

Vedi questo articolo KB per le procedure , anche qui c'è un metodo alternativo CAPolicy.inf per ISIS MTT v1.1

4

un punto della lista di controllo spesso viene perso:

  • [~ ~] # backup [~ ~ #]
  • [~ ~] # backup [~ ~ #]
  • [~ ~] # backup [~ ~ #]

esp. se si implementa una CA.

Ho esaurito lo spazio sulla mia risposta precedente, ma penso che si tratti di informazioni valide e utili:

Revoca

Le prossime sezioni discutono di CRL e certificati, ma prima di andare troppo lontano voglio attirare la vostra attenzione su un problema che potrebbe influenzare la produzione e le operazioni PKI: se pensate che il vostro PKI revocherà il doppio dello stesso certificato con il PKI di Microsoft (certificato Active Directory) Servizi), quindi la data di revoca sarà la data della seconda revoca, non la prima. Ma se gestisci certificati su smart card con il prodotto FIM CM di Microsoft (Forefront Identity Management - Certificate Management), eseguirai tali revoche duplicate. fonte

1