Come configurare correttamente openssl CA per generare certificati client ssl

Sto configurando la mia prima CA. Lo scopo sarà quello di emettere certificati per i nostri clienti, che li useranno per accedere al nostro servizio EDI su https. Quindi ho bisogno di generare certificati client SSL. L'intero processo di firma dei certificati funziona ormai e i certificati possono essere utilizzati con successo per accedere al nostro servizio, ma sono preoccupato per una cosa:

Gli scopi del certificato generato sono generici:

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

Sento che non dovrebbero esserci altri scopi se non il client SSL e la firma S / MIME nel mio caso. Sbaglio e questo dovrebbe rimanere così?

Se ho ragione e dovrei disabilitare altri scopi, cosa devo inserire nella mia configurazione openssl.cnf?

Ecco la mia configurazione attuale (un po 'spogliata):

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

Cosa sto facendo di sbagliato che i certificati generati consentono l'utilizzo del server?

Hai ragione a essere preoccupato per "Firma CRL", "Qualsiasi scopo CA" e "Assistente OCSP", di solito sono riservati per certificati CA o certificati specificamente emessi per la firma di elenchi di revoche di certificati (CRL, un elenco di certificati che sono non valido) o che esegue un server OCSP (simile ai CRL, ma un servizio online che fornisce lo stato di validità per i certificati).

La relativa documentazione di OpenSSL è per il comando x509 e x509v3_config

Ecco la configurazione OpenSSL che utilizzo per generare certificati client:

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

Ti guiderò riga per riga:

Il basicConstraintsè impostato come critici, che significa "rifiutare questo certificato, se non si capisce questo bit", e specifica che il certificato è non è una CA . Anche se qualcuno utilizza un software per emettere un certificato da questo certificato, non sarà mai attendibile.

L'uso esteso della chiave non è essenziale, ma alcuni software richiedono che sia presente e che abbia uno scopo specifico elencato. Questo elenca l'autenticazione client (di cui stai parlando) e anche la firma e la crittografia S / MIME; puoi rimuovere in modo sicuro lo scopo S / MIME se non ti serve.

subjectAltNameti consente di includere informazioni sull'argomento che non puoi includere nel subjectcampo. Viene anche utilizzato nei certificati del server Web per includere nomi di dominio per i quali il certificato può essere utilizzato per un dominio diverso da quello specificato nell'attributo nome comune del soggetto; questi certificati vengono definiti certificati SAN (nome alternativo soggetto). È prassi comune includere l'indirizzo e-mail subjectAltNamenell'oggetto anziché nell'oggetto; non è necessario includere un indirizzo e-mail e si può omettere l'estensione.

crlDistributionPointselenca i luoghi in cui è disponibile l'LCR per l'autorità emittente; indica al software che sta tentando di convalidare il certificato "ecco dove andare per vedere se questo certificato è ancora valido". Per l'uso di Internet, un http://URL è probabilmente il migliore (i CRL sono firmati digitalmente, quindi non ce n'è bisogno httpse potrebbe causare problemi di trust loop).

authorityKeyIdentifierdi solito è l'hash SHA-1 della chiave pubblica della CA emittente (sebbene possano essere altri valori). Se si include questa estensione, il valore deve corrispondere al valore del subjectKeyIdentifiercertificato CA emittente .

authorityInfoAccessè un po 'simile crlDistributionPointsma specifica dove ottenere il certificato CA di emissione anziché il CRL. Ciò è utile se si dispone di una lunga catena di fiducia: ad esempio CA-1 emette CA-2, che emette CA-3, che emette il certificato; il software che tenta di verificare il certificato può utilizzare questa estensione per ottenere il certificato CA-3, quindi utilizzare il valore in quel certificato per ottenere il certificato CA-2, ecc. Di solito, la catena di certificati (in questo caso, il certificato CA-2 e certificato CA-3) è associato al certificato dell'oggetto (ad es. in una transazione SSL o e-mail S / MIME). Non conosco alcun software che utilizza questa estensione, ma non so nemmeno che non sia comunemente usato. È comunemente incluso nei certificati.

Di tutto ciò, hai solo bisogno del basicConstraintse extendedKeyUsage; i vincoli di base in realtà, devono essere davvero fondamentali (o hai appena distribuito certificati CA!), e in genere non lo è l'utilizzo esteso delle chiavi.