Comment signer une demande de signature de certificate avec votre autorité de certificateion?

Lors de ma recherche, j’ai trouvé plusieurs façons de signer une demande de signature de certificate SSL:

  1. En utilisant le module x509 :

     openssl x509 -req -days 360 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt 
  2. En utilisant le module ca :

     openssl ca -cert ca.crt -keyfile ca.key -in server.csr -out server.crt 

Note: Je ne suis pas sûr de l’utilisation des bons parameters pour celui-ci. S’il vous plaît aviser l’utilisation correcte si je dois l’utiliser.

Quel moyen doit-on utiliser pour signer des demandes de certificate avec votre autorité de certificateion? Une méthode est-elle meilleure que l’autre (par exemple, une méthode déconseillée)?

 1. Using the x509 module openssl x509 ... ... 2 Using the ca module openssl ca ... ... 

Ce qui vous manque, c’est le prélude à ces commandes.

Ceci est un processus en deux étapes. Vous devez d’abord configurer votre autorité de certificateion, puis signer un certificate d’entité finale (également appelé serveur ou utilisateur). Les deux commandes éliminent les deux étapes en une. Et les deux supposent que vous avez un fichier de configuration OpenSSL déjà configuré pour les certificates de CA et de serveur (entité finale).


Tout d’abord, créez un fichier de configuration de base:

 $ touch openssl-ca.cnf 

Ensuite, ajoutez les éléments suivants:

 HOME = . RANDFILE = $ENV::HOME/.rnd #################################################################### [ ca ] default_ca = CA_default # The default ca section [ CA_default ] default_days = 1000 # how long to certify for default_crl_days = 30 # how long before next CRL default_md = sha256 # use public key default MD preserve = no # keep passed DN ordering x509_extensions = ca_extensions # The extensions to add to the cert email_in_dn = no # Don't concat the email in the DN copy_extensions = copy # Required to copy SANs from CSR to cert #################################################################### [ req ] default_bits = 4096 default_keyfile = cakey.pem distinguished_name = ca_distinguished_name x509_extensions = ca_extensions ssortingng_mask = utf8only #################################################################### [ ca_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Maryland localityName = Locality Name (eg, city) localityName_default = Baltimore organizationName = Organization Name (eg, company) organizationName_default = Test CA, Limited organizationalUnitName = Organizational Unit (eg, division) organizationalUnitName_default = Server Research Department commonName = Common Name (eg server FQDN or YOUR name) commonName_default = Test CA emailAddress = Email Address emailAddress_default = [email protected] #################################################################### [ ca_extensions ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always, issuer basicConstraints = critical, CA:true keyUsage = keyCertSign, cRLSign 

Les champs ci-dessus sont extraits d’un openssl.cnf plus complexe (vous pouvez le trouver dans /usr/lib/openssl.cnf ), mais je pense qu’ils sont essentiels pour créer le certificate de l’autorité de certificateion et la clé privée.

Ajustez les champs ci-dessus à votre goût. Les valeurs par défaut vous permettent de gagner du temps en saisissant les mêmes informations tout en expérimentant avec le fichier de configuration et les options de commande.

J’ai omis les éléments pertinents de la liste de révocation de certificates, mais les opérations de votre autorité de certificateion devraient les avoir. Voir openssl.cnf et la section associée crl_ext .

Ensuite, exécutez les opérations suivantes. Les -nodes le mot de passe ou la phrase secrète afin que vous puissiez examiner le certificate. C’est une très mauvaise idée d’omettre le mot de passe ou la phrase de passe.

 $ openssl req -x509 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM 

Après l’exécution de la commande, cacert.pem sera votre certificate pour les opérations CA et cakey.pem sera la clé privée. Rappelez-vous que la clé privée n’a pas de mot de passe ni de phrase de passe.

Vous pouvez vider le certificate avec les éléments suivants.

 $ openssl x509 -in cacert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 11485830970703032316 (0x9f65de69ceef2ffc) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/[email protected] Validity Not Before: Jan 24 14:24:11 2014 GMT Not After : Feb 23 14:24:11 2014 GMT Subject: C=US, ST=MD, L=Baltimore, CN=Test CA/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:b1:7f:29:be:78:02:b8:56:54:2d:2c:ec:ff:6d: ... 39:f9:1e:52:cb:8e:bf:8b:9e:a6:93:e1:22:09:8b: 59:05:9f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A X509v3 Authority Key Identifier: keyid:4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: Certificate Sign, CRL Sign Signature Algorithm: sha256WithRSAEncryption 4a:6f:1f:ac:fd:fb:1e:a4:6d:08:eb:f5:af:f6:1e:48:a5:c7: ... cd:c6:ac:30:f9:15:83:41:c1:d1:20:fa:85:e7:4f:35:8f:b5: 38:ff:fd:55:68:2c:3e:37 

Et testez son objective avec les éléments suivants (ne vous inquiétez pas à propos de l’ Any Purpose: Yes , voir “Critique, CA: FAUX” mais “CA quelconque: Oui” ).

 $ openssl x509 -purpose -in cacert.pem -inform PEM Certificate purposes: SSL client : No SSL client CA : Yes SSL server : No SSL server CA : Yes Netscape SSL server : No Netscape SSL server CA : Yes S/MIME signing : No S/MIME signing CA : Yes S/MIME encryption : No S/MIME encryption CA : Yes CRL signing : Yes CRL signing CA : Yes Any Purpose : Yes Any Purpose CA : Yes OCSP helper : Yes OCSP helper CA : Yes Time Stamp signing : No Time Stamp signing CA : Yes -----BEGIN CERTIFICATE----- MIIFpTCCA42gAwIBAgIJAJ9l3mnO7y/8MA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV ... aQUtFrV4hpmJUaQZ7ySr/RjCb4KYkQpTkOtKJOU1Ic3GrDD5FYNBwdEg+oXnTzWP tTj//VVoLD43 -----END CERTIFICATE----- 

Pour la deuxième partie, je vais créer un autre fichier de config facilement digérable. Tout d’abord, touch le openssl-server.cnf (vous pouvez en créer un pour les certificates utilisateur également).

 $ touch openssl-server.cnf 

Ensuite, ouvrez-le et ajoutez les éléments suivants.

 HOME = . RANDFILE = $ENV::HOME/.rnd #################################################################### [ req ] default_bits = 2048 default_keyfile = serverkey.pem distinguished_name = server_distinguished_name req_extensions = server_req_extensions ssortingng_mask = utf8only #################################################################### [ server_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = MD localityName = Locality Name (eg, city) localityName_default = Baltimore organizationName = Organization Name (eg, company) organizationName_default = Test Server, Limited commonName = Common Name (eg server FQDN or YOUR name) commonName_default = Test Server emailAddress = Email Address emailAddress_default = [email protected] #################################################################### [ server_req_extensions ] subjectKeyIdentifier = hash basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" #################################################################### [ alternate_names ] DNS.1 = example.com DNS.2 = www.example.com DNS.3 = mail.example.com DNS.4 = ftp.example.com 

Si vous développez et devez utiliser votre station de travail en tant que serveur, vous devrez peut-être procéder comme suit pour Chrome. Sinon, Chrome peut se plaindre qu’un nom commun n’est pas valide ( ERR_CERT_COMMON_NAME_INVALID ) . Je ne suis pas sûr de la relation entre une adresse IP dans le SAN et un CN dans cette instance.

 # IPv4 localhost IP.1 = 127.0.0.1 # IPv6 localhost IP.2 = ::1 

Ensuite, créez la demande de certificate du serveur. Veillez à omettre -x509 *. L’ajout de -x509 créera un certificate et non une demande.

 $ openssl req -config openssl-server.cnf -newkey rsa:2048 -sha256 -nodes -out servercert.csr -outform PEM 

Une fois cette commande exécutée, vous aurez une demande dans servercert.csr et une clé privée dans serverkey.pem .

Et vous pouvez inspecter à nouveau.

 $ openssl req -text -noout -verify -in servercert.csr Certificate: verify OK Certificate Request: Version: 0 (0x0) Subject: C=US, ST=MD, L=Baltimore, CN=Test Server/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d: ... f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51: 86:e1 Exponent: 65537 (0x10001) Atsortingbutes: Requested Extensions: X509v3 Subject Key Identifier: 1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61 X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com Netscape Comment: OpenSSL Generated Certificate Signature Algorithm: sha256WithRSAEncryption 6d:e8:d3:85:b3:88:d4:1a:80:9e:67:0d:37:46:db:4d:9a:81: ... 76:6a:22:0a:41:45:1f:e2:d6:e4:8f:a1:ca:de:e5:69:98:88: a9:63:d0:a7 

Ensuite, vous devez le signer avec votre autorité de certificateion.


Vous êtes presque prêt à signer le certificate du serveur par votre autorité de certificateion. Le openssl-ca.cnf l’autorité de openssl-ca.cnf nécessite deux sections supplémentaires avant de lancer la commande.

Tout d’abord, ouvrez openssl-ca.cnf et ajoutez les deux sections suivantes.

 #################################################################### [ signing_policy ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### [ signing_req ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment 

Deuxièmement, ajoutez ce qui suit à la section [ CA_default ] de openssl-ca.cnf . Je les ai laissés dehors plus tôt car ils peuvent compliquer les choses (ils étaient inutilisés à l’époque). Maintenant, vous verrez comment ils sont utilisés, alors j’espère qu’ils auront du sens.

 base_dir = . certificatee = $base_dir/cacert.pem # The CA certifcate private_key = $base_dir/cakey.pem # The CA private key new_certs_dir = $base_dir # Location for new certs after signing database = $base_dir/index.txt # Database index file serial = $base_dir/serial.txt # The current serial number unique_subject = no # Set to 'no' to allow creation of # several certificatees with same subject. 

Troisièmement, touchez index.txt et serial.txt :

 $ touch index.txt $ echo '01' > serial.txt 

Effectuez ensuite les opérations suivantes:

 $ openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out servercert.pem -infiles servercert.csr 

Vous devriez voir comme suit:

 Using configuration from openssl-ca.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :ASN.1 12:'MD' localityName :ASN.1 12:'Baltimore' commonName :ASN.1 12:'Test CA' emailAddress :IA5STRING:'[email protected]' Certificate is to be certified until Oct 20 16:12:39 2016 GMT (1000 days) Sign the certificatee? [y/n]:Y 1 out of 1 certificatee requests certified, commit? [y/n]Y Write out database with 1 new ensortinges Data Base Updated 

Une fois la commande exécutée, vous aurez un certificate de serveur fraîchement servercert.pem dans servercert.pem . La clé privée a été créée plus tôt et est disponible dans serverkey.pem .

Enfin, vous pouvez inspecter votre certificate fraîchement moulu avec les éléments suivants.

 $ openssl x509 -in servercert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 9 (0x9) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/[email protected] Validity Not Before: Jan 24 19:07:36 2014 GMT Not After : Oct 20 19:07:36 2016 GMT Subject: C=US, ST=MD, L=Baltimore, CN=Test Server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d: ... f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51: 86:e1 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61 X509v3 Authority Key Identifier: keyid:42:15:F2:CA:9C:B1:BB:F5:4C:2C:66:27:DA:6D:2E:5F:BA:0F:C5:9E X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com Netscape Comment: OpenSSL Generated Certificate Signature Algorithm: sha256WithRSAEncryption b1:40:f6:34:f4:38:c8:57:d4:b6:08:f7:e2:71:12:6b:0e:4a: ... 45:71:06:a9:86:b6:0f:6d:8d:e1:c5:97:8d:fd:59:43:e9:3c: 56:a5:eb:c8:7e:9f:6b:7a 

Auparavant, vous avez ajouté les éléments suivants à CA_default : copy_extensions = copy . Cette extension de copie fournie par la personne effectuant la demande.

Si vous omettez copy_extensions = copy , votre certificate de serveur ne contiendra pas d’autres noms de sujets (SAN), tels que www.example.com et mail.example.com .

Si vous utilisez copy_extensions = copy mais ne examinez pas la requête, le demandeur peut alors vous amener à signer quelque chose comme une racine subordonnée (plutôt qu’un certificate de serveur ou d’utilisateur). Ce qui signifie qu’il sera capable de bash des certificates qui reviennent vers votre racine de confiance. Assurez-vous de vérifier la demande avec openssl req -verify avant de signer.


Si vous omettez unique_subject ou si vous le définissez sur yes , vous ne pourrez créer qu’un seul certificate sous le nom distinctif du sujet.

 unique_subject = yes # Set to 'no' to allow creation of # several ctificates with same subject. 

Si vous essayez de créer un second certificate lors de l’expérimentation, vous obtiendrez les éléments suivants lors de la signature du certificate de votre serveur avec la clé privée de l’autorité de certificateion:

 Sign the certificatee? [y/n]:Y failed to update database TXT_DB error number 2 

Donc, unique_subject = no est parfait pour les tests.


Si vous voulez vous assurer que le nom de l’organisation est cohérent entre les autorités de certificateion auto-signées, les certificates d’autorité de certificateion subordonnée et les certificates d’entité finale, ajoutez les éléments suivants aux fichiers de configuration de votre autorité de certificateion:

 [ policy_match ] organizationName = match 

Si vous souhaitez autoriser la modification du nom de l’organisation, utilisez:

 [ policy_match ] organizationName = supplied 

Il existe d’autres règles concernant le traitement des noms DNS dans les certificates X.509 / PKIX. Reportez-vous à ces documents pour les règles:

  • RFC 5280, profil d’infrastructure de clé publique X.509 et profil de révocation de certificate (CRL)
  • RFC 6125, Représentation et vérification de l’identité du service d’application basé sur un domaine dans une infrastructure à clé publique Internet à l’aide de certificates X.509 (PKIX) dans le contexte du protocole TLS (Transport Layer Security)
  • RFC 6797, Annexe A, HTTP Ssortingct Transport Security (HSTS)
  • RFC 7469, Extension de saisie de clé publique pour HTTP
  • Exigences de base du forum CA / navigateur
  • Directives de validation étendues du CA / Browser Forum

Les documents RFC 6797 et RFC 7469 sont répertoriés car ils sont plus ressortingctifs que les autres documents RFC et CA / B. Les RFC 6797 et 7469 ne permettent pas non plus une adresse IP.

En plus de la réponse de @jww, je voudrais dire que la configuration dans openssl-ca.cnf

 default_days = 1000 # how long to certify for 

définit le nombre de jours par défaut que le certificate signé par cette racine-ca sera valide, pour définir la validité de root-ca, vous devez utiliser l’option ‘-days n’ dans

 openssl req -x509 -days 3000 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM 

Si vous ne le faites pas, votre root-ca ne sera valide que pour 1 mois par défaut et tout certificate signé par ce rot-ca aura également une validité de 1 mois.