Une demande de certificat arrive dans votre boîte : un fournisseur a besoin de votre certificat client, un nouveau répartiteur de charge a besoin du certificat wildcard, un collègue a besoin du certificat de signature pour compiler une version. Le fichier demandé peut être sans danger, ou contenir la clé privée qui permet à n’importe qui de se faire passer pour votre service, et les deux voyagent souvent dans le même paquet.
Pour partager un certificat privé par un lien sécurisé en toute sécurité, déterminez d’abord quelle moitié est réellement nécessaire, emballez la clé privée pour qu’elle soit inutilisable sans mot de passe, envoyez le fichier par un lien à usage unique détruit après un seul téléchargement, et envoyez le mot de passe ailleurs. Ce guide détaille chaque étape avec les commandes.
Le certificat est public. La clé ne l’est pas.
Un certificat contient une clé publique, le sujet pour lequel il a été émis, l’émetteur et les dates de validité. Il est fait pour être distribué : chaque navigateur qui se connecte à votre site le reçoit. La clé privée est le secret distinct qui prouve que le certificat vous appartient. Qui la détient peut déchiffrer le trafic qui vous est destiné, signer en votre nom ou monter un serveur qui prétend être le vôtre.
La première question est donc de savoir si le destinataire a besoin de la clé.
| Le destinataire veut | Il lui faut | Sensible ? |
|---|---|---|
| Faire confiance à votre service ou vérifier une signature | Le certificat (et éventuellement la chaîne de l’autorité de certification) | Non |
| Installer TLS sur un serveur ou un appareil qu’il gère | Le certificat, la chaîne et la clé privée | Oui |
| Signer du code ou des documents au nom de votre organisation | Le certificat et la clé privée | Oui, très |
| S’authentifier sur un système avec un certificat client | Le certificat et la clé privée | Oui |
Si la réponse est la première ligne, envoyez le fichier .crt ou .cer comme vous voulez, et vous pouvez vous arrêter là. Tout ce qui suit concerne les lignes où la clé doit circuler.
Vérifier le contenu du fichier avant de l’envoyer
Les extensions trompent. Un .pem peut contenir un certificat, une clé ou les deux. Un .pfx ou un .p12 regroupe en général le certificat, la chaîne et la clé derrière un mot de passe. Inspectez avant d’envoyer :
# what is in this PEM?
openssl x509 -in cert.pem -noout -subject -issuer -dates
grep -c "PRIVATE KEY" cert.pem # 0 means no key inside
# what is in this PFX? (prompts for the password)
openssl pkcs12 -in bundle.pfx -info -noout
Vérifiez que le sujet correspond à ce que le destinataire a demandé et que la date d’expiration n’est pas passée. Envoyer le mauvais certificat arrive souvent ; envoyer le mauvais certificat avec sa clé est une violation de données.
Emballer la clé pour qu’elle soit inutilisable seule
Si la clé doit circuler, ne l’envoyez jamais à nu. Placez-la dans un format chiffré avec un mot de passe que vous enverrez séparément.
# bundle certificate, chain and key into a password-protected PFX
openssl pkcs12 -export -out service.pfx \
-inkey service.key -in service.crt -certfile chain.crt
# or encrypt a PEM key on its own
openssl pkey -in service.key -aes-256-cbc -out service.enc.key
Utilisez un long mot de passe généré par un gestionnaire de mots de passe. Le mot de passe est le second facteur : la personne qui obtient le fichier ne peut toujours pas l’utiliser, et celle qui obtient le mot de passe n’a rien à quoi l’appliquer.
Envoyer le fichier par un lien sécurisé à usage unique
Le lien est l’étape de livraison, et le but est qu’aucune copie du fichier ne reste ensuite dans un message.
- Vérifiez le destinataire auprès d’une source à laquelle vous faites déjà confiance : le ticket, le contact du fournisseur enregistré chez vous, un appel. Une demande de certificat venue d’une adresse inattendue mérite un coup de téléphone, pas une réponse.
- Créez un lien secret avec le fichier en pièce jointe. Depuis un compte LinkPilot connecté, ouvrez « Secret Links », choisissez « New » et joignez le PFX ou le PEM chiffré. Chaque fichier est limité à 9 Mo, des milliers de fois plus que n’importe quel paquet de clés. La pièce jointe est chiffrée dans votre navigateur avant l’envoi et supprimée au premier téléchargement.
- Réglez l’expiration sur la fenêtre réelle. Une heure si le destinataire attend, 24 heures s’il est dans un autre fuseau horaire. Le téléchargement unique est le contrôle principal ; l’expiration est le filet de sécurité pour un lien que personne n’ouvre.
- Limitez le nombre d’ouvertures à une. Si deux ingénieurs ont besoin du paquet, chacun reçoit son propre lien.
- Ajoutez une phrase de passe au lien avec un compte Pro s’il doit passer par un canal que d’autres personnes peuvent voir.
- Envoyez le lien avec une ligne de contexte : quel certificat, quel système, quand il expire.
- Envoyez le mot de passe du fichier par un autre canal. Un SMS, un appel ou un second lien secret envoyé par une autre voie. Jamais dans le même message que le lien du fichier, et jamais dans le nom du fichier.
Si la clé est un petit texte PEM, vous pouvez la coller directement dans l’outil gratuit de lien secret au lieu de joindre un fichier. Le texte est chiffré dans votre navigateur et détruit dès la première ouverture, de la même façon.
Indiquer au destinataire quoi en faire
Envoyez les notes d’installation avec le message de contexte, pas avec le mot de passe :
- Le fichier attendu, son format et le système auquel il est destiné.
- Où le stocker : le répertoire des certificats du serveur, avec des droits limités au compte de service, ou le magasin de certificats du système d’exploitation. Pas le dossier Téléchargements, pas un lecteur partagé.
- Supprimer la copie téléchargée une fois l’import fait, et ne jamais l’ajouter à un dépôt de code.
- Confirmer la réception par le nom du fichier et l’empreinte, jamais en renvoyant le fichier :
openssl x509 -in service.crt -noout -fingerprint -sha256
Ensuite
Vérifiez que le lien affiche le statut « revealed » (affiché) et que le destinataire confirme que l’empreinte correspond. Les comptes Pro voient dans l’historique d’audit l’heure exacte du téléchargement. Si le lien a été ouvert avant que le destinataire n’y arrive, ou si le fichier est parti à la mauvaise adresse, n’attendez pas la preuve d’un abus : révoquez le certificat auprès de l’autorité de certification émettrice, générez une nouvelle paire de clés, faites réémettre le certificat et remplacez-le partout où il est installé.
Notez qui a reçu quel certificat et quand. Conservez cette trace. Le fichier doit exister sur les systèmes qui en ont besoin, et nulle part entre les deux.