Comment créer un certificat auto-signé avec OpenSSL


1294

J'ajoute la prise en charge HTTPS à un appareil Linux intégré. J'ai essayé de générer un certificat auto-signé avec ces étapes:

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

Cela fonctionne, mais je reçois des erreurs avec, par exemple, Google Chrome:

Ce n'est probablement pas le site que vous recherchez!
Le certificat de sécurité du site n'est pas fiable!

Suis-je en train de manquer quelque chose? Est-ce la bonne façon de créer un certificat auto-signé?


40
Les certificats auto-signés sont considérés comme non sécurisés pour Internet. Firefox traitera le site comme ayant un certificat non valide, tandis que Chrome agira comme si la connexion était HTTP simple. Plus de détails: gerv.net/security/self-signed-certs
user1202136

34
Vous devez importer votre certificat d'autorité de certification dans vos navigateurs et dire aux navigateurs que vous faites confiance au certificat -ou- le faire signer par l'une des grandes organisations à prix d'argent qui sont déjà approuvées par les navigateurs -ou- ignorer l'avertissement et cliquer sur passé. J'aime moi-même la dernière option.
trojanfoe

12
Vous ne devez pas utiliser les paramètres OpenSSL "stock" comme ça. En effet, vous ne pouvez pas placer de noms DNS dans le nom alternatif du sujet (SAN). Vous devez fournir un fichier de configuration avec une alternate_namessection et le transmettre avec l' -configoption. En outre, placer un nom DNS dans le nom commun (CN) est déconseillé (mais pas interdit) à la fois par l'IETF et les forums CA / Browser. Tout nom DNS dans le CN doit également être présent dans le SAN. Il n'y a aucun moyen d'éviter d'utiliser le SAN. Voir la réponse ci-dessous.
2015

5
En plus du commentaire de @jww. En mai 2017, Chrome n'acceptait plus les certificats sans SAN (emtpy): "Le certificat de ce site ne contient pas d'extension de nom de sujet alternatif contenant un nom de domaine ou une adresse IP."
GerardJP

6
De nos jours, tant que votre serveur Web est accessible par son nom de domaine complet sur le port 80 via Internet, vous pouvez utiliser LetsEncrypt et obtenir des certificats CA complets gratuits (valables 90 jours, le renouvellement peut être automatisé) qui ne donneront aucun avertissement de navigateur / messages. www.letsencrypt.com
barny

Réponses:


2131

Vous pouvez le faire en une seule commande:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Vous pouvez également ajouter -nodes(abréviation de no DES) si vous ne souhaitez pas protéger votre clé privée avec une phrase secrète. Sinon, il vous demandera un mot de passe "au moins 4 caractères".

Le daysparamètre (365) que vous pouvez remplacer par n'importe quel nombre pour affecter la date d'expiration. Il vous demandera alors des choses comme "Nom du pays", mais vous pouvez simplement appuyer Enteret accepter les valeurs par défaut.

Ajoutez -subj '/CN=localhost'pour supprimer les questions sur le contenu du certificat (remplacez-le localhostpar le domaine souhaité).

Les certificats auto-signés ne sont validés auprès d'aucun tiers, sauf si vous les avez importés dans les navigateurs précédemment. Si vous avez besoin de plus de sécurité, vous devez utiliser un certificat signé par une autorité de certification (CA).


8
Pour toute personne intéressée, voici la documentation , si vous voulez vérifier vous-même quelque chose.

17
Comment la signature avec un tiers offre-t-elle plus de sécurité?
James Mills

201
Pour tous ceux qui utilisent cela dans l'automatisation, voici tous les paramètres communs pour le sujet:-subj "/C=US/ST=Oregon/L=Portland/O=Company Name/OU=Org/CN=www.example.com"
Alex S

17
@JamesMills Je veux dire, pensez-y - si un gars à l'ombre avec des "bonbons gratuits" écrits sur le côté de sa camionnette vous invite à entrer, vous allez totalement réfléchir à deux fois et être sur vos gardes - mais si quelqu'un en qui vous avez confiance - comme vraiment en toute confiance - est du genre "naw man, il est légitime", vous allez être tout à propos de ce bonbon gratuit.
BrainSlugs83

73
N'oubliez pas d'utiliser -sha256pour générer un certificat basé sur SHA-256.
Gea-Suan Lin

536

Suis-je en train de manquer quelque chose? Est-ce la bonne façon de créer un certificat auto-signé?

Il est facile de créer un certificat auto-signé. Vous utilisez simplement la openssl reqcommande. Il peut être difficile d'en créer un qui peut être consommé par la plus grande sélection de clients, comme les navigateurs et les outils de ligne de commande.

C'est difficile car les navigateurs ont leur propre ensemble d'exigences, et ils sont plus restrictifs que l' IETF . Les exigences utilisées par les navigateurs sont documentées sur les forums CA / Browser (voir les références ci-dessous). Les restrictions se posent dans deux domaines clés: (1) les ancres de confiance et (2) les noms DNS.

Les navigateurs modernes (comme le warez que nous utilisons en 2014/2015) veulent un certificat qui renvoie à une ancre de confiance, et ils veulent que les noms DNS soient présentés de manière particulière dans le certificat. Et les navigateurs évoluent activement contre les certificats de serveur auto-signés.

Certains navigateurs ne facilitent pas exactement l'importation d'un certificat de serveur auto-signé. En fait, vous ne pouvez pas avec certains navigateurs, comme le navigateur d'Android. La solution complète est donc de devenir votre propre autorité.

En l'absence de devenir votre propre autorité, vous devez obtenir les bons noms DNS pour donner au certificat les meilleures chances de succès. Mais je vous encourage à devenir votre propre autorité. Il est facile de devenir votre propre autorité, et cela évitera tous les problèmes de confiance (à qui mieux faire confiance que vous?).


Ce n'est probablement pas le site que vous recherchez!
Le certificat de sécurité du site n'est pas fiable!

En effet, les navigateurs utilisent une liste prédéfinie d'ancres de confiance pour valider les certificats de serveur. Un certificat auto-signé ne renvoie pas à une ancre approuvée.

La meilleure façon d'éviter cela est:

  1. Créez votre propre autorité (c.-à-d. Devenez CA )
  2. Créer une demande de signature de certificat (CSR) pour le serveur
  3. Signez la CSR du serveur avec votre clé CA
  4. Installer le certificat de serveur sur le serveur
  5. Installer le certificat CA sur le client

Étape 1 - Créer votre propre autorité signifie simplement créer un certificat auto-signé avec CA: trueune utilisation appropriée des clés. Cela signifie que le sujet et l' émetteur sont la même entité, CA est défini sur true dans les contraintes de base (il doit également être marqué comme critique), l'utilisation de la clé est keyCertSignet crlSign(si vous utilisez des listes de révocation de certificats) et l' identificateur de la clé du sujet (SKI) est Identique à l' identifiant de clé d'autorité (AKI).

Pour devenir votre propre autorité de certification, voir * Comment signez-vous une demande de signature de certificat avec votre autorité de certification? sur Stack Overflow. Ensuite, importez votre autorité de certification dans le Trust Store utilisé par le navigateur.

Les étapes 2 à 4 correspondent à peu près à ce que vous faites maintenant pour un serveur public lorsque vous vous inscrivez aux services d'une autorité de certification comme Startcom ou CAcert . Les étapes 1 et 5 vous permettent d'éviter l'autorité tierce et d'agir comme votre propre autorité (à qui faire confiance mieux que vous?).

La deuxième meilleure façon d'éviter l'avertissement du navigateur est de faire confiance au certificat du serveur. Mais certains navigateurs, comme le navigateur par défaut d'Android, ne vous permettent pas de le faire. Cela ne fonctionnera donc jamais sur la plate-forme.

Le problème des navigateurs (et autres agents utilisateurs similaires) qui ne font pas confiance aux certificats auto-signés va être un gros problème dans l'Internet des objets (IoT). Par exemple, que va-t-il se passer lorsque vous vous connectez à votre thermostat ou réfrigérateur pour le programmer? La réponse est, rien de bon en ce qui concerne l'expérience utilisateur.

Le groupe de travail WebAppSec du W3C commence à examiner la question. Voir, par exemple, Proposition: Marquer HTTP comme non sécurisé .


Comment créer un certificat auto-signé avec OpenSSL

Les commandes ci-dessous et le fichier de configuration créent un certificat auto-signé (il vous montre également comment créer une demande de signature). Ils diffèrent des autres réponses sur un point: les noms DNS utilisés pour le certificat auto-signé se trouvent dans le nom alternatif du sujet (SAN) et non dans le nom commun (CN) .

Les noms DNS sont placés dans le SAN via le fichier de configuration avec la ligne subjectAltName = @alternate_names(il n'y a aucun moyen de le faire via la ligne de commande). Ensuite, il y a une alternate_namessection dans le fichier de configuration (vous devez régler cela à votre goût):

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# IP.1        = 127.0.0.1
# IP.2        = ::1

Il est important de mettre le nom DNS dans le SAN et non le CN, car à la fois l'IETF et le CA / Forums du navigateur précisent la pratique. Ils précisent également que les noms DNS dans le CN sont obsolètes (mais pas interdits). Si vous mettez un nom DNS dans le CN, il doit être inclus dans le SAN sous les stratégies CA / B. Vous ne pouvez donc pas éviter d'utiliser l'autre nom du sujet.

Si vous ne placez pas de noms DNS dans le SAN, le certificat ne pourra pas être validé sous un navigateur et d'autres agents utilisateurs qui suivent les directives de CA / Browser Forum.

Connexes: les navigateurs suivent les politiques de CA / Browser Forum; et non les politiques de l'IETF. C'est l'une des raisons pour lesquelles un certificat créé avec OpenSSL (qui suit généralement l'IETF) ne valide parfois pas sous un navigateur (les navigateurs suivent le CA / B). Ce sont des normes différentes, elles ont des politiques d'émission différentes et des exigences de validation différentes.


Créez un certificat auto-signé (notez l'ajout d'une -x509option):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

Créez une demande de signature (notez le manque d' -x509option):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

Imprimez un certificat auto-signé :

openssl x509 -in example-com.cert.pem -text -noout

Imprimer une demande de signature :

openssl req -in example-com.req.pem -text -noout

Fichier de configuration (transmis via -configoption)

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = test@example.com

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier    = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

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.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

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.


4
Est-il possible d'utiliser des caractères génériques dans la alternate_namessection? Particulièrement des sous-sous-domaines. J'ai une question référençant cette réponse ici: serverfault.com/questions/711596/…
LeonardChallis

3
Je viens de répondre à sa question précise. Je pense que cela n'a pas de sens d'ajouter cette longue description de la sécurité alors que la réponse était si simple
Diego Woitasen

14
@diegows - votre réponse n'est pas complète ou correcte. La raison pour laquelle ce n'est pas correct est discutée dans le long post que vous ne voulez pas lire :)
jww

1
Merci! J'ai trouvé votre message très utile. Pour info, je jouais récemment avec le coffre-fort et j'ai trouvé qu'il insistait sur IP.x 127.0.0.1 plutôt que DNS.x 127 ... Je n'ai pas vérifié si c'était dans la norme ou non.
Chomeh

4
Merci @jww. Vous avez dit: "1. Créez votre propre autorité (c.-à-d., Devenez une autorité de certification)" , puis dites: "5. Installez le certificat de l'autorité de certification sur le client" . Si la clé racine était compromise, une personne malveillante pourrait signer un certificat pour n'importe quel domaine avec cette clé, et si elle vous incite à accéder à son site Web, elle peut désormais lancer une attaque de type intermédiaire. Existe-t-il un moyen de créer l'autorité de certification racine de telle sorte qu'elle ne puisse signer que des autorités de certification intermédiaires et non des certificats? Ensuite, vous pouvez protéger votre autorité de certification intermédiaire avec une contrainte de nom.
Robin Zimmermann

408

Voici les options décrites dans la réponse de @ diegows , décrites plus en détail dans la documentation :

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
req

Demande de certificat PKCS # 10 et utilitaire de génération de certificat.

-x509

cette option génère un certificat auto-signé au lieu d'une demande de certificat. Ceci est généralement utilisé pour générer un certificat de test ou une autorité de certification racine auto-signée.

-newkey arg

cette option crée une nouvelle demande de certificat et une nouvelle clé privée. L'argument prend plusieurs formes. rsa: nbits , où nbits est le nombre de bits, génère une clé RSA de nbits de taille.

-keyout filename

cela donne le nom du fichier dans lequel écrire la clé privée nouvellement créée.

-out filename

Ceci spécifie le nom du fichier de sortie dans lequel écrire ou la sortie standard par défaut.

-days n

lorsque l' option -x509 est utilisée, cela spécifie le nombre de jours pour certifier le certificat. La valeur par défaut est de 30 jours.

-nodes

si cette option est spécifiée, si une clé privée est créée, elle ne sera pas chiffrée.

La documentation est en fait plus détaillée que ci-dessus; Je viens de le résumer ici.


3
Le XXXdans la commande d'origine doit être remplacé par le «nombre de jours pour certifier le certificat pour». La valeur par défaut est de 30 jours. Par exemple, -days XXXdevient -days 365si vous souhaitez que votre certificat soit valide pendant 365 jours. Consultez la documentation pour en savoir plus .
Nathan Jones

Merci d'avoir ajouté la documentation. Ce lien IBM sur la création d'un certificat auto-signé à l'aide d'une commande qui semble identique à cette réponse
The Red Pea

314

À partir de 2020, la commande suivante répond à tous vos besoins, y compris SAN:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -extensions san -config \
  <(echo "[req]"; 
    echo distinguished_name=req; 
    echo "[san]"; 
    echo subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1
    ) \
  -subj "/CN=example.com"

Dans OpenSSL ≥ 1.1.1, cela peut être raccourci à:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout example.key -out example.crt -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1"

Il crée un certificat qui est

  • valable pour les domaines example.comet example.net(SAN),
  • également valable pour l'adresse IP 10.0.0.1(SAN),
  • relativement forte (à partir de 2020) et
  • valable pendant des 3650jours (~ 10 ans).

Il crée les fichiers suivants:

  • Clé privée: example.key
  • Certificat: example.crt

Toutes les informations sont fournies sur la ligne de commande. Il n'y a aucune entrée interactive qui vous agace. Il n'y a pas de fichiers de configuration avec lesquels vous devez jouer. Toutes les étapes nécessaires sont exécutées par une seule invocation OpenSSL : de la génération de la clé privée jusqu'au certificat auto-signé.

Remarque # 1: Paramètres Crypto

Étant donné que le certificat est auto-signé et doit être accepté manuellement par les utilisateurs, il n'est pas logique d'utiliser une expiration courte ou une cryptographie faible.

À l'avenir, vous voudrez peut-être utiliser plus de 4096bits pour la clé RSA et un algorithme de hachage plus fort que sha256, mais à partir de 2020, ce sont des valeurs sensées. Ils sont suffisamment solides tout en étant pris en charge par tous les navigateurs modernes.

Remarque n ° 2: paramètre " -nodes"

Théoriquement, vous pourriez omettre le -nodesparamètre (ce qui signifie "pas de cryptage DES"), auquel cas il example.keyserait crypté avec un mot de passe. Cependant, cela n'est presque jamais utile pour une installation de serveur, car vous devrez soit stocker également le mot de passe sur le serveur, soit le saisir manuellement à chaque redémarrage.

Remarque n ° 3: Voir aussi


1
Je ne pouvais pas comprendre exactement ce qui était à blâmer dans l'argument arg / CN = localhost en C: / Program Files / Git / CN = localhost, alors j'ai juste exécuté la commande entière dans plain cmd.exe et cela a très bien fonctionné. Juste au cas où quelqu'un aurait du mal avec celui-ci.
Yuriy Pozniak

1
@FranklinYu Êtes-vous sûr que rsa: 2048 sera suffisant dans 10 ans? Parce que c'est la période de validité. Comme expliqué, il n'est pas logique d'utiliser une expiration courte ou une cryptographie faible. La plupart des clés RSA 2048 bits ont une période de validité de 1 à 3 ans au maximum. En ce qui concerne OpenSSL 1.1.1, je laisse toujours sha256 dedans, il est donc plus explicite et évident de changer si vous voulez un hachage plus fort.
vog

1
@DaveFerguson Le certificat n'est-il pas alors créé pour //CN=localhostau lieu de /CN=localhost? Est-ce qu'une bonne évasion aidera ici? Par exemple, le remplacement /CN=localhostpar "/CN=localhost"résout-il le problème de manière propre?
vog

4
1000 + 1 pour créer un "one-liner" qui utilise le nouveau SAN requis sans avoir à créer un fichier de configuration de longue haleine avec beaucoup de passe-partout. Bien joué!
Joshua Pinter

1
@cautionbug Merci! Je viens de modifier cela dans la réponse. La réponse est-elle maintenant correcte pour Windows / MinGW?
VOG

143

Je ne peux pas commenter, donc je vais mettre cela comme une réponse distincte. J'ai trouvé quelques problèmes avec la réponse monoligne acceptée:

  • La doublure comprend une phrase secrète dans la clé.
  • Le one-liner utilise SHA-1 qui, dans de nombreux navigateurs, lance des avertissements dans la console.

Voici une version simplifiée qui supprime la phrase secrète, augmente la sécurité pour supprimer les avertissements et inclut une suggestion dans les commentaires à passer dans -subj pour supprimer la liste complète des questions:

openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

Remplacez «localhost» par le domaine dont vous avez besoin. Vous devrez exécuter les deux premières commandes une par une car OpenSSL vous demandera une phrase secrète.

Pour combiner les deux dans un fichier .pem:

cat server.crt server.key > cert.pem

6
J'avais besoin d'un certificat de développement pour github.com/molnarg/node-http2 et cette réponse est juste la meilleure.
Capaj

1
Pour combiner le certificat et la clé dans un seul fichier: cat server.crt server.key >foo-cert.pem. Fonctionne avec l'exemple dansopenssl-1.0.2d/demos/ssl/
18446744073709551615

Le certificat que j'ai généré de cette façon utilise toujours SHA1.
user169771

1
Tks, fonctionne très bien pour créer un certificat auto-signé FreeBSD 10 OpenLDAP 2.4avecTLS
Thiago Pereira

2
Qu'en est-il du fichier key.pem?
quikchange

72

Les navigateurs modernes lancent maintenant une erreur de sécurité pour les certificats auto-signés autrement bien formés s'il leur manque un SAN (Subject Alternate Name). OpenSSL ne fournit pas de moyen en ligne de commande pour spécifier cela , donc de nombreux tutoriels et signets de développeurs sont soudainement dépassés.

Le moyen le plus rapide de redémarrer est un fichier de configuration court et autonome:

  1. Créer un fichier de configuration de OpenSSL (exemple: req.cnf)

    [req]
    distinguished_name = req_distinguished_name
    x509_extensions = v3_req
    prompt = no
    [req_distinguished_name]
    C = US
    ST = VA
    L = SomeCity
    O = MyCompany
    OU = MyDivision
    CN = www.company.com
    [v3_req]
    keyUsage = critical, digitalSignature, keyAgreement
    extendedKeyUsage = serverAuth
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = www.company.com
    DNS.2 = company.com
    DNS.3 = company.net
    
  2. Créez le certificat référençant ce fichier de configuration

    openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
     -keyout cert.key -out cert.pem -config req.cnf -sha256
    

Exemple de configuration de https://support.citrix.com/article/CTX135602


1
Cela a fonctionné pour moi après avoir supprimé le dernier paramètre -extensions 'v3_req' qui provoquait une erreur. Utilisation d'OpenSSL pour Windows. Enfin, je parviens à résoudre ce problème! Merci.
CGodo

1
@ Kyopaxa vous avez raison - ce paramètre est redondant avec la ligne 3 du fichier cnf; mise à jour.
rymo

2
Voie solide. Merci. Je suggère d'ajouter -sha256.
cherouvim

5
Vous pouvez maintenant spécifier le SAN sur la ligne de commande avec -extension 'subjectAltName = DNS:dom.ain, DNS:oth.er'voir github.com/openssl/openssl/pull/4986
Alexandre DuBreuil

2
On dirait que cette option est appelée -addextmaintenant.
Alexandr Zarubkin

67

Je recommanderais d'ajouter le paramètre -sha256 , pour utiliser l'algorithme de hachage SHA-2, car les principaux navigateurs envisagent d'afficher les "certificats SHA-1" comme non sécurisés.

La même ligne de commande de la réponse acceptée - @diegows avec -sha256 ajouté

openssl req -x509 -sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem -days XXX

Plus d'informations sur le blog de Google Security .

Mise à jour de mai 2018. Comme beaucoup l'ont noté dans les commentaires, l'utilisation de SHA-2 n'ajoute aucune sécurité à un certificat auto-signé. Mais je recommande toujours de l'utiliser comme une bonne habitude de ne pas utiliser de fonctions de hachage cryptographiques obsolètes / non sécurisées. Une explication complète est disponible dans Pourquoi les certificats supérieurs au certificat d'entité finale sont-ils basés sur SHA-1? .


1
Si c'est une clé auto-signée, cela va quand même générer des erreurs de navigateur, donc cela n'a pas vraiment d'importance
Mark

30
@Mark, c'est important, car SHA-2 est plus sécurisé
Maris B.

1
L'ouverture du certificat dans Windows après avoir renommé le cert.pem en cert.cer indique que l'algorithme d'empreinte digitale est toujours Sha1, mais l'algorithme de hachage de signature est sha256.
péché

2
"Cryptage de classe mondiale * authentification zéro = sécurité zéro" gerv.net/security/self-signed-certs
x-yuri

4
Notez que l'algorithme de signature utilisé sur un certificat auto-signé n'est pas pertinent pour décider s'il est fiable ou non. Les certificats d'autorité de certification racine sont auto-signés. et en mai 2018, il existe encore de nombreux certificats d'autorité de certification racine actifs signés SHA-1. Parce que peu importe si un certificat se fait confiance, ni comment ce certificat vérifie cette confiance. Soit vous faites confiance au certificat racine / auto-signé pour qui il dit qu'il est, soit vous ne le faites pas. Voir security.stackexchange.com/questions/91913/…
Andrew Henle

20

Il s'agit du script que j'utilise sur les boîtes locales pour définir le SAN (subjectAltName) dans les certificats auto-signés.

Ce script prend le nom de domaine (example.com) et génère le SAN pour * .example.com et example.com dans le même certificat. Les sections ci-dessous sont commentées. Nommez le script (par exemple generate-ssl.sh) et donnez-lui des autorisations exécutables. Les fichiers seront écrits dans le même répertoire que le script.

Chrome 58 et versions ultérieures nécessitent que le SAN soit défini dans des certificats auto-signés.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster@$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

Ce script écrit également un fichier d'informations afin que vous puissiez inspecter le nouveau certificat et vérifier que le SAN est correctement configuré.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

Si vous utilisez Apache, vous pouvez référencer le certificat ci-dessus dans votre fichier de configuration comme suit:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

N'oubliez pas de redémarrer votre serveur Apache (ou Nginx ou IIS) pour que le nouveau certificat prenne effet.


Fonctionne sur macOS High Siera et Chrome 58
Saqib Omer

Je ne sais toujours pas comment le CN affecte la configuration globale? J'essaye d'exécuter ceci comme localhostou 127.0.0.1:port#quel serait le correspondant CNpour quelque chose comme ça.
DJ2

@ DJ2 Je définirais BASE_DOMAIN = "localhost"
Drakes

9

One-liner 2017:

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650

Cela fonctionne également dans Chrome 57, car il fournit le SAN, sans avoir d'autre fichier de configuration. Il est tiré d'une réponse ici .

Cela crée un seul fichier .pem qui contient à la fois la clé privée et le certificat. Vous pouvez les déplacer vers des fichiers .pem séparés si nécessaire.


2
Pour les utilisateurs Linux, vous devrez changer ce chemin pour la configuration. par exemple sur les /etc/ssl/openssl.conftravaux Ubuntu en cours
déclinaison le

Pour une ligne unique qui ne vous oblige pas à spécifier l'emplacement openssl.cnf, voir: stackoverflow.com/a/41366949/19163
vog

7

Je ne peux pas commenter donc j'ajoute une réponse séparée. J'ai essayé de créer un certificat auto-signé pour NGINX et c'était facile, mais quand j'ai voulu l'ajouter à la liste blanche de Chrome, j'ai eu un problème. Et ma solution était de créer un certificat racine et de signer un certificat enfant par celui-ci.

Donc, étape par étape. Créer un fichier config_ssl_ca.cnf Remarque, le fichier de configuration a une option basicConstraints = CA: true ce qui signifie que ce certificat est censé être root.

Il s'agit d'une bonne pratique, car vous le créez une fois et vous pouvez le réutiliser.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=root organisation
organizationalUnitName=roote department
commonName=root
emailAddress=root_email@root.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names

Fichier de configuration suivant pour votre certificat enfant.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=FirstName LastName
emailAddress=email@market.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash

La première étape - créer une clé racine et un certificat

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf

La deuxième étape crée la clé enfant et le fichier CSR - Demande de signature de certificat. Parce que l'idée est de signer le certificat enfant par root et d'obtenir un certificat correct

openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr

Ouvrez le terminal Linux et faites cette commande echo 0

echo 1 > ca.srl
touch index.txt

The ca.srl fichier texte contenant le prochain numéro de série à utiliser en hexadécimal. Obligatoire. Ce fichier doit être présent et contenir un numéro de série valide.

Dernière étape, créez un autre fichier de configuration et appelez-le config_ca.cnf

# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca

[ my_ca ]
#  a text file containing the next serial number to use in hex. Mandatory.
#  This file must be present and contain a valid serial number.
serial = ./ca.srl

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./

# the file containing the CA certificate. Mandatory
certificate = ./ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 365

# a section with a set of variables corresponding to DN fields
policy = my_policy

# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy

[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = supplied
organizationalUnitName = optional
commonName = supplied

Vous pouvez vous demander pourquoi c'est si difficile, pourquoi nous devons créer une configuration supplémentaire pour signer le certificat enfant par root. La réponse est simple car le certificat enfant doit avoir un bloc SAN - Subject Alternative Names. Si nous signons le certificat enfant par les utilitaires "openssl x509", le certificat racine supprimera le champ SAN du certificat enfant. Nous utilisons donc "openssl ca" au lieu de "openssl x509" pour éviter la suppression du champ SAN. Nous créons un nouveau fichier de configuration et lui demandons de copier tous les champs étendus copy_extensions = copy .

openssl ca -config config_ca.cnf -out market.crt -in market.csr

Le programme vous pose 2 questions: 1. Signer le certificat? Dites «O» 2. 1 demande de certificat sur 1 est certifiée, vous vous engagez? Dites "Y"

Dans le terminal, vous pouvez voir une phrase avec le mot "Database", cela signifie le fichier index.txt que vous créez par la commande "touch". Il contiendra toutes les informations de tous les certificats que vous créez par l'utilitaire "openssl ca". Pour vérifier la validité du certificat, utilisez:

openssl rsa -in market.key -check

Si vous voulez voir ce qu'il y a dans CRT:

openssl x509 -in market.crt -text -noout

Si vous voulez voir ce que contient la RSE:

openssl req -in market.csr -noout -text 

2
Bien que ce processus semble compliqué, c'est exactement ce dont nous avons besoin pour le domaine .dev, car ce domaine ne prend pas en charge les certificats auto-signés et Chrome et Firefox forcent HSTS. J'ai suivi les étapes suivantes: créer une autorité de certification, créer un certificat et le signer avec mon autorité de certification et, à la fin, faire confiance à mon autorité de certification dans le navigateur. Merci.
bajicdusko

1
Vous monsieur, êtes une putain de légende. Mon homelab vous remercie!
antsyawn

6

Vous avez la procédure générale correcte. La syntaxe de la commande est ci-dessous.

openssl req -new -key {private key file} -out {output file}

Cependant, les avertissements sont affichés, car le navigateur n'a pas pu vérifier l'identité en validant le certificat auprès d'une autorité de certification (CA) connue.

Comme il s'agit d'un certificat auto-signé, il n'y a pas de CA et vous pouvez ignorer l'avertissement en toute sécurité et continuer. Si vous souhaitez obtenir un vrai certificat qui sera reconnaissable par n'importe qui sur Internet public, la procédure est ci-dessous.

  1. Générer une clé privée
  2. Utilisez cette clé privée pour créer un fichier CSR
  3. Soumettre la RSE à CA (Verisign ou autres, etc.)
  4. Installer le certificat reçu de CA sur le serveur Web
  5. Ajoutez d'autres certificats à la chaîne d'authentification en fonction du type cert

J'ai plus de détails à ce sujet dans un article sur Sécuriser la connexion: création d'un certificat de sécurité avec OpenSSL


6

Un liner FTW. J'aime rester simple. Pourquoi ne pas utiliser une commande qui contient TOUS les arguments nécessaires? Voici comment je l'aime - cela crée un certificat x509 et sa clé PEM:

openssl req -x509 \
 -nodes -days 365 -newkey rsa:4096 \
 -keyout self.key.pem \
 -out self-x509.crt \
 -subj "/C=US/ST=WA/L=Seattle/CN=example.com/emailAddress=someEmail@gmail.com"

Cette commande unique contient toutes les réponses que vous fourniriez normalement pour les détails du certificat. De cette façon, vous pouvez définir les paramètres et exécuter la commande, obtenir votre sortie - puis opter pour le café.

>> Plus ici <<


1
Tous les arguments, à l'exception des SAN ... La réponse de @ vog couvre également cela (et est antérieure à celle-ci) (Cela contient un champ "Objet" plus complet, bien que rempli ...) (Pas un grand fan de l'expiration d'un an non plus)
Gert van den Berg

6

Version one-liner 2017:

CentOS:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Ubuntu:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "/CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

Edit: ajout d'une barre oblique pré-ajoutée à l'option 'subj' pour Ubuntu.


3

Générer des clés

J'utilise /etc/mysqlpour le stockage de certificats car /etc/apparmor.d/usr.sbin.mysqldcontient /etc/mysql/*.pem r.

sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Ajouter une configuration

/etc/mysql/my.cnf

[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem

[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

Lors de ma configuration, le serveur Ubuntu s'est connecté à: /var/log/mysql/error.log

Notes de suivi:

  • SSL error: Unable to get certificate from '...'

    MySQL peut se voir refuser l'accès en lecture à votre fichier de certificat s'il n'est pas dans la configuration des apparmors . Comme mentionné dans les étapes précédentes ^, enregistrez tous nos certificats sous forme de .pemfichiers dans le /etc/mysql/répertoire approuvé par défaut par apparmor (ou modifiez votre apparmor / SELinux pour autoriser l'accès à l'endroit où vous les avez stockés.)

  • SSL error: Unable to get private key

    La version de votre serveur MySQL peut ne pas prendre en charge le rsa:2048format par défaut

    Converti généré rsa:2048 en clair rsaavec:

    openssl rsa -in server-key.pem -out server-key.pem
    openssl rsa -in client-key.pem -out client-key.pem
    
  • Vérifiez si le serveur local prend en charge SSL :

    mysql -u root -p
    mysql> show variables like "%ssl%";
    +---------------+----------------------------+
    | Variable_name | Value                      |
    +---------------+----------------------------+
    | have_openssl  | YES                        |
    | have_ssl      | YES                        |
    | ssl_ca        | /etc/mysql/ca-cert.pem     |
    | ssl_capath    |                            |
    | ssl_cert      | /etc/mysql/server-cert.pem |
    | ssl_cipher    |                            |
    | ssl_key       | /etc/mysql/server-key.pem  |
    +---------------+----------------------------+
    
  • La vérification d'une connexion à la base de données est cryptée SSL :

    Vérification de la connexion

    Une fois connecté à l'instance MySQL, vous pouvez émettre la requête:

    show status like 'Ssl_cipher';
    

    Si votre connexion n'est pas cryptée, le résultat sera vierge:

    mysql> show status like 'Ssl_cipher';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | Ssl_cipher    |       |
    +---------------+-------+
    1 row in set (0.00 sec)
    

    Sinon, il afficherait une chaîne de longueur non nulle pour le chiffre utilisé:

    mysql> show status like 'Ssl_cipher';
    +---------------+--------------------+
    | Variable_name | Value              |
    +---------------+--------------------+
    | Ssl_cipher    | DHE-RSA-AES256-SHA |
    +---------------+--------------------+
    1 row in set (0.00 sec)
    
  • Exiger SSL pour la connexion d'un utilisateur spécifique («exiger SSL»):

    • SSL

    Indique au serveur d'autoriser uniquement les connexions cryptées SSL pour le compte.

    GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
      REQUIRE SSL;
    

    Pour se connecter, le client doit spécifier l'option --ssl-ca pour authentifier le certificat de serveur et peut en outre spécifier les options --ssl-key et --ssl-cert. Si ni l'option --ssl-ca ni l'option --ssl-capath n'est spécifiée, le client n'authentifie pas le certificat de serveur.


Lien alternatif: long tutoriel sur les connexions PHP sécurisées à MySQL avec SSL .


-1; ceci est en grande partie tangentiel à la question posée, et fait également un mauvais travail de préciser d'où viennent ses citations.
Mark Amery

Cela montre l'approvisionnement CA, les certificats serveur / client signés par l'autorité de certification, les configurer pour la lecture par mysqld sur un hôte avec apparmor. Cela illustre un cas plutôt inutile d'héberger l'autorité de certification, le serveur et le client sur la même machine, et d'exposer dangereusement l'autorité de l'autorité de certification au processus mysqld. Cette configuration n'a pas vraiment de sens autre que de tester la configuration SSL dans un environnement de test. Pour exploiter une autorité de certification interne, je recommanderais la chaîne d'outils gnuttls sur openssl help.ubuntu.com/community/GnuTLS et avoir une bonne compréhension de tls avant de contourner le cas de l'applicateur mysqld +
ThorSummoner

3

Comme cela a été discuté en détail, les certificats auto-signés ne sont pas approuvés pour Internet . Vous pouvez ajouter votre certificat auto-signé à de nombreux navigateurs, mais pas à tous . Vous pouvez également devenir votre propre autorité de certification .

La principale raison pour laquelle on ne veut pas obtenir un certificat signé d'une autorité de certification est le coût - Symantec facture entre 995 $ - 1999 $ par an pour les certificats - juste pour un certificat destiné au réseau interne, Symantec facture 399 $ par an . Ce coût est facile à justifier si vous traitez des paiements par carte de crédit ou travaillez pour le centre de profit d'une entreprise très rentable. C'est plus que ce que beaucoup peuvent se permettre pour un projet personnel que l'on crée sur Internet, ou pour un organisme sans but lucratif avec un budget minimal, ou si l'on travaille dans un centre de coûts d'une organisation - les centres de coûts essaient toujours d'en faire plus. avec moins.

Une alternative est d'utiliser certbot (voir à propos de certbot ). Certbot est un client automatique facile à utiliser qui récupère et déploie les certificats SSL / TLS pour votre serveur Web.

Si vous configurez certbot, vous pouvez l'activer pour créer et maintenir un certificat pour vous émis par l' autorité de certification Let's Encrypt .

Je l'ai fait le week-end pour mon organisation. J'ai installé les packages requis pour certbot sur mon serveur (Ubuntu 16.04), puis j'ai exécuté la commande nécessaire pour configurer et activer certbot. On a probablement besoin d'un plugin DNS pour certbot - nous utilisons actuellement DigitalOcean, mais nous pourrons bientôt migrer vers un autre service.

Notez que certaines des instructions n'étaient pas tout à fait correctes et ont pris un peu de temps et de temps avec Google pour comprendre. Cela m'a pris pas mal de temps la première fois mais maintenant je pense que je pourrais le faire en quelques minutes.

Pour DigitalOcean, un des problèmes que j'ai rencontrés a été lorsque j'ai été invité à entrer le chemin d'accès à votre fichier INI d'informations d'identification DigitalOcean. Le script fait référence à la page Applications et API et à l'onglet Jetons / Clés de cette page. Vous devez avoir ou générer un jeton d'accès personnel (lecture et écriture) pour l'API de DigitalOcean - il s'agit d'une chaîne hexadécimale de 65 caractères. Cette chaîne doit ensuite être placée dans un fichier sur le serveur Web à partir duquel vous exécutez certbot. Ce fichier peut avoir un commentaire comme première ligne (les commentaires commencent par #). La seconde ligne est:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

Une fois que j'ai compris comment configurer un jeton de lecture + écriture pour l'API de DigitalOcean, il était assez facile d'utiliser certbot pour configurer un certificat générique . Notez que l'on n'a pas à configurer un certificat générique, on peut à la place spécifier chaque domaine et sous-domaine que l'on veut appliquer au certificat. C'était le certificat générique qui exigeait le fichier INI d'informations d'identification qui contenait le jeton d'accès personnel de DigitalOcean.

Notez que les certificats de clé publique (également appelés certificats d'identité ou certificats SSL) expirent et doivent être renouvelés. Ainsi, vous devrez renouveler votre certificat sur une base périodique (récurrente). La documentation certbot couvre le renouvellement des certificats .

Mon plan est d'écrire un script pour utiliser la commande openssl pour obtenir la date d'expiration de mon certificat et déclencher le renouvellement lorsqu'il est de 30 jours ou moins jusqu'à son expiration. Je vais ensuite ajouter ce script à cron et l'exécuter une fois par jour.

Voici la commande pour lire la date d'expiration de votre certificat:

root@prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.