Creazione della mia CA per una intranet

Se la tua infrastruttura è minuscola , è probabile che molti dettagli sull'esecuzione di una CA (ad esempio CRL e così via) possano essere ignorati. Invece tutto ciò che devi veramente preoccuparti è firmare i certificati.

C'è una moltitudine di strumenti là fuori che gestiranno questo processo per te. Ne ho persino scritto uno molti anni fa. Ma quello che consiglio se vuoi qualcosa di veramente semplice è easy-rsa dal progetto OpenVPN. È un involucro molto sottile attorno allo strumento da riga di comando OpenSSL. Se gestirai un sacco di certificati e ti occuperai effettivamente di revoca e roba del genere, ti servirà un'utilità molto più complessa e completa. Ci sono più che sufficienti suggerimenti già forniti, quindi invece mi limiterò a seguire le basi di ciò che stai cercando di realizzare.

Ma ecco la procedura di base. Lo spiegherò con OpenSSL, ma qualsiasi sistema lo farà.

Inizia creando la tua CA "root": sarà un certificato autofirmato. Ci sono diversi modi per farlo; questo è uno. Faremo del nostro un certificato di 10 anni con una chiave da 2048 bit. Modificare i numeri come appropriato. Hai detto che eri preoccupato per l'algoritmo di hashing, quindi ho aggiunto -sha256 per assicurarmi che sia firmato con qualcosa di accettabile. Sto crittografando la chiave usando AES-256, ma è opzionale. Ti verrà chiesto di compilare il nome del certificato e tale; questi dettagli non sono particolarmente importanti per una CA radice.

# 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

Se hai crittografato la chiave nel primo passaggio, dovrai fornire la password per usarla nel secondo. Controlla il tuo certificato generato per assicurarti che sotto "Vincoli di base" vedi "CA: TRUE". Questo è davvero l'unico punto importante di cui ti devi preoccupare:

openssl x509 -text < root.cer

Cool. OK, ora firmiamo un certificato. Avremo bisogno di un'altra chiave e questa volta di una richiesta. Ti verrà chiesto di nuovo il tuo nome e indirizzo. Quali campi vengono compilati e quali materiali vengono forniti da te e dalla tua applicazione, ma il campo più importante è il "Nome comune". È qui che fornisci il tuo nome host o nome di accesso o qualsiasi cosa questo attestato.

# 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

Si noti che questo crea un file chiamato root.srl per mantenere i nostri numeri seriali dritti. Il flag -CAcreateserial dice a openssl di creare questo file, quindi lo fornisci per la prima richiesta che firmi e poi mai più. E ancora una volta, puoi vedere dove aggiungere l'argomento -sha256 .

Questo approccio, facendo tutto manualmente, non è secondo me l'idea migliore. Se stai eseguendo un'operazione di dimensioni considerevoli, probabilmente vorrai uno strumento in grado di tenere traccia di tutti i tuoi certificati per te.

Invece, il mio punto qui era di mostrarti che l'output che vuoi - i certificati firmati nel modo in cui li vuoi - non dipende dagli strumenti che usi, ma piuttosto dalle opzioni che fornisci a quegli strumenti. La maggior parte degli strumenti può produrre un'ampia varietà di configurazioni, sia forti che deboli, e spetta a te fornire i numeri che ritieni appropriati. Le impostazioni predefinite obsolete sono par per il corso.

Non c'è modo di farlo semplicemente. ci sono alcuni strumenti che possono aiutarti a iniziare facilmente.

come:

• XCA
• EJBCA
• openssl

nessuno di questi è un PKI completo a parte forse EJBCA ma non è banale da configurare.

• XCA è un piccolo strumento di frontend per ottenere un'interfaccia grafica per generare, firmare e revocare i certificati.
• EJBCA o Enterprise Java Beans Certificate Authority è una JBOSS / Jetty Webapp che può eseguire l'infrastruttura PKI completa per un'azienda.
• openssl è lo strumento di base della riga di comando. può fare tutti i bit offline di una CA ma nessuno della verifica (out of the box). puoi creare i tuoi verificatori OCSP con esso, ma devi creare il codice "online" per te stesso.

Se tutto ciò che cerchi è una corretta configurazione di openssl. XCA può aiutarti a generarli. (ha una funzione di esportazione di configurazione di openssl

Se vuoi veramente essere un CA, presta attenzione alle implicazioni per la sicurezza di farlo.

1. La chiave privata utilizzata per generare la CA radice per la tua intranet dovrebbe essere letteralmente bloccata in una cassastrong. E l'accesso a detta cassastrong dovrebbe essere monitorato fisicamente.
2. L'uso di una CA radice autofirmata costringe gli utenti non solo a fidarsi del fatto che si sta eseguendo la dovuta diligenza con la protezione sicura delle chiavi, ma anche a inserire una radice di root inizialmente non sicura nella catena di certificati.
3. In questo modo si interrompe anche la funzionalità di pinzatura OSCP in merito alla verifica esterna della catena di certificati, motivo per cui i servizi di gestione delle identità esistono in primo luogo.

Alcuni sostengono il ragionamento alla base della gestione della propria CA come; è per una intranet aziendale in cui parte delle nostre build desktop include root ca o è per un numero limitato di utenti.

Anche se non è necessariamente sbagliato farlo e può offrire alcuni vantaggi, nega la catena di verifica per la quale è stata creata la gestione dell'identità basata sui certificati.

Se decidi di implementare il tuo root ca, assicurati di seguire le stesse pratiche di sicurezza di qualsiasi altro uso di root ca. Come azienda, l'ultima cosa che vorresti succedere è che qualcuno possa compromettere la chiave privata utilizzata per il tuo root ca e iniziare a firmare certificati per campagne di phishing contro i tuoi clienti.

Ci sono tonnellate di guide alle migliori pratiche disponibili per questo, il NIST (Istituto nazionale per gli standard e la tecnologia) è un gruppo collaborativo che assiste in vari standard per gli argomenti di sicurezza informatica.

Lettura consigliata:
Controllo (PDF)
Ripristino di emergenza (PDF)
Sistemi a chiave pubblica (PDF)
Istituto di sicurezza per le implementazioni PKI più piccole

Ok, vedo che hai aggiornato la tua domanda per essere più specifica.

Due documenti per configurare il tuo file openssl.cnf per le specifiche della CA:

link

link

Mi rendo conto che questa potrebbe non essere la risposta che desideri ma, poiché l'ambiente e i requisiti di ognuno sono diversi, dovrai definire un ambito per l'implementazione della CA per un buon esempio di configurazione.

Per un buon background, vedi la mia presentazione Come costruire e gestire il proprio centro di gestione certificati di mediocrità . L'essenza della presentazione è che la cosa più richiesta non è un elenco dei comandi da eseguire, ma piuttosto una profonda comprensione di tutti i vari controlli che avvengono nel gestire una CA commerciale, come interagiscono insieme, l'impatto esatto della rimozione ognuno di essi, l'impatto cumulativo della rimozione di alcuni di essi e dei controlli attenuanti necessari per compensare la riduzione della sicurezza.

Questo è il motivo per cui non esiste una "risposta canonica sull'impostazione di una CA semplice". O si percorre l'intero percorso ISO, a partire da una key signing party, airgapped e vaulted duplicts root root, più firmatari intermedi, server di revoca, ecc. Ecc., Oppure devono escogitare un compromesso basato sul costo / beneficio univoco e profilo di rischio che l'azienda è disposta ad accettare. Chiunque abbia sufficiente esperienza ed esperienza per fare quella valutazione per definizione non ha bisogno del trucco. Possono analizzare la sintassi del comando corretta in base a una profonda comprensione della funzione aziendale da eseguire e alle primitive di sicurezza utilizzate per implementare tale requisito.

Nella presentazione ci sono storie di impegni reali di negozi che hanno seguito questa strada e l'hanno terribilmente sbagliata. In alcuni casi la mia valutazione ha riportato che assolutamente nulla che posso fare con la vostra sicurezza middleware può eventualmente superare i difetti intrinseci della CA interna. Chiunque negli Stati Uniti dovrebbe rendersi conto che probabilmente acquista servizi da almeno uno dei venditori a cui la presentazione si riferisce. Queste sono banche, cooperative di credito, assicuratori sanitari, rivenditori e altro ancora.

Poiché le raccomandazioni per essere "corrette" richiede che il responsa- bile faccia delle ipotesi importanti sui tuoi profili di rischio accettabili e che tu prenda delle ipotesi importanti sul grado in cui le tue e le loro idee di rischio sono allineate e sincronizzate, il molto proposta è rischiosa sul suo volto. Nella maggior parte dei casi, la valutazione dell'idoneità dei tutorial forniti ha più a che fare con la presentazione che con l'effettivo livello di sicurezza derivante dal seguire le loro procedure. Se è ben organizzato e chiaramente articolato, questo è MOLTO più che efficace. Selezioniamo il cheat sheet canonico che sembra il migliore per noi.

Per questi motivi, non credo che un esperto credibile possa fornire "file corretti e aggiornati di openssl.cnf ", ma piuttosto potrebbe nel migliore dei casi fornire un processo di valutazione per valutare i requisiti e il rischio accettabile in modo più completo. Dal momento che stai scommettendo l'azienda sul risultato, nessun esperto credibile farebbe questo al di fuori della protezione di un contratto. Qualsiasi raccomandazione che si ottiene, quasi per definizione, deve provenire da un esperto credibile in . Buona fortuna.

Segui queste istruzioni per configurare una CA basata su Windows . Poiché stai emettendo certificati client, tieni presente che gli hash SHA2 non sono supportati su XP.

La risposta semplice è:

1. Installa AD
2. Installa una CA Enterprise sul controller di dominio
3. Modifica il modello di certificato per emettere certificati utente finale (imposta l'autorizzazione per gli utenti di autoiscriversi o vai a una pagina web)
4. Distribuisci la chiave pubblica del certificato principale su tutti i server che convalidano gli utenti
5. Se gli utenti sono su AD, utilizzare GPO per abilitare la registrazione automatica