Comment configurer correctement openssl CA pour générer des certificats clients SSL

Je configure ma première CA. Son objectif sera d'émettre des certificats pour nos clients, qui les utiliseront pour accéder à notre service EDI via https. J'ai donc besoin de générer des certificats clients SSL. L'ensemble du processus de signature des certificats fonctionne maintenant, et les certificats peuvent être utilisés avec succès pour accéder à notre service, mais je m'inquiète d'une chose:

Les objectifs du certificat généré sont très génériques:

$ 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

Je pense qu'il ne devrait pas y avoir d'autre but que le client SSL et la signature S / MIME dans mon cas. Ai-je tort et cela devrait rester tel quel?

Si j'ai raison et que je devrais désactiver d'autres fonctions, que dois-je mettre dans ma configuration openssl.cnf?

Voici ma configuration actuelle (dépouillée un peu):

[ 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

Que fais-je de mal à ce que les certificats générés permettent l'utilisation du serveur?

Vous avez raison de vous préoccuper de la «signature CRL», de «Any Purpose CA» et «OCSP Helper», ceux-ci sont généralement réservés aux certificats CA ou aux certificats spécifiquement émis pour la signature des listes de révocation de certificats (CRL, une liste de certificats qui sont non valide) ou exécutant un serveur OCSP (similaire aux listes de révocation de certificats, mais un service en ligne qui fournit le statut de validité des certificats).

La page de documentation OpenSSL appropriée concerne la commande x509 et x509v3_config

Voici la configuration OpenSSL que j'utilise pour générer des certificats clients:

[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

Je vais vous guider ligne par ligne:

Le basicConstraintsest défini comme critique, ce qui signifie «rejeter ce certificat si vous ne comprenez pas ce bit» et spécifie que le certificat n'est pas une autorité de certification . Même si quelqu'un utilise un logiciel pour émettre un certificat à partir de ce certificat, il ne sera jamais approuvé.

L'utilisation étendue des clés n'est pas essentielle, mais certains logiciels nécessitent sa présence et un objectif particulier répertorié. Cela répertorie l'authentification du client (ce dont vous parlez) ainsi que la signature et le cryptage des e-mails S / MIME; vous pouvez supprimer en toute sécurité l'objectif S / MIME si vous n'en avez pas besoin.

subjectAltNamevous permet d'inclure des informations sur le sujet que vous ne pouvez pas inclure dans le subjectchamp. Il est également utilisé dans les certificats de serveur Web pour inclure les noms de domaine pour lesquels le certificat peut être utilisé autre que le domaine spécifié dans l'attribut de nom commun du sujet; ces certificats sont appelés certificats SAN (autre nom du sujet). Il est courant d'inclure l'adresse e-mail dans subjectAltNameplutôt que dans le sujet; vous n'avez pas du tout besoin d'inclure une adresse e-mail et vous pouvez omettre l'extension.

crlDistributionPointsrépertorie les endroits où la liste de révocation de certificats pour l'autorité d'émission est disponible; il indique au logiciel qui essaie de valider le certificat "voici où aller pour voir si ce certificat est toujours valide." Pour une utilisation sur Internet, une http://URL est probablement la meilleure (les CRL sont signées numériquement, donc il n'y en a pas besoin https, et cela peut provoquer des problèmes de boucle de confiance).

authorityKeyIdentifierest généralement le hachage SHA-1 de la clé publique de l'autorité de certification émettrice (bien qu'il puisse s'agir d'autres valeurs). Si vous incluez cette extension, la valeur doit correspondre à la valeur de subjectKeyIdentifierdans le certificat de l'autorité de certification émettrice .

authorityInfoAccessest un peu similaire, crlDistributionPointsmais il spécifie où obtenir le certificat CA émetteur plutôt que la liste de révocation de certificats . Ceci est utile si vous avez une longue chaîne de confiance: par exemple, CA-1 émet CA-2, qui émet CA-3, qui émet le certificat; les logiciels qui tentent de vérifier le certificat peuvent utiliser cette extension pour obtenir le certificat CA-3, puis utiliser la valeur de ce certificat pour obtenir le certificat CA-2, etc. Habituellement, la chaîne de certificats (dans ce cas, le certificat CA-2 et certificat CA-3) est fourni avec le certificat du sujet (par exemple dans une transaction SSL ou un e-mail S / MIME). Je ne connais aucun logiciel qui utilise cette extension, mais je ne sais pas non plus ce n'est pas couramment utilisé. Il est généralement inclus dans les certificats.

De tout cela, vous n'avez vraiment besoin que de basicConstraintset extendedKeyUsage; les contraintes de base doivent vraiment, vraiment être critiques (ou vous venez de remettre des certificats CA!), et l'utilisation étendue des clés ne l'est généralement pas.