Qu'est-ce qu'un fichier Pem et en quoi diffère-t-il des autres formats de fichiers de clés générés par OpenSSL?
Je suis responsable de la maintenance de deux serveurs Debian. Chaque fois que je dois faire quoi que ce soit avec des certificats de sécurité, je Google pour les tutoriels et battre jusqu'à ce que cela fonctionne enfin.
Cependant, dans mes recherches, je rencontre souvent différents formats de fichiers (.key, .csr, .pem) mais je n'ai jamais pu trouver une bonne explication de l'objectif de chaque format de fichier.
Je me demandais si les bonnes personnes ici à ServerFault pourraient apporter des éclaircissements à ce sujet?
SSL existe depuis assez longtemps, on pourrait penser qu'il y aurait des formats de conteneurs convenus. Et vous avez raison, il y en a. Trop de normes que cela arrive. C'est donc ce que je sais, et je suis sûr que d'autres vont sonner.
- . csr - Ceci est une demande de signature de certificat. Certaines applications peuvent les générer pour les soumettre aux autorités de certification. Le format réel est PKCS10 qui est défini dans RFC 2986 . Il comprend certains/tous les détails clés du certificat demandé, tels que l'objet, l'organisation, l'état, ainsi que les clé publique du certificat à signer. Ceux-ci sont signés par l'AC et un certificat est retourné. Le certificat retourné est le public certificat (qui inclut la clé publique mais pas la clé privée), qui lui-même peut être dans deux formats.
- . pem - Défini dans les RFC 1421 à 1424 , il s'agit d'un format de conteneur qui peut inclure juste le certificat public (comme avec les installations Apache et les fichiers de certificat CA
/etc/ssl/certs), ou peut inclure une chaîne de certificats complète, y compris la clé publique, la clé privée et les certificats racine. De manière confuse, il peut également coder un CSR (par exemple tel qu'utilisé ici ) car le format PKCS10 peut être traduit en PEM. Le nom vient de Privacy Enhanced Mail (PEM) , une méthode qui a échoué pour le courrier électronique sécurisé mais le format de conteneur sur lequel il a été utilisé, est une traduction en base64 des clés x509 ASN.1. - . key - Il s'agit d'un fichier au format PEM contenant uniquement la clé privée d'un certificat spécifique et n'est qu'un nom conventionnel et non standard. Dans les installations Apache, cela réside fréquemment dans
/etc/ssl/private. Les droits sur ces fichiers sont très importants et certains programmes refuseront de charger ces certificats s'ils sont mal définis. - . pkcs12 .pfx .p12 - Initialement défini par RSA dans les Public-Key Cryptography Standards (abrégé PKCS), le " La variante 12 "a été initialement améliorée par Microsoft, puis soumise sous la forme RFC 7292 . Il s'agit d'un format de conteneur avec mot de passe qui contient des paires de certificats publics et privés. Contrairement aux fichiers .pem, ce conteneur est entièrement crypté. Openssl peut transformer cela en un fichier .pem avec des clés publiques et privées:
openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes
Quelques autres formats qui apparaissent de temps en temps:
- . der - Une façon d'encoder la syntaxe ASN.1 en binaire, un fichier .pem est juste un fichier .der encodé en Base64. OpenSSL peut les convertir en .pem (
openssl x509 -inform der -in to-convert.der -out converted.pem). Windows les considère comme des fichiers de certificats. Par défaut, Windows exportera les certificats sous forme de fichiers au format .DER avec une extension différente. Comme... - . cert .cer .crt - Un fichier au format .pem (ou rarement .der) avec une extension différente, reconnu par l'explorateur Windows comme certificat, qui n'est pas .pem.
- . p7b .keystore - Défini dans RFC 2315 comme PKCS numéro 7, il s'agit d'un format utilisé par Windows pour l'échange de certificats. Java les comprend nativement et utilise souvent
.keystorecomme extension à la place. Contrairement aux certificats de style .pem, ce format a une manière defined d'inclure les certificats de chemin de certification. - . crl - Une liste de révocation de certificats. Les autorités de certification les produisent comme moyen de désautoriser les certificats avant leur expiration. Vous pouvez parfois les télécharger à partir des sites Web de CA.
En résumé, il existe quatre façons différentes de présenter les certificats et leurs composants:
- [~ # ~] pem [~ # ~] - Régi par les RFC, il est utilisé de préférence par les logiciels open source. Il peut avoir une variété d'extensions (.pem, .key, .cer, .cert, plus)
- PKCS7 - Un standard ouvert utilisé par Java et pris en charge par Windows. Ne contient pas de clé privée.
- PKCS12 - Une norme privée Microsoft qui a ensuite été définie dans un RFC qui offre une sécurité renforcée par rapport au format PEM en texte brut. Cela peut contenir du matériel de clé privée. Il est utilisé de préférence par les systèmes Windows et peut être librement converti au format PEM grâce à OpenSL.
- [~ # ~] der [~ # ~] - Le format parent de PEM. Il est utile de le considérer comme une version binaire du fichier PEM encodé en base64. Pas couramment utilisé en dehors de Windows.
J'espère que ça aide.
PEM seul n'est pas un certificat, c'est juste un moyen de coder les données. Les certificats X.509 sont un type de données généralement codé à l'aide de PEM.
PEM est un certificat X.509 (dont la structure est définie à l'aide d'ASN.1), codé à l'aide de l'ASN.1 DER (règles de codage distinctes), puis exécuté à travers le codage Base64 et coincé entre les lignes d'ancrage en texte brut (BEGIN CERTIFICATE et END CERTIFICATE ).
Vous pouvez représenter les mêmes données à l'aide des représentations PKCS # 7 ou PKCS # 12, et l'utilitaire de ligne de commande openssl peut être utilisé pour ce faire.
Les avantages évidents de PEM sont qu'il est sûr de coller dans le corps d'un e-mail car il a des lignes d'ancrage et est propre en 7 bits.
RFC1422 contient plus de détails sur la norme PEM en ce qui concerne les clés et les certificats.
Parfois, un .crt le fichier est déjà un .pem. Voir: https://stackoverflow.com/questions/991758/openssl-pem-key