Importation de certificat SSL WAF : conversion de format JKS, PFX et PEM

Pourquoi le même certificat refuse de se téléverser deux fois

Le certificat est authentique, il n'a pas expiré, et il refuse toujours d'entrer dans le WAF — parce que le fichier lui-même a la mauvaise forme.

La plupart des plateformes de serveur web ne stockent pas les certificats sous forme de simple clé publique, clé privée et chaîne. Apache et Nginx, bâtis sur OpenSSL, s'en rapprochent le plus — ils fonctionnent déjà avec des fichiers de type CRT, KEY et CER. Tomcat, WebLogic et JBoss tournent sur Java et stockent tout dans un seul fichier Java Keystore (JKS) construit avec le Keytool du JDK. IIS de Microsoft utilise le magasin de certificats Windows et exporte en PFX. La configuration HTTPS d'un WAF veut directement les fichiers de style OpenSSL, donc tout ce qui sort d'un conteneur JKS ou PFX doit d'abord être converti — et la chaîne doit voyager avec, sinon le site reste inaccessible même avec un certificat parfaitement valide.

Voici la relation de conversion entre les trois formats, les commandes exactes pour chaque étape, comment générer une chaîne de certificats quand celle du client manque, comment distinguer un fichier de clé publique d'un fichier de CA avant de téléverser l'un ou l'autre, et quelques réponses de FAQ tirées de cas de terrain réels.

Comment les trois formats se rapportent réellement entre eux

JKS, PFX et PEM/KEY/CRT ne sont pas trois formats sans rapport — ils se situent sur une seule chaîne de conversion, et chaque téléversement de certificat WAF finit par la parcourir depuis l'une ou l'autre extrémité.

Savoir de quelle extrémité vous partez vous indique exactement combien d'étapes vous séparent d'un téléversement qui fonctionne réellement.

Les légendes du schéma restent en anglais pour la clarté technique.

Tout ce qui se trouve à gauche de PEM/KEY/CRT doit faire le trajet à travers ce schéma avant qu'un WAF ne l'accepte. La chaîne de certificats est une préoccupation distincte qui voyage aux côtés de la paire de clés publique/privée, pas un quatrième format sur la même chaîne — et c'est l'élément le plus souvent oublié.

Les étapes de conversion réelles

Deux étapes, une étape de construction de chaîne si nécessaire, et une passe de vérification avant de toucher au formulaire de téléversement.

Étape 1 — De JKS à PFX (Keytool)

Si le certificat provient d'un serveur Tomcat, WebLogic ou JBoss, il se trouve dans un seul fichier JKS et nécessite d'abord une étape via Keytool.

1. Localisez l'utilitaire Keytool du JDK sur la machine qui détient le fichier JKS — il est fourni avec toute installation standard du JDK.
2. Exécutez la commande importkeystore, en la pointant vers le fichier JKS source et en nommant le fichier PFX de destination, avec le type source défini sur JKS et le type de destination sur PKCS12.
3. Keytool demandera le mot de passe du keystore ; fournissez celui que l'administrateur du serveur du client a utilisé lors de la création du fichier JKS.

keytool -importkeystore -srckeystore D:\server.jks -destkeystore D:\server.pfx -srcstoretype JKS -deststoretype PKCS12

Étape 2 — De PFX à PEM / KEY / CRT (OpenSSL)

Que le PFX provienne de l'étape 1 ou directement d'un serveur IIS, c'est cette étape qui produit les fichiers que le WAF veut réellement.

1. Copiez le fichier PFX dans le répertoire d'installation d'OpenSSL (ou assurez-vous qu'OpenSSL est accessible depuis l'emplacement du fichier).
2. Exécutez openssl pkcs12 pour tout extraire dans un seul fichier PEM non chiffré — celui-ci contient à la fois la clé privée et le certificat.
3. Exécutez openssl rsa sur ce fichier PEM pour n'extraire que la clé privée sous forme de fichier KEY à part.
4. Exécutez openssl x509 sur le même fichier PEM pour n'extraire que le certificat public sous forme de fichier CRT à part.

openssl pkcs12 -in server.pfx -nodes -out server.pem
openssl rsa -in server.pem -out server.key
openssl x509 -in server.pem -out server.crt

Étape 3 — Construire la chaîne de certificats (si elle manque)

Lorsque le certificat provient d'une CA intermédiaire plutôt que d'une autorité racine — le cas normal — la chaîne doit elle aussi être téléversée, sinon le site reste inaccessible pour quiconque dont le navigateur ne fait pas déjà confiance à cet intermédiaire.

1. Vérifiez si le client a déjà fourni un fichier de chaîne avec le certificat. Si oui et qu'il est intact, passez directement à l'étape 4.
2. Si la chaîne manque ou a été perdue, importez le certificat de CA du site dans un outil en ligne de téléchargement de chaîne tel que la page chain_download de myssl.com.
3. Une fois le certificat de CA importé, utilisez l'outil pour générer la chaîne, puis téléchargez le fichier de chaîne obtenu pour le téléverser avec la clé publique et la clé privée.

Étape 4 — Vérifier avant de téléverser

Un fichier qui s'ouvre sans erreur n'est pas la preuve que c'est le bon fichier pour le champ dans lequel vous allez le mettre.

1. Double-cliquez sur chaque fichier de certificat pour l'ouvrir et vérifiez le chemin du certificat. Un nom de domaine dans le chemin signifie que vous regardez la clé publique — le certificat feuille réellement émis pour ce site.
2. L'absence de nom de domaine dans le chemin signifie qu'il s'agit d'un certificat de CA — utile pour la chaîne, mais il n'a pas sa place dans le champ de téléversement de la clé publique.
3. Téléversez la clé publique, la clé privée et la chaîne de certificats dans leurs champs respectifs, activez le déchiffrement HTTPS/SSL sur le site protégé, et confirmez que le site est accessible en HTTPS avant de considérer la tâche terminée.

4 pièges à l'origine de la plupart des échecs de téléversement de certificat

Les commandes de conversion elles-mêmes échouent rarement — ce sont ces quatre éléments autour d'elles qui font vraiment échouer le téléversement.

Conceptions de solutions associées

Cinq questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

Limites honnêtes de cette note

Lectures connexes