Présentation
Initialement développé par Netscape en 1994 pour prendre en charge les capacités de commerce électronique d'Internet, Secure Socket Layer (SSL) a parcouru un long chemin. Au milieu de toutes les cyberattaques, les certificats SSL sont devenus une nécessité régulière pour tout site Web en direct.
Même si Secure Socket Layer (SSL) et Transport Socket Layer (TLS) sont devenus assez omniprésents, nous prendrons un bref instant pour expliquer ce qu'ils font et comment ils le font.
Ne sautez pas le tutoriel OpenSSL rubrique.
Qu'est-ce qu'un certificat SSL ? Comment fonctionne SSL ?
Un certificat Secure Socket Layer (SSL) est un protocole de sécurité qui sécurise les données entre deux ordinateurs en utilisant le cryptage.
En règle générale, les certificats SSL sont utilisés sur les pages Web qui transmettent et reçoivent des données sensibles de l'utilisateur final, telles que le numéro de sécurité sociale, les détails de la carte de crédit, l'adresse personnelle ou le mot de passe. Les formulaires de paiement en ligne en sont un bon exemple et cryptent généralement les informations délicates susmentionnées à l'aide de la technologie SSL 128 ou 256 bits.
Les certificats SSL garantissent l'identité d'un ordinateur distant, le plus souvent un serveur, mais confirment également l'identité de votre ordinateur à l'ordinateur distant pour établir une connexion sécurisée. La sécurité d'Internet a toujours été une voie à double sens et grâce au cryptage SSL, le serveur "serre la main" de votre ordinateur personnel et les deux parties savent avec qui elles communiquent.
Quelle est la différence entre TLS et SSL ?
Il n'y en a pas . Transport Layer Security (TLS) est une version mise à jour de Secure Socket Layer (SSL). Même si la plupart des connexions sécurisées se font via les protocoles TLS, les gens continuent de l'appeler SSL. Dans ce cas, on peut dire sans se tromper que les vieilles habitudes ont la vie dure.
Comment puis-je savoir si une page Web est sécurisée avec SSL ?
En tant qu'internaute, vous avez sans doute remarqué un cadenas et la barre d'informations sur le site passe au vert dans votre navigateur Web, ainsi que le https protocole de connexion.
C'est votre navigateur qui vous informe qu'un site Web est sécurisé à l'aide du cryptage SSL. Cliquer sur la barre d'informations du site fournira des détails supplémentaires sur la connexion ainsi qu'un aperçu du certificat SSL lui-même.
Pourquoi ai-je besoin d'un certificat SSL ?
Prenons un exemple concret.
Vous êtes propriétaire d'un site de commerce électronique et vous venez de louer un serveur avec phoenixNAP et de lancer quelques nouvelles boutiques de commerce électronique. Vous souhaitez que vos visiteurs se sentent en sécurité lorsqu'ils visitent votre e-boutique et surtout qu'ils n'hésitent pas à se connecter et à effectuer un achat.
Un certificat SSL et une connexion HTTPS inspirent confiance aux consommateurs. L'industrie du commerce électronique est étroitement liée à la confiance des consommateurs, et nous pourrions même dire que votre entreprise dépend du sentiment de sécurité de vos clients tout au long de l'expérience d'achat.
Outre les raisons de sécurité évidentes, un certificat SSL augmente le référencement et le classement Google de votre site et renforce la confiance des clients, améliorant ainsi les taux de conversion globaux.
Si cela ne suffit pas pour vous inciter à envisager d'obtenir un certificat SSL pour votre domaine, Google est sûr de vous convaincre. À savoir, à partir de juillet 2018, Google signale chaque site Web sans SSL comme dangereux.
Où puis-je obtenir un certificat SSL ?
Les certificats SSL sont vérifiés et émis par une autorité de certification (CA). Vous postulez en générant un CSR avec une paire de clés sur votre serveur qui, idéalement, contiendrait le certificat SSL. Le CSR contient des détails cruciaux sur l'organisation que l'autorité de certification vérifie.
- Générez un CSR et une paire de clés localement sur votre serveur. La paire de clés se compose d'une clé publique et d'une clé privée.
- Envoyez la CSR et la clé publique à une autorité de certification qui vérifiera votre identité légale et si vous possédez et contrôlez le domaine soumis dans la candidature. L'autorité de certification effectue une vérification de votre organisation et valide si l'organisation est enregistrée à l'emplacement indiqué dans le CSR et si le domaine existe.
- Lorsqu'elle est vérifiée, l'organisation reçoit une copie de son certificat SSL, y compris les détails de l'entreprise ainsi que la clé publique. L'organisation peut maintenant installer le certificat sur son serveur.
- Lorsqu'une autorité de certification émet le certificat, il se lie au certificat "racine de confiance" d'une autorité de certification. Les certificats racine sont intégrés à chaque navigateur et connectés à des certificats émis individuellement pour établir une connexion HTTPS.
Types de certificat SSL
Assurez-vous de choisir une autorité de certification qui prend en charge le type de certificat dont vous avez besoin. Pour votre commodité, vous trouverez ci-dessous une description de chaque type de certificat :
Certificat SSL à domaine unique
Ce type est destiné à être utilisé pour un seul domaine et n'offre aucun support pour les sous-domaines. Par exemple, si le certificat doit être utilisé pour www.phoenixnap.com, il ne prendra en charge aucun autre nom de domaine.
Plusieurs domaines (certificats SAN/UC)
Plusieurs certificats de domaine sont utilisés pour de nombreux domaines et sous-domaines. Outre le nom de domaine complet, vous pouvez ajouter la prise en charge d'autres (sous-)domaines en les ajoutant au champ Autre nom du sujet. Par exemple, un certificat SAN peut inclure le domaine www.phoenixnap.com, son sous-domaine help.phoenixnap.com ainsi qu'un autre domaine (par exemple, www.examplesite.com).
Certificat générique
Les certificats génériques peuvent être utilisés pour un domaine, y compris tous ses sous-domaines. La principale différence est qu'au lieu d'être émis pour un FQDN spécifique, les certificats génériques sont utilisés pour un large éventail de sous-domaines. Par exemple, un certificat générique délivré à *.phoenixnap.com pourrait être utilisé pour un large éventail de sous-domaines sous le domaine principal www.phoenixnap.com, comme le montre l'image ci-dessous.
Niveaux de validation des certificats SSL
Les autorités de certification ont diversifié les niveaux de validation des certificats en réponse à une demande croissante de certificats. Certaines organisations utilisent SSL uniquement pour le cryptage, tandis que d'autres veulent montrer à leurs clients qu'elles sont une entreprise de confiance. Différents besoins ont entraîné différents niveaux de validation des certificats.
Validation de domaine (DV SSL)
Ce type de certificat SSL est idéal pour sécuriser les blogs, les applications de médias sociaux et les sites Web personnels. L'autorité de certification ne garantit pas l'identité d'une organisation et seule la propriété du domaine est vérifiée.
Validation étendue (EV SSL)
L'autorité de certification vérifie la propriété du domaine et mène une enquête approfondie sur l'organisation associée au certificat EV. Des règles strictes sont suivies lors de l'examen d'une demande de validation étendue, et l'autorité de certification doit vérifier les éléments suivants :
- L'identité de l'organisation correspond aux documents officiels.
- L'existence physique, juridique et opérationnelle de l'entité.
- L'organisation a le droit exclusif d'utiliser le domaine spécifié dans le certificat SSL.
- L'organisation a dûment autorisé l'émission du certificat SSL EV.
Créer un certificat SSL
La manière de générer une demande de signature de certificat dépend uniquement de la plate-forme que vous utilisez et de l'outil particulier de votre choix.
Nous allons générer un CSR en utilisant OpenSSL .
OpenSSL est un outil largement utilisé pour travailler avec des fichiers CSR et des certificats SSL et est disponible en téléchargement sur le site officiel OpenSSL. Il s'agit d'un outil d'implémentation open source pour SSL/TLS et est utilisé sur environ 65 % de tous les serveurs Internet actifs, ce qui en fait la norme non officielle de l'industrie.
Debian et Ubuntu
dpkg -l |grep openssl
Si le paquet OpenSSL est installé, il renverra le résultat suivant :
ii libgnutls-openssl27:amd64 2.12.23-12ubuntu2.4 amd64 GNU TLS library - OpenSSL wrapper
ii openssl 1.0.1f-1ubuntu2.16 amd64 Secure Sockets Layer toolkit - cryptographic utility
Si vous ne voyez pas un tel résultat, exécutez la commande suivante pour installer OpenSSL :
apt-get install openssl
Red Hat ou CentOS
Red Hat (version 7.0 et ultérieure) devrait être fourni avec une version limitée préinstallée d'OpenSSL. Il n'offre qu'un support limité pour IDEA, RC5 et MDC2, vous pouvez donc installer les fonctionnalités manquantes. Pour en savoir plus à ce sujet, consultez la documentation d'OpenSSL.
Pour vérifier si OpenSSL est installé sur un serveur yum (par exemple, Red Hat ou CentOS), exécutez la commande suivante :
rpm -qa | grep -i openssl
Cette commande doit renvoyer le résultat suivant :
openssl-1.0.1e-48.el6_8.1.x86_64
openssl-devel-1.0.1e-48.el6_8.1.x86_64
openssl-1.0.1e-48.el6_8.1.i686
Si votre format de sortie diffère, cela signifie qu'OpenSSL n'est pas installé sur votre serveur. Exécutez la commande suivante pour installer OpenSSL :
yum install openssl openssl-devel
Qu'est-ce qu'une demande de signature de certificat (CSR) ?
Une demande de signature de certificat (CSR) contient les informations les plus vitales sur votre organisation et votre domaine.
Habituellement, vous générez une CSR et une paire de clés localement sur le serveur où le certificat SSL sera installé. Cependant, ce n'est pas une règle stricte. Vous pouvez générer une CSR et une paire de clés sur un serveur et installer le certificat sur un autre. Cependant, cela rend les choses plus compliquées. Nous couvrirons également ce scénario.
Secure Socket Layer (SSL) utilise deux longues chaînes de nombres générés aléatoirement, appelés privés et clés publiques . Une clé publique est disponible dans le domaine public car elle fait partie de votre certificat SSL et est communiquée à votre serveur.
La clé privée doit correspondre au CSR avec lequel elle a été générée et, en fin de compte, elle doit correspondre au certificat créé à partir du CSR. Si la clé privée est manquante, cela peut signifier que le certificat SSL n'est pas installé sur le même serveur qui a généré la demande de signature de certificat.
Un CSR contient généralement les informations suivantes :
Paramètre | Description | Exemple de valeur |
Nom commun ou FQDN | FQDN est le nom de domaine complet de votre site Web. Il doit être identique à ce que les utilisateurs saisissent dans le navigateur Web. | www.phoenixnap.com |
Nom de l'organisation (par exemple, société) | Le nom légal complet de votre organisation, y compris les suffixes tels que LLC, Corp, etc. | PhoenixNAP, LLC |
Nom de l'unité organisationnelle | La division de votre organisation qui s'occupe de ce certificat. | NOC |
Nom de la localité (par exemple, ville) | La ville dans laquelle se trouve votre organisation. | Phénix |
État/Région/Province (nom complet) | L'état ou la région dans laquelle se trouve votre organisation. | Arizona |
Code du pays (code à 2 lettres) | Le pays dans lequel votre organisation est située. Toujours saisi sous la forme d'un code ISO à deux lettres. | États-Unis |
Adresse e-mail | Adresse e-mail utilisée pour contacter le webmaster du site. | [e-mail protégé] |
Clé publique | Une clé créée automatiquement qui est générée avec le CSR et va dans le certificat. | Un bloc de texte codé similaire à la clé privée. Voir un exemple de clé privée ci-dessous. |
Veuillez noter que certaines conventions de dénomination doivent être prises en compte. Nom de l'organisation et Nom de l'unité organisationnelle ne doit pas contenir les caractères suivants :< > ~ ! @ # $ % ^ * / \ ( ) ?.,&
Comment générer un CSR
Les demandes de signature de certificat (CSR) sont générées avec une paire de clés - une clé publique et une clé privée. Seule la clé publique est envoyée à une autorité de certification et incluse dans le certificat SSL, et elle fonctionne avec votre clé privée pour chiffrer la connexion. N'importe qui peut avoir accès à votre clé publique et elle vérifie que le certificat SSL est authentique.
Une clé privée est un bloc de texte codé qui, avec le certificat, vérifie la connexion sécurisée entre deux machines. Il ne doit pas être accessible publiquement et ne doit pas être envoyé à l'autorité de certification.
L'intégrité d'un certificat repose sur le fait que vous seul connaissez la clé privée. En cas de compromis ou de perte, re-saisissez votre certificat avec une nouvelle clé privée dès que possible. La plupart des autorités de certification ne vous facturent pas pour ce service.
Option 1 :Générer un CSR
La première chose à faire serait de générer localement une paire de clés RSA 2048 bits. Cette paire contiendra à la fois votre clé privée et votre clé publique. Vous pouvez utiliser l'outil de clé Java ou un autre outil, mais nous travaillerons avec OpenSSL.
Pour générer une clé publique et privée avec une demande de signature de certificat (CSR), exécutez la commande OpenSSL suivante :
openssl req -out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key
Une fois que vous avez généré un CSR avec une paire de clés, il est difficile de voir quelles informations il contient car il ne sera pas dans un format lisible par l'homme. Vous pouvez facilement décoder le CSR sur votre serveur à l'aide de la commande OpenSSL suivante :
openssl req -in server.csr -noout -text
Il est conseillé de décoder le CSR et de vérifier qu'il contient les bonnes informations sur votre organisation avant de l'envoyer à une autorité de certification. Il existe de nombreux décodeurs CSR sur le Web qui peuvent vous aider à faire de même simplement en copiant-collant le contenu de votre fichier CSR.
Pour votre commodité, nous avons répertorié deux (2) outils de décodage RSE en ligne :
- Acheteur SSL
- Crécerelle rousse
Option 2 :Générer un CSR pour une clé privée existante
Il est recommandé d'émettre une nouvelle clé privée chaque fois que vous générez un CSR. Si, pour une raison quelconque, vous devez générer une demande de signature de certificat pour une clé privée existante, utilisez la commande OpenSSL suivante :
openssl req -out CSR.csr -key privateKey.key -new
Option 3 :Générer un CSR pour un certificat et une clé privée existants
openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
Un scénario peu probable dans lequel cela peut s'avérer utile est si vous devez renouveler votre certificat existant, mais que ni vous ni votre autorité de certification n'avez le CSR d'origine. Cela extraira des informations sur votre domaine et votre organisation du certificat SSL et les utilisera pour créer un nouveau CSR, vous faisant ainsi gagner du temps.
Option 4 :générer un certificat auto-signé
Un certificat auto-signé est généralement utilisé pour les environnements de test et de développement et sur un intranet. Générons un certificat auto-signé à l'aide de la commande OpenSSL suivante :
openssl req -newkey rsa:2048 -nodes -keyout domain.key -x509 -days 365 -out domain.crt
Les -days
est défini sur 365, ce qui signifie que le certificat est valide pour les 365 prochains jours. Le -x509
Le paramètre indique qu'il s'agira d'un certificat auto-signé. Un CSR temporaire est généré, et il est utilisé uniquement pour recueillir les informations nécessaires.
Les autorités de certification ne vérifient pas les certificats auto-signés. Ainsi, ils ne sont pas aussi sûrs que les certificats vérifiés. Si une autorité de certification n'a pas signé le certificat, tous les principaux navigateurs afficheront un message d'erreur "certificat non approuvé", comme celui illustré dans l'image ci-dessous.
Si vous ne souhaitez pas protéger votre clé privée avec un mot de passe, vous pouvez ajouter les -nodes
paramètre.
Option 5 :Générer un certificat auto-signé à partir d'une clé privée et d'un CSR existants
Si vous avez déjà un CSR et privé et que vous devez générer un certificat auto-signé, utilisez la commande suivante :
openssl x509 \ -signkey domain.key \ -in domain.csr \ -req -days 365 -out domain.crt
Les -days
est défini sur 365, ce qui signifie que le certificat est valide pour les 365 prochains jours.
Comment copier le contenu d'un fichier CSR
Ouvrez le répertoire dans lequel se trouve votre fichier CSR. Tapez la commande suivante :
sudo cat domain.csr
Remplacer ddomaine avec le paramètre FQDN de votre CSR. Cette commande affichera le contenu du fichier CSR. Copiez tout le contenu, en commençant par "BEGIN CERTIFICATE REQUEST" et en terminant par "END CERTIFICATE REQUEST".
Renouvellement de certificat :ne réutilisez pas les anciens CSR
Ce n'est pas parce que certains serveurs Web autorisent l'utilisation d'anciens CSR pour le renouvellement des certificats que vous devez les utiliser. Par mesure de sécurité, générez toujours une nouvelle CSR et une nouvelle clé privée lorsque vous renouvelez un certificat. S'accrocher à la même clé privée est une route pavée de failles de sécurité.
Aussi, il est recommandé de renouveler un certificat SSL avant la date d'expiration. Sinon, un nouvel achat de certificat sera nécessaire.
Comment vérifier votre CSR, votre certificat SSL et votre clé
Comme nous l'avons déjà mentionné, il serait judicieux de vérifier les informations fournies dans le CSR avant de demander un certificat. Utilisez les commandes suivantes pour vérifier votre demande de signature de certificat, votre certificat SSL et votre clé :
RSE
openssl req -text -noout -verify -in server.csr
Cette commande vérifiera le CSR et affichera les données fournies dans la demande.
Clé
La commande suivante vérifiera la clé et sa validité :
openssl rsa -in server.key -check
Certificat SSL
Lorsque vous devez vérifier un certificat, sa date d'expiration et qui l'a signé, utilisez la commande OpenSSL suivante :
openssl x509 -in server.crt -text -noout
Clé privée
Une clé privée est codée et créée dans un format PEM basé sur Base-64 qui n'est pas lisible par l'homme. Vous pouvez l'ouvrir avec n'importe quel éditeur de texte, mais tout ce que vous verrez, ce sont quelques dizaines de lignes de ce qui semble être des symboles aléatoires entourés d'en-têtes d'ouverture et de fermeture. Voir ci-dessous un exemple de clé privée :
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG+yY/6OBQoPKcx4Jv2h
vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB+MVFHTJvKjQ+eY9p
dWA3NbQusM9uf8dArm+3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB
AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa+6pO5
5bShQyQSCkxa9f2jnBorKK4+0K412TBM/SG6Zjw+DsZd6VuoZ7P027msTWQrMBxg
Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w+7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM
S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B+vee/q5edQA2OIaDgNmn
AurEtUaRAkEAn7/65w+Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq+iNWdcSE6xE
2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe
f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG
DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x
TAUq7IMYHtCHZwxkNQJBAORwE+6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5
lr++9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU=
-----END RSA PRIVATE KEY-----
Dans la plupart des cas, vous n'aurez pas besoin d'importer le code de la clé privée dans le système de fichiers du serveur, car il sera créé en arrière-plan pendant que vous générez le CSR, puis enregistré automatiquement sur le serveur. Lors de l'installation du certificat SSL, le système récupère la clé.
Vérifier si un certificat et une clé privée correspondent
Pour vérifier, vous devez imprimer les sommes de contrôle md5 et les comparer. Exécutez la commande suivante :
openssl x509 -noout -modulus -in server.crt| openssl md5
openssl rsa -noout -modulus -in server.key| openssl md5
Résoudre les problèmes SSL
Le système ne récupère pas la clé privée automatiquement
Certains systèmes n'automatisent pas la procédure de récupération d'une clé privée. De plus, si vous devez installer un certificat existant sur un autre serveur, vous ne pouvez évidemment pas vous attendre à ce qu'il récupère la clé privée. La principale difficulté ici est de trouver l'emplacement exact de la clé. La façon dont vous pouvez récupérer la clé dépend du système d'exploitation du serveur utilisé et si une interface de ligne de commande ou un panneau de contrôle d'hébergement Web d'un type particulier a été utilisé pour la génération CSR.
J'ai besoin de localiser ma clé privée précédemment installée
Si le cas est que votre certificat a déjà été installé, suivez les étapes ci-dessous qui vous aideront à localiser votre clé privée sur les systèmes d'exploitation courants.
Nginx
Vous devriez pouvoir trouver l'emplacement de la clé privée de votre serveur dans le fichier d'hôte virtuel de votre domaine.
Accédez à l'emplacement du serveur racine du site (généralement, il s'agit de /var/www/directory ) et ouvrez le fichier de configuration principal du site. Recherchez le ssl_certificate_key
directive qui fournira le chemin du fichier de la clé privée.
Si vous ne trouvez pas le ssl_certificate_key
directive, il se peut qu'il existe un fichier de configuration séparé pour les détails SSL. Recherchez quelque chose de descriptif, tel que ssl.conf .
Apache
Lors de l'utilisation de la bibliothèque OpenSSL sur Apache, la clé privée est enregistrée dans /usr/local/ssl par défaut. Exécutez openssl version -a
, une commande OpenSSL qui identifie la version d'OpenSSL que vous utilisez.
La sortie affichera le répertoire contenant la clé privée. Voir l'exemple de sortie ci-dessous :
OpenSSL 1.0.2g 1 Dec 2016
built on: reproducible build, date unspecified
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -
D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-
strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-
Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -
DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -
DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -
DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/lib/ssl"
La dernière ligne OPENSSLDIR
définit le chemin du fichier. Dans l'exemple fourni, il s'agit de l'emplacement par défaut /usr/lib/ssl
.
Si vous n'avez pas généré le CSR avec OpenSSL, vous devez trouver et accéder à votre fichier de configuration Apache principal, qui est apache2.conf
ou httpd.conf
. La directive SSLCertficateKeyFile spécifiera le chemin du fichier de la clé privée.
Windows (IIS)
Sur les serveurs exécutant Windows Internet Information Services, le système d'exploitation enregistre la clé privée dans un dossier caché, tout comme n'importe quel système d'exploitation Windows standard stocke les données système critiques.
Cependant, en exportant un .pfx fichier, vous pouvez récupérer la clé privée et le(s) certificat(s). Pour ce faire, suivez les étapes ci-dessous :
- Ouvrez la console de gestion Microsoft (MMC).
- Situé sous la racine de la console, développez les certificats (ordinateur local) arbre.
- Votre certificat se trouve soit dans le répertoire Personnel ou dossier d'hébergement Web . Trouvez le certificat que vous recherchez. Vous pouvez identifier chaque certificat par son nom commun (domaine).
- Cliquez avec le bouton droit sur le certificat que vous souhaitez exporter, puis sélectionnez Toutes les tâches> Exporter .
- Suivez l'assistant guidé pour exporter le .pfx fichier.
Vous avez ce qu'il vous faut si vous souhaitez enregistrer une sauvegarde ou installer le certificat sur un autre serveur Windows.
Si vous devez installer le certificat sur un autre serveur qui n'exécute pas Windows (par exemple, Apache), vous devez convertir le fichier .pfx et séparer les fichiers .key et .crt/.cer. Vous pouvez le faire avec OpenSSL.
Comment déplacer un certificat SSL d'un serveur Windows vers un serveur non Windows ?
Pour déplacer un certificat d'un serveur Windows vers un serveur non Windows, vous devez extraire la clé privée d'un fichier .pfx à l'aide d'OpenSSL.
- Après avoir téléchargé le fichier .pfx comme décrit dans la section ci-dessus, exécutez la commande OpenSSL suivante pour extraire la clé privée du fichier :
openssl pkcs12 -in mypfxfile.pfx -out privatekey.txt -nodes
Où monfichierpfx.pfx est la sauvegarde de vos certificats de serveur Windows.
- Cette commande créera un privatekey.txt fichier de sortie. Utilisez un éditeur de texte pour ouvrir le fichier, et vous verrez la clé privée en haut de la liste au format standard :
-----BEGIN RSA PRIVATE KEY-----
(Encrypted Text Block)
-----END RSA PRIVATE KEY-----
- Copiez la clé privée, y compris les balises "BEGIN" et "END", et collez-la dans un nouveau fichier texte. Enregistrez le fichier texte sous Your_Domain_Name.key.
Je ne trouve pas ma clé privée
Si vous ne trouvez pas la clé privée, cherchez des indices. Une chose à noter est de savoir si le serveur fournit une connexion HTTPS fonctionnelle. Si tel est le cas, la clé privée est accessible au serveur et se trouve très probablement quelque part sur le serveur.
L'étape logique serait de rechercher un .key dossier. Dans certains cas, OpenSSL stocke le fichier .key dans le même répertoire à partir duquel OpenSSL -req
la commande a été exécutée.
Si vous avez tout essayé et que vous ne trouvez toujours pas le fichier .key, il est possible que la clé soit perdue. Pas de panique, la chose intelligente à faire serait de générer un nouveau CSR et de réémettre le certificat. Assurez-vous de vous souvenir de l'emplacement de la clé privée cette fois.
Commandes OpenSSL pour la conversion des CSR
Si vous travaillez avec des serveurs Apache, les demandes de signature de certificat (CSR) et les clés sont stockées au format PEM. Mais que se passe-t-il si vous souhaitez transférer des CSR vers un serveur Tomcat ou Windows IIS ? Eh bien, vous devrez convertir un fichier PEM standard en un fichier PFX. Les commandes suivantes vous aideront à faire exactement cela.
Convertir un CSR PEM et une clé privée en PKCS12 (.pfx .p12)
Les fichiers FKCS12 sont utilisés pour exporter/importer des certificats dans Windows IIS.
openssl pkcs12 \ -inkey domain.key \ -in domain.crt \ -export -out domain.pfx
Cela prendra la clé privée et le CSR et les convertira en un seul fichier .pfx. Vous pouvez configurer une phrase secrète d'exportation, mais vous pouvez la laisser vide. Veuillez noter qu'en joignant les chaînes de caractères de certificat de bout en bout dans un seul fichier PEM, vous pouvez exporter une chaîne de certificats vers un format de fichier .pfx.
Convertir un PKCS12 en PEM CSR
openssl pkcs12 \ -in domain.pfx \ -nodes -out domain.combined.crt
Si le fichier .pfx contient une chaîne de certificats, le fichier .crt PEM aura également plusieurs éléments.
Convertir PEM en DER
DER est un format binaire généralement utilisé avec Java. Pour convertir un fichier ASCII PEM en DER, utilisez la commande OpenSSL suivante :
openssl x509 \ -in domain.crt \ -outform der -out domain.der
Convertir DER en PEM
Si vous devez convertir un fichier .der en PEM, utilisez la commande OpenSSL suivante :
openssl x509 \ -inform der -in domain.der \ -out domain.crt
Chiffrer une clé privée non chiffrée
La commande OpenSSL suivante prendra une clé privée non chiffrée et la chiffrera avec la phrase secrète que vous définissez.
openssl rsa -des3 \ -in unencrypted.key \ -out encrypted.key
Définissez la phrase de passe pour chiffrer la clé privée.
Déchiffrer une clé privée chiffrée
La commande OpenSSL suivante prendra une clé privée chiffrée et la déchiffrera.
openssl rsa \ -in encrypted.key \ -out decrypted.key
Lorsque vous y êtes invité, saisissez la phrase secrète pour déchiffrer la clé privée.