MS Certificate Services può essere un subordinato alla CA creata con OpenSSL

Voglio configurare un'autorità di certificazione aziendale per il mio dominio. Quindi posso rilasciare certificati per vari scopi. Vorrei seguire le migliori pratiche di avere una CA offline come root e configurare la mia CA aziendale come subordinata. Ma sembra sciocco concedere in licenza una copia completa di Windows per questo compito.

Quello che spero di poter fare è installare una distribuzione live su un disco flash USB, quindi installare openssl e configurare la mia CA sull'unità flash. Quando sono pronto a creare la chiave / certificato root, disconnetterò il computer dalla rete e non userò mai più quel disco USB su un computer collegato in rete.

Sarò in grado di firmare e creare correttamente un certificato CA subordinato per una CA aziendale Windows, che sarà utilizzabile. Quali opzioni devo utilizzare con OpenSSL per creare la CA e firmare correttamente il certificato CA subordinato.

Ho provato a cercare sul web e questa è stata l'unica cosa che ho trovato sull'argomento. Ma è precedente al 2008 e non sono del tutto sicuro che la persona abbia avuto successo.

Sì, funziona benissimo; un'autorità di certificazione di Windows non ha scrupoli nell'esecuzione come subordinata a una radice non Windows.

Testato con una radice OpenSSL e un subordinato di Windows 2008 R2 in modalità Enterprise.

Un paio di cose da giocare bene con ciò che la CA MS si aspetta nella configurazione di OpenSSL:

• Le posizioni AIA e CDP valide devono essere applicate al certificato radice, nella sezione configurata dalla x509_extensionsproprietà della [req]sezione per la radice autofirmata . Qualcosa del genere:

  authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
  crlDistributionPoints = URI:http://test-rootca.test.local/root.crl
  

• Una determinata configurazione OpenSSL probabilmente non consente le CA subordinate per impostazione predefinita. Modificalo per le richieste firmate (assicurati che non sia presente per le richieste che non dovrebbero essere CA, ovviamente). Questo sarà nella sezione configurata dalla x509_extensionsproprietà della [ca]sezione:

  basicConstraints=CA:TRUE
  certificatePolicies=2.5.29.32.0
  

Quindi, faremo una CA per testare.

Crea la tua radice:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Gioca con la tua configurazione e crea i file e le directory necessari nella [ca]sezione della tua configurazione OpenSSL.

Tutto pronto per far funzionare la parte Microsoft; creare una CA subordinata di Windows con firma manuale.

Carica la richiesta di certificato sul server OpenSSL. Mentre ci sei, scarica il certificato di root. Importalo nell'archivio radice attendibile - del computer, non del tuo utente!

Rilascia il certificato subordinato:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

Se ciò non ha funzionato, probabilmente la tua CA ha un problema con la configurazione: nuova directory certs, file indice, file seriale, ecc. Controlla il messaggio di errore.

Se è andato, allora è tutto. In caso contrario, creare un elenco CRL e inserirlo nel CDP configurato in precedenza; Ho appena installato Apache e l'ho bloccato in webroot:

openssl ca -gencrl -out /var/www/root.crl

E metti il ​​certificato nella posizione AIA, se non lo è già:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Scarica il certificato subordinato appena rilasciato e installalo nella CA con lo snap-in MMC dell'autorità di certificazione. Riguarderà qualsiasi problema con fiducia o convalida, ma non ha obiezioni morali nel prenderlo.

Risultato finale; una CA di Windows funzionante senza lamentarsi dello snap-in Enterprise PKI, con una spia OpenSSL Generated Certificatenegli attributi.

Vedo cosa stai ottenendo, ma non credo che OpenSSL sia piuttosto lo strumento per il lavoro. Potresti voler esaminare i progetti dell'autorità di certificazione Open Source come EJBCA che sono più focalizzati su questa funzionalità rispetto a OpenSSL e hanno una documentazione specifica che puoi usare.

Non vedo un motivo per cui il concetto non avrebbe funzionato, poiché tutto ciò che stai facendo è firmare il certificato della CA subordinata. Se steste pagando una CA pubblica per farlo, non dovresti necessariamente sapere o preoccuparti del tipo di server che stavano usando.

Tutto quello che devi preoccuparti è:

• puoi firmare il certificato dal CSR generato dal tuo subordinato
• il risultato può essere installato sul subordinato stesso
• si dispone di un certificato di firma radice che può essere installato come attendibile su qualsiasi client di destinazione
• puoi generare un elenco di revoca che viene pubblicato da qualche parte

Non posso dire di averlo fatto, ma sono sicuro che se segui i documenti per generare un CSR da una finestra di Windows, quindi segui i tuoi documenti CA per generare un certificato .p7k da un CSR, allora dovresti andare bene.

A proposito, ti consiglio di creare la tua CA come macchina virtuale per un hypervisor popolare come Hyper-V o VMware, piuttosto che un disco di avvio, assicurati di archiviarlo in modo sicuro in un luogo in cui il successore possa trovarlo e ruotarlo periodicamente offline per assicurarsi che funzioni o trasferirlo su nuovi media / tecnologia. Una CA principale può avere una durata di 10 o 20 anni ...