Comment créer un certificate auto-signé avec openssl?

J’ajoute le support https à un périphérique Linux intégré. J’ai essayé de générer un certificate auto-signé en procédant comme suit:

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 certificate de sécurité du site n’est pas fiable!

Est-ce que je manque quelque chose? Est-ce la bonne façon de créer un certificate 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 append -nodes si vous ne souhaitez pas protéger votre clé privée avec une phrase de passe, sinon elle vous demandera un mot de passe “d’au moins 4 caractères”. Le paramètre days (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 sur Entrée et accepter les valeurs par défaut.

Ajoutez -subj '/CN=localhost' pour supprimer les questions sur le contenu du certificate (remplacez localhost par le domaine de votre choix)

Les certificates auto-signés ne sont validés avec aucun tiers, sauf si vous les importez dans les navigateurs précédemment. Si vous avez besoin de davantage de sécurité, vous devez utiliser un certificate signé par une autorité de certificateion.

Est-ce que je manque quelque chose? Est-ce la bonne façon de créer un certificate auto-signé?

Il est facile de créer un certificate auto-signé. Vous utilisez simplement la commande openssl req . Il peut être difficile d’en créer un qui puisse être utilisé 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 leurs propres exigences et ils sont plus ressortingctifs que l’IETF. Les exigences utilisées par les navigateurs sont documentées sur les forums CA / navigateur (voir les références ci-dessous). Les ressortingctions apparaissent 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) souhaitent un certificate qui retourne à une ancre de confiance, et ils souhaitent que les noms DNS soient présentés de manière particulière dans le certificate. Et les navigateurs évoluent activement contre les certificates de serveur auto-signés

Certains navigateurs ne facilitent pas l’importation d’un certificate de serveur auto-signé. En fait, vous ne pouvez pas utiliser certains navigateurs, comme le navigateur Android. Donc, la solution complète est de devenir votre propre autorité.

En l’absence de votre propre autorité, vous devez obtenir les noms DNS appropriés pour donner au certificate la plus grande chance de succès. Mais je vous encourage à devenir votre propre autorité. Il est facile de devenir votre propre autorité et il mettra de côté tous les problèmes de confiance (qui peut être plus fiable que vous?).


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

Cela est dû au fait que les navigateurs utilisent une liste prédéfinie d’ancres de confiance pour valider les certificates de serveur. Un certificate auto-signé ne renvoie pas à une ancre approuvée.

Le meilleur moyen d’éviter cela est:

  1. Créez votre propre autorité (par exemple, devenez un CA)
  2. Créer une demande de signature de certificate (CSR) pour le serveur
  3. Signer le CSR du serveur avec votre clé CA
  4. Installer le certificate de serveur sur le serveur
  5. Installer le certificate de l’autorité de certificateion sur le client

Étape 1 – Créez votre propre autorité signifie simplement créer un certificate auto-signé avec CA: true utilisation correcte et correcte 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 des clés est keyCertSign et crlSign (si vous utilisez des CRL) ) est identique à l’identificateur de clé d’autorité (AKI).

Pour devenir votre propre autorité de certificateion, voir Comment signer une demande de signature de certificate avec votre autorité de certificateion? sur le débordement de stack. Ensuite, importez votre autorité de certificateion 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 faites appel aux services d’une autorité de certificateion comme Startcom ou CAcert . Les étapes 1 et 5 vous permettent d’éviter l’autorité tierce et d’agir en tant que votre propre autorité (qui peut mieux faire confiance à vous-même?).

La meilleure façon d’éviter l’avertissement du navigateur est de faire confiance au certificate du serveur. Mais certains navigateurs, comme le navigateur par défaut d’Android, ne vous permettent pas de le faire. Donc, cela ne fonctionnera jamais sur la plate-forme.

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

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


Comment créer un certificate auto-signé avec openssl?

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

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 section alternate_names dans le fichier de configuration (vous devriez régler ceci selon vos goûts):

 [ 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 

Il est important d’inscrire le nom DNS dans le SAN et non le CN car les forums IETF et CA / Browser spécifient la pratique. Ils spécifient également que les noms DNS dans le CN sont obsolètes (mais non interdits). Si vous placez un nom DNS dans le CN, il doit être inclus dans le SAN sous les stratégies CA / B. Donc, vous ne pouvez pas éviter d’utiliser le nom secondaire du sujet.

Si vous ne mettez pas de noms DNS dans le SAN, le certificate ne sera pas validé sous un navigateur et par d’autres agents utilisateurs qui respectent les directives du forum CA / Browser.

Connexes: les navigateurs suivent les règles du forum CA / navigateur. et non les politiques de l’IETF. C’est l’une des raisons pour lesquelles un certificate 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 certificate auto-signé (notez l’ajout de l’option -x509 ):

 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 l’absence de l’option -x509 ):

 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 certificate 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 -config option -config )

 [ req ] default_bits = 2048 default_keyfile = server-key.pem distinguished_name = subject req_extensions = req_ext x509_extensions = x509_ext ssortingng_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 its 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 # ssortingctly follow the CA/Browser Baseline Requirements will fail). commonName = Common Name (eg 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 certificatee. Ie, openssl req -x509 ... [ x509_ext ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer # You only need digitalSignature below. *If* you don't allow # RSA Key transport (ie, 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 certificatee signing request. Ie, 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 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 

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.

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

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

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

 -x509 

Cette option génère un certificate auto-signé au lieu d’une demande de certificate. Ceci est généralement utilisé pour générer un certificate de test ou une autorité de certificateion racine auto-signée.

 -newkey arg 

Cette option crée une nouvelle demande de certificate 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 taille nbits .

 -keyout filename 

Cela donne le nom de fichier pour écrire la nouvelle clé privée créée.

 -out filename 

Ceci spécifie le nom de fichier de sortie pour écrire ou standard par défaut.

 -days n 

Lorsque l’option -x509 est utilisée, elle spécifie le nombre de jours pendant lesquels le certificate doit être certifié. La valeur par défaut est 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 ce qui précède, je viens de le résumer ici.

La commande suivante répond à tous vos besoins:

 openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650 

Il crée un certificate pour le domaine example.com qui est

  • relativement fort (à partir de 2018) et
  • valable 3650 jours (~ 10 ans).

Il crée les fichiers suivants:

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

Comme toutes les informations sont fournies sur la ligne de commande, il n’y a pas de saisie interactive ennuyeuse. De plus, toutes les étapes nécessaires sont exécutées par cette seule invocation OpenSSL: de la génération de la clé privée au certificate auto-signé.

Étant donné que le certificate est auto-signé et doit être accepté manuellement par les utilisateurs, il n’est pas logique d’utiliser une crypto à faible expiration ou faible.

À l’avenir, vous voudrez peut-être utiliser plus de 4096 bits pour la clé RSA et un algorithme de hachage plus fort que sha256 , mais à partir de 2018, il s’agit de valeurs saines. Ils sont suffisamment forts tout en étant supportés par tous les navigateurs modernes.

Remarque: Théoriquement, vous pouvez -nodes paramètre -nodes (qui signifie “pas de cryptage DES”), auquel cas example.key serait crypté avec un mot de passe. Cependant, cela n’est presque jamais utile pour une installation sur un serveur, car vous devrez soit stocker le mot de passe sur le serveur, soit le saisir manuellement à chaque redémarrage.

Je ne peux pas faire de commentaire, alors je vais vous donner une réponse séparée. J’ai trouvé quelques problèmes avec la réponse unique acceptée:

  • Le one-liner comprend un mot de passe dans la clé.
  • Le one-liner utilise SHA1 qui dans de nombreux navigateurs émet 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 de transmettre -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 demandera une phrase secrète.

Pour combiner les deux dans un fichier .pem:

 cat server.crt server.key > cert.pem 

Je recommande d’append le paramètre -sha256 pour utiliser l’algorithme de hachage SHA-2, car les principaux navigateurs envisagent d’afficher les certificates 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’infos sur le blog 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é au certificate auto-signé. Mais je recommande toujours de l’utiliser comme une bonne habitude de ne pas utiliser les fonctions de hachage cryptographiques obsolètes / non sécurisées. Une explication complète est disponible dans: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificatees-above-the-end-entity-certificatee-to-be-sha1-base

Les navigateurs modernes génèrent désormais une erreur de sécurité pour les certificates auto-signés par ailleurs bien formés s’ils ne disposent pas d’un réseau SAN (Subject Alternate Name). OpenSSL ne fournit pas de moyen de ligne de commande pour spécifier cela , de nombreux didacticiels et signets de développeurs sont donc devenus obsolètes.

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

  1. Créez un fichier de configuration 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éer le certificate 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 depuis https://support.cisortingx.com/article/CTX135602

C’est le script que j’utilise sur les zones locales pour définir le SAN (subjectAltName) dans des certificates 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 certificate. Les sections ci-dessous sont commentées. Nommez le script (par exemple generate-ssl.sh ) et atsortingbuez-lui des permissions exécutables. Les fichiers seront écrits dans le même répertoire que le script.

À partir de Chrome 58, le SAN doit être défini dans des certificates 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 certificate et vérifier que le SAN est défini correctement.

  ... 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 certificate ci-dessus dans votre fichier de configuration comme suit:

  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  

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

2017 Un paquebot:

 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 un autre fichier de configuration. Tiré d'une réponse ici . Cela crée un seul fichier .pem contenant à la fois la clé privée et cert. Vous pouvez les déplacer pour séparer les fichiers .pem si nécessaire.

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 certificate auprès d’une autorité de certificateion (CA) connue.

Comme il s’agit d’un certificate auto-signé, il n’y a pas d’AC et vous pouvez ignorer cet avertissement en toute sécurité et continuer. Si vous souhaitez obtenir un vrai certificate qui sera reconnaissable par quiconque sur Internet, la procédure est décrite ci-dessous.

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

J’ai plus de détails à ce sujet dans un post sur https://bigthinkingapplied.com/secure-the-connection-installing-certificatees-on-3-common-web-servers/

Un liner FTW. J’aime garder les choses simples. Pourquoi ne pas utiliser une seule commande contenant TOUS les arguments nécessaires? Voici comment je l’aime – Cela crée un certificate 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 certificate. De cette façon, vous pouvez définir les parameters et exécuter la commande, obtenir votre sortie, puis prendre le café.

>> plus ici <<

Générer des clés

J’utilise /etc/mysql pour le stockage de cert car /etc/apparmor.d/usr.sbin.mysqld contient /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 

Sur ma configuration, le serveur ubuntu s’est connecté à /var/log/mysql/error.log

Notes de suivi:

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

    Mysql pourrait se voir refuser l’access en lecture à votre fichier cert s’il ne se trouve pas dans la configuration apparmors . Comme mentionné dans les étapes précédentes ^, Enregistrez tous nos certs en tant que fichiers .pem dans le répertoire /etc/mysql/ qui est approuvé par défaut par apparmor (ou modifiez votre apparmor / SELinux pour autoriser l’access à vos fichiers stockés).

  • SSL error: Unable to get private key

    Votre version du serveur mysql peut ne pas supporter le format rsa:2048 par défaut.

    Covert a généré rsa:2048 en plaine avec:

     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 firebase database est cryptée par SSL :

    Vérification de la connexion

    Lorsque vous êtes connecté à l’instance MySQL, vous pouvez lancer la requête:

     show status like 'Ssl_cipher'; 

    Si votre connexion n’est pas cryptée, le résultat sera vide:

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

    Sinon, une chaîne de longueur différente de zéro sera affichée pour le chiffrement utilisé:

     mysql> show status like 'Ssl_cipher'; +---------------+--------------------+ | Variable_name | Value | +---------------+--------------------+ | Ssl_cipher | DHE-RSA-AES256-SHA | +---------------+--------------------+ 1 row in set (0.00 sec) 
  • Exiger le langage ssl pour la connexion de l’utilisateur spécifique (‘require 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; 

    To connect, the client must specify the –ssl-ca option to authenticate the server certificatee, and may additionally specify the –ssl-key and –ssl-cert options. If neither –ssl-ca option nor –ssl-capath option is specified, the client does not authenticate the server certificatee.


Alternate link: Lengthy tutorial here http://www.madirish.net/214

oneliner v2017:

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