Au cours de ma recherche, j'ai trouvé plusieurs façons de signer une demande de signature de certificat SSL:
Utilisation du
x509module:openssl x509 -req -days 360 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crtUtilisation du
camodule:openssl ca -cert ca.crt -keyfile ca.key -in server.csr -out server.crt
Remarque: je ne suis pas sûr de l'utilisation des bons paramètres pour celui-ci. Veuillez conseiller une utilisation correcte si je dois l'utiliser.
De quelle manière doit-on utiliser pour signer les demandes de certificat avec votre autorité de certification? Une méthode est-elle meilleure que l'autre (par exemple, une étant obsolète)?
cac'est pour les cas où vous êtes plus sérieux au sujet de devenir CA.Réponses:
Il vous manque le prélude à ces commandes.
Il s'agit d'un processus en deux étapes. Vous configurez d'abord votre autorité de certification, puis vous signez un certificat d'entité finale (aka serveur ou utilisateur). Les deux commandes élident les deux étapes en une seule. Et les deux supposent que vous disposez d'un fichier de configuration OpenSSL déjà configuré pour les certificats d'autorité de certification et de serveur (entité finale).
Créez d'abord un fichier de configuration de base :
Ajoutez-y ensuite:
Les champs ci-dessus sont tirés d'un plus complexe
openssl.cnf(vous pouvez le trouver dans/usr/lib/openssl.cnf), mais je pense qu'ils sont les éléments essentiels pour créer le certificat CA et la clé privée.Ajustez les champs ci-dessus à votre goût. Les valeurs par défaut vous font gagner du temps lors de la saisie des mêmes informations lors de l'expérimentation du fichier de configuration et des options de commande.
J'ai omis les éléments pertinents pour la liste de révocation de certificats, mais vos opérations d'autorité de certification devraient les avoir. Voir
openssl.cnfet lacrl_extsection associée .Ensuite, exécutez ce qui suit. Le
-nodesomet le mot de passe ou la phrase secrète pour que vous puissiez examiner le certificat. C'est une très mauvaise idée d'omettre le mot de passe ou la phrase secrète.Après l'exécution de la commande,
cacert.pemsera votre certificat pour les opérations de l'autorité de certification etcakey.pemsera la clé privée. Rappelez-vous que la clé privée n'a pas de mot de passe ou de phrase secrète.Vous pouvez vider le certificat avec les éléments suivants.
Et testez son objectif avec les éléments suivants (ne vous inquiétez pas pour le
Any Purpose: Yes; voir "Critique, CA: FAUX" mais "CA à tout usage: Oui" ).Pour la deuxième partie, je vais créer un autre fichier de configuration facilement digestible. Tout d'abord,
touchleopenssl-server.cnf(vous pouvez également en créer un pour les certificats utilisateur).Ensuite, ouvrez-le et ajoutez ce qui suit.
Si vous développez et devez utiliser votre poste de travail en tant que serveur, vous devrez peut-être effectuer les opérations suivantes pour Chrome. Sinon, Chrome peut se plaindre qu'un nom commun n'est pas valide (
ERR_CERT_COMMON_NAME_INVALID) . Je ne sais pas quelle est la relation entre une adresse IP dans le SAN et un CN dans ce cas.Ensuite, créez la demande de certificat de serveur. N'oubliez pas d' omettre
-x509*. L'ajout-x509créera un certificat et non une demande.Une fois cette commande exécutée, vous recevrez une demande
servercert.csret une clé privéeserverkey.pem.Et vous pouvez l'inspecter à nouveau.
Ensuite, vous devez le signer avec votre CA.
Vous êtes presque prêt à signer le certificat du serveur par votre autorité de certification. L'autorité de certification a
openssl-ca.cnfbesoin de deux sections supplémentaires avant d'émettre la commande.Tout d'abord, ouvrez
openssl-ca.cnfet ajoutez les deux sections suivantes.Ensuite, ajoutez ce qui suit à la
[ CA_default ]section deopenssl-ca.cnf. Je les ai laissés de côté plus tôt, car ils peuvent compliquer les choses (ils n'étaient pas utilisés à l'époque). Vous allez maintenant voir comment ils sont utilisés, alors j'espère qu'ils auront du sens.Troisièmement, touchez
index.txtetserial.txt:Ensuite, procédez comme suit:
Vous devriez voir semblable à ce qui suit:
Une fois la commande exécutée, vous aurez un certificat de serveur fraîchement émis dans
servercert.pem. La clé privée a été créée précédemment et est disponible dansserverkey.pem.Enfin, vous pouvez inspecter votre certificat fraîchement émis avec les éléments suivants:
Plus tôt, vous avez ajouté ce qui suit à
CA_default:copy_extensions = copy. Cette copie copie l'extension fournie par la personne qui fait la demande.Si vous omettez
copy_extensions = copy, votre certificat de serveur n'aura pas les noms alternatifs de sujet (SAN) commewww.example.cometmail.example.com.Si vous utilisez
copy_extensions = copy, mais ne regardez pas la demande, le demandeur pourrait être en mesure de vous inciter à signer quelque chose comme une racine subordonnée (plutôt qu'un serveur ou un certificat utilisateur). Ce qui signifie qu'il / elle pourra frapper des certificats qui remonteront à votre racine de confiance. Assurez-vous de vérifier la demandeopenssl req -verifyavant de signer.Si vous l' omettez
unique_subjectou le définissezyes, vous ne pourrez créer qu'un seul certificat sous le nom distinctif du sujet.La tentative de création d'un deuxième certificat lors de l'expérimentation se traduira par les éléments suivants lors de la signature du certificat de votre serveur avec la clé privée de l'autorité de certification:
Il
unique_subject = noest donc parfait pour les tests.Si vous souhaitez vous assurer que le nom de l' organisation est cohérent entre les autorités de certification auto-signées, les autorités de certification subordonnées et les certificats d' entité finale , ajoutez les éléments suivants à vos fichiers de configuration d'autorité de certification:
Si vous souhaitez autoriser la modification du nom de l' organisation , utilisez:
Il existe d'autres règles concernant la gestion des noms DNS dans les certificats X.509 / PKIX. Reportez-vous à ces documents pour les règles:
Les RFC 6797 et RFC 7469 sont répertoriées, car elles sont plus restrictives que les autres RFC et documents CA / B. Les RFC 6797 et 7469 ne permettent pas non plus une adresse IP.
la source
openssl reqest utilisé pour générer la CSR,openssl req -x509est utilisé pour générer le certificat CA (j'ai vu dans un autre endroit que vous pourriez également créer un certificat auto-signé),openssl caest utilisé pour signer une CSR avec un certificat CA. Droite? Ce qui m'embrouille aussi, c'est que les mêmes parties du fichier openssl.cnf sont utilisées avec des valeurs différentes selon la commande ... Je pense que je suis totalement perdu maintenant.openssl req -x509est utilisé pour créer l'AC. Deuxièmement,openssl reqest utilisé pour créer la CSR du serveur. Troisièmement,openssl caest utilisé pour créer le certificat de serveur et le certifier avec la signature de l'autorité de certification.openssl-ca.cnfetopenssl-server.cnf. Après vous être habitué à eux et comment les sections sont invoquées, vous pouvez les combiner en une monstruosité commeopenssl.cnf.En plus de répondre à @jww, je voudrais dire que la configuration dans openssl-ca.cnf,
définit le nombre de jours par défaut pendant lesquels le certificat signé par ce root-ca sera valide. Pour définir la validité de root-ca lui-même, vous devez utiliser l'option '-days n' dans:
A défaut, votre root-ca ne sera valide que pour le mois par défaut et tout certificat signé par cette autorité de certification racine aura également une validité d'un mois.
la source