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é?

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).

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        = [email protected]

# 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:

• RFC 5280, certificat de l'infrastructure de clé publique Internet X.509 et profil de liste de révocation de certificats (CRL)
• RFC 6125, représentation et vérification de l'identité du service d'application basé sur le domaine dans l'infrastructure de clé publique Internet à l'aide de certificats X.509 (PKIX) dans le contexte de la sécurité de la couche de transport (TLS)
• RFC 6797, Annexe A, HTTP Strict Transport Security (HSTS)
• RFC 7469, Extension d'épinglage de clé publique pour HTTP
• Exigences de base de CA / Browser Forum
• Directives de validation étendues du forum CA / Browser

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.

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.

À 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

• Fournissez subjectAltName à openssl directement sur la ligne de commande
• Comment ajouter plusieurs adresses e-mail à un certificat SSL via la ligne de commande?
• En savoir plus sur MSYS_NO_PATHCONV

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

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

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? .

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.

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.

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
[email protected]

[ 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
[email protected]

[ 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 

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

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/[email protected]"

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 <<

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.

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 .

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