PEM, CER, CRT, P12 - de quoi s'agit-il?

Question

J'espère que ma question n'est pas trop générale, mais je trouve le sujet du stockage des clés asymétriques très déroutant ..

Voici comment je le comprends: En utilisant openSSL, je peux générer ma paire de clés RSA:

• openssl genrsa -out private.pem me donne un fichier PEM qui ne comprend que la clé privée
• openssl rsa -in private.pem -outform PEM -pubout -out public.pem me donne un fichier PEM qui contient une clé publique

Donc, après avoir exécuté ces 2 commandes, j'ai ma paire de clés RS-256 (est-ce le bon nom? Les clés sont à 2048 bits pour autant que je sache, alors pourquoi RS-256, pas RS-2048?).

1. Puis-je considérer les 2 fichiers que j'ai (private.PEM + public.PEM) comme un certificat?
2. Quel est le contenu des fichiers CER, CRT ou P12? Je ne trouve aucun exemple réel de ces fichiers.
3. Comment générer CER, CRT ou P12 à partir de mes 2 fichiers PEM que j'ai?
4. J'ai vu des informations selon lesquelles le fichier P12 peut être protégé par un mot de passe - quelle est la raison de protéger ce fichier avec un mot de passe - ce mot de passe doit à nouveau être stocké quelque part, déjà nous stockons le fichier P12 dans un endroit sûr où personne ne devrait avoir accès à droite?
5. J'ai vu un exemple où 1 fichier PEM comprenait des clés publiques et privées. N'y a-t-il pas une structure décidée de PEM? Puis-je y mettre les clés que je veux?
6. J'ai également vu le fichier PEM qui avait "----- BEGIN CERTIFICATE -----" et "----- END CERTIFICATE -----". Quel est ce certificat? Mes 2 fichiers PEM ont: "----- BEGIN PUBLIC KEY -----...----- END PUBLIC KEY -----" et l'autre a: "----- BEGIN RSA CLÉ PRIVÉE -----...----- FIN CLÉ PRIVÉE RSA ----- ".

Answer 1

openssl genrsa -out private.pem me donne un fichier PEM qui comprend uniquement la clé privée

Pas vraiment. En principe, RSA ne peut stocker qu'une clé privée sans publickey, mais le format RSAPrivateKey utilisé par OpenSSL (de PKCS1 aka RFCs 2313 2437 3447 8017 ) stocke les deux. Les formats utilisés pour d'autres algorithmes asymétriques (DSA, DH, ECC) ont également cette propriété, ce qui signifie que vous pouvez toujours stocker uniquement le fichier de clé privée et toujours obtenir le publickey en cas de besoin. GPG fait la même chose; les informations de clé publique sont toujours contenues dans la clé "secrète", comme on l'appelle pour des raisons historiques. OpenSSH utilise (principalement) les formats OpenSSL, donc ce n'est pas une observation utile.

openssl rsa -in private.pem -outform PEM -pubout -out public.pem me donne un fichier PEM qui contient une clé publique

Qui contient seulement la clé publique. Et est à peu près inutile car (1) il peut être régénéré à partir du fichier de clé privée et (2) la plupart des applications n'utilisent pas seulement le publickey mais plutôt un certificat.

Donc, après avoir exécuté ces 2 commandes, j'ai ma paire de clés RS-256 (est-ce le bon nom? Les clés sont à 2048 bits pour autant que je sache, alors pourquoi RS-256, pas RS-2048?).

Techniquement, c'est une paire de clés, mais comme ci-dessus, OpenSSL fusionne fondamentalement le concept de paire de clés avec une clé privée et ne distingue que publickey - qui est celui qui doit être distingué, car il est public.

Oui, les clés de chiffrement sont presque toujours mesurées en bits. Le nom de schéma RS256 (sans trait d'union) est utilisé dans JSON Web Signature (JWS) et JSON Web Token (JWT) pour signifier la signature RSA (en particulier le schéma de signature RSA RSASSA-PKCS1-v1_5 défini par PKCS1) avec SHA- 256 pour le hachage. Ceci n'est pas lié à la taille de la clé RSA et peut être utilisé avec n'importe quelle taille (implémentée); l'exemple de clé pour RS256 dans RFC7517 est 1024 bits - bien que RSA-1024 aujourd'hui n'offre pas une marge de sécurité adéquate, et il est interdit par des autorités comme NIST et CABforum (et donc la plupart des navigateurs Web) depuis plusieurs années. La signature RSA (et également le cryptage RSA) est utilisée dans de nombreuses applications autres que JWS/JWT.

Puis-je considérer les 2 fichiers que j'ai (private.PEM + public.PEM) comme un certificat?

Premièrement, une clarification: le "certificat" est un concept général utilisé dans de nombreux contextes. Pour la cryptographie, les certificats d'intérêt sont généralement des certificats à clé publique qui lient une clé publique à une identité (ou parfois à un rôle) avec certains attributs associés, et les plus courants sont de loin les certificats à clé publique définis par - X.509 , une norme créée en 1988 par le CCITT d'alors (aujourd'hui l'UIT-T) et depuis améliorée et rendue plus utile, mais pas fondamentalement différente, par de nombreux organismes de normalisation. Les normes Internet pour les certificats sont basées sur X.509 et appelées Infrastructure à clé publique utilisant X.509, abrégé PKIX. X.509, comme certaines autres normes informatiques, représente ses données en utilisant une syntaxe générique appelée Abstract Syntax Notation 1, abrégée ASN.1 .

Cela dit, NON. Un certificat de clé publique/X.509 contient un publickey, mais ce n'est pas simplement un publickey. Il contient beaucoup d'autres informations qui sont essentielles à la façon dont elles sont utilisées, bien que le publickey soit sans doute l'élément d'information le plus important. Un certificat est créé pour un publickey, normalement empaqueté comme une demande de signature de certificat aka CSR ou simplement une demande, par une entité appelée autorité de certification ou CA qui signe numériquement le certificat utilisant la clé de l'autorité de certification afin que personne d'autre ne puisse le modifier, et donc tout programme l'utilisant peut lui faire confiance. En principe, n'importe qui peut agir en tant qu'autorité de certification, et en particulier le programme de ligne de commande OpenSSL peut effectuer les opérations techniques d'une autorité de certification, comme l'émission de certificats. Cependant, dans la plupart des situations, la valeur et l'utilité d'un certificat dépendent de la fiabilité et de la fiabilité de l'autorité de certification émettrice, de sorte que les autorités de certification les plus performantes sont celles qui se sont établies comme fiables, telles que Digicert-now-including-Symantec-formerly -Verisign, Comodo, GoDaddy, etc.

Dans un cas particulier, il est possible d'avoir un certificat "auto-signé", qui est signé à l'aide de sa propre clé au lieu d'une clé d'autorité de certification. Ce certificat ne peut pas transmettre la confiance comme celle d'une vraie CA, car il n'est PAS efficacement protégé contre la substitution, mais il peut être créé même lorsque vous ne pouvez pas contacter et/ou payer une CA, et il peut généralement être traité, avec approbation ou dérogation manuelle, par des programmes conçus pour utiliser ou exiger normalement un certificat.

Quel est le contenu des fichiers CER, CRT ou P12? Je ne trouve aucun exemple réel de ces fichiers.

CER et CRT sont (les deux) couramment utilisés comme extensions pour un fichier contenant un certificat X.509, et peuvent l'être dans les deux cas en fonction du système de fichiers. Il existe deux encodages communs utilisés pour le contenu du fichier: "DER", qui est un encodage binaire (Distinguished Encoding Rules) défini par l'ASN.1; et "PEM" , qui convertit le DER binaire en base64, divisé en lignes de taille pratique et avec des lignes d'en-tête et de fin ajoutées, ce qui est plus pratique pour les personnes, en particulier pour des choses comme couper-coller. PEM est ainsi nommé car cet encodage a été initialement défini pour Privacy Enhanced (e) Mail, un schéma qui a été remplacé par d'autres technologies de messagerie et de message, mais ce format reste utilisé. Ces encodages sont très différents, mais ils contiennent exactement les mêmes informations (sauf s'ils sont endommagés), et de nombreux programmes traitant des certificats peuvent lire les deux. Les fichiers PEM écrits par OpenSSL incluent souvent des informations de "commentaire" avant l'en-tête ou après la bande-annonce; les programmes doivent ignorer cela, mais parfois ils deviennent confus et vous devez supprimer les informations superflues. Sous Windows, veillez également à NE PAS utiliser le format 'UTF-8' qui ajoute généralement un Byte Order Mark qui n'est pas visible à l'écran mais interfère avec un programme lisant le fichier.

Bien que PEM soit largement utilisé pour les certificats et que de nombreux fichiers PEM soient des certificats, sachez que PEM est également utilisé pour bien d'autres choses. Ne présumez pas qu'un fichier PEM est un certificat; vérifiez plutôt la ligne d'en-tête, qui dans ce cas indique commodément -----BEGIN CERTIFICATE----- ou parfois -----BEGIN X509 CERTIFICATE-----. Voir rfc7468 pour beaucoup plus de détails à ce sujet.

P12 est couramment utilisé pour identifier les fichiers au format PKCS12 aka PFX , ce qui est assez différent. Bien que la norme PKCS12 prenne en charge un grand nombre d'options, elle est normalement utilisée pour contenir une clé privée PLUS le certificat correspondant PLUS dans la plupart des cas un ou plusieurs certificats de `` chaîne '' ou `` intermédiaires '' qui sont nécessaires pour former une chaîne de confiance pour valider le certificat d'entité finale. Dans la pratique, les fichiers PKCS12 sont toujours binaires, bien qu'il n'y ait aucune raison technique de ne pas les coder en PEM ou de les rendre plus conviviaux.

Comment générer CER, CRT ou P12 à partir de mes 2 fichiers PEM que j'ai?

Pour obtenir un certificat, vous devez soit utiliser une autorité de certification (établie ou bricolage que vous créez), soit créer un certificat auto-signé. Il existe probablement des centaines de variantes de chacun de ces éléments en fonction du logiciel (et de l'autorité de certification le cas échéant) que vous utilisez, mais pour OpenSSL et la plupart CA la procédure habituelle est:

1. Créez un CSR en utilisant openssl req -new -key privatekey [... other options] >csr

Voir la page de manuel de req pour plus de détails. Si vous souhaitez utiliser le certificat pour SSL/TLS y compris HTTPS, définissez le 'Common Name' comme le (ou un) nom par lequel le serveur sera accédé, qui est normalement son nom complet Nom de domaine (FQDN). Si vous souhaitez utiliser le certificat pour d'autres applications, les informations d'identité nécessaires dépendent de la ou des applications.

2. Pour une vraie CA, soumettez la CSR à la CA (souvent sur un formulaire Web, ce que PEM rend pratique) avec la preuve d'identité ou autre autorisation, et éventuellement le paiement, dont ils ont besoin.

Vous devriez recevoir en retour un certificat d'entité finale nouvellement émis (contenant votre publickey et votre identité) et généralement un ou deux cert (s) contenant publickey (s) et identité (s) pour les autorités de certification intermédiaires utilisées pour créer la chaîne de confiance . Il peut s'agir de fichiers séparés (DER ou PEM) ou d'une concaténation (PEM uniquement) ou d'un cas particulier de la norme PKCS7 (SignedData sans données ni signatures uniquement), généralement appelé P7B ou P7C.

2 '. Ou faites-le vous-même. Créez une clé CA et un certificat (une seule fois), puis utilisez openssl ca ... ou openssl x509 -req -CA -CAkey ... pour lire le CSR et émettre un certificat sous votre propre autorité de certification.

Ce certificat ne sera utilisable qu'avec des systèmes et des programmes contrôlés par vous-même ou des personnes qui vous font implicitement confiance et sont techniquement capables d'installer votre certificat CA, qui est généralement un petit groupe, parfois vide . Veillez également à ne pas donner le même nom à votre certificat d'autorité de certification et à votre certificat d'entité finale, par exemple en acceptant les valeurs par défaut dans req; si vous faites cela, les certificats obtenus ne seront utilisables nulle part.

3. Utilisez le certificat, ainsi que les certificats de clé privée et de chaîne, si nécessaire. Cela mai implique de les combiner en un PKCS12, en utilisant openssl pkcs12 -export.

Comme indiqué ci-dessus, vous pouvez créer un certificat auto-signé au lieu d'un certificat émis par une autorité de certification. Remplacez les étapes 1 et 2/2 'par l'étape unique: openssl req -new -x509 -key privatekey ... >cert

Notez l'ajout de -x509 flag, et il existe de nombreuses options supplémentaires décrites dans la page de manuel. Cela a toutes les propriétés et les limites d'une autorité de certification DIY, et plus encore: vous (et/ou vos amis) ne pouvez pas simplement installer le certificat de l'autorité de certification DIY une fois, mais devez installer chaque certificat d'entité finale séparément et répéter le processus à tout moment l'un des vos certificats doivent être remplacés car ils expirent ou toute information pertinente a changé.

J'ai vu des informations selon lesquelles le fichier P12 peut être protégé par un mot de passe - quelle est la raison de protéger ce fichier avec un mot de passe - ce mot de passe doit à nouveau être stocké quelque part, déjà nous stockons le fichier P12 dans un endroit sûr où personne ne devrait avoir accès à droite?

Le mot de passe ne doit pas nécessairement être stocké; les programmes peuvent le demander si nécessaire (et le programme openssl en particulier le fait). Bien que maintenant souvent utilisé pour le stockage, PKCS12/PFX était à l'origine destiné à transférer une clé privée, avec certificat (s), d'un système à un autre, un processus qui n'est très souvent pas sécurisé. Même pour le stockage, les systèmes et les lieux que vous pensez être sécurisés s'avèrent parfois ne pas l'être, et la défense en profondeur du cryptage de la clé privée en vaut la peine. Mais dans certains cas, oui, le mot de passe est juste un peu de travail supplémentaire sans réel avantage.

J'ai vu un exemple où 1 fichier PEM comprenait des clés publiques et privées. N'y a-t-il pas une structure décidée de PEM? Puis-je y mettre les clés que je veux?

La possibilité de lire plusieurs objets et de les stocker de manière utile dans un même fichier PEM dépend du programme qui effectue la lecture. OpenSSL dans la plupart (mais pas tous) les cas peuvent gérer cela, donc l'utilisation de ces fichiers avec OpenSSL (et les programmes qui appellent la bibliothèque OpenSSL) est assez courante; d'autres programmes et bibliothèques peuvent être différents. Comme ci-dessus, le stockage du publickey en tant que tel n'est presque jamais utile. Stockage par ex. la clé privée et le certificat, ou tous les certificats de la chaîne, peuvent être utiles. Des programmes comme Apache httpd et nginx le supportent (mais ne l'exigent pas).

J'ai également vu le fichier PEM qui avait "----- BEGIN CERTIFICATE -----" et "----- END CERTIFICATE -----". Quel est ce certificat?

Voir ci-dessus pour les certificats en général. Si vous souhaitez connaître les détails d'un certificat particulier (le nom du propriétaire de la clé, appelé `` sujet ''; la clé publique; la période de validité du certificat; l'autorité de certification émettrice et son numéro de série, etc.), vous pouvez utiliser openssl x509 -text <file ou, selon votre système, plusieurs autres programmes sont généralement capables d'afficher les détails du certificat. Sous Windows pour .cer .crt vous pouvez simplement double-cliquer sur un fichier (ou le nommer dans la boîte de dialogue "Exécuter" ou une commande start dans CMD) et une boîte de dialogue apparaîtra contenant un onglet Détails.