base : https://en.wikipedia.org/wiki/PKCS / https://fr.wikipedia.org/wiki/Public_Key_Cryptographic_Standards

In cryptography, PKCS stands for « Public Key Cryptography Standards ». These are a group of public-key cryptography standards devised and published by RSA Security LLC, starting in the early 1990s. The company published the standards to promote the use of the cryptography techniques to which they had patents, such as the RSA algorithm, the Schnorr signature algorithm and several others. Though not industry standards (because the company retained control over them), some of the standards in recent years have begun to move into the « standards-track » processes of relevant standards organizations such as the IETF and the PKIX working-group.

Les PKCS (Public-Key Cryptography Standards), ou standards de cryptographie à clé publique, sont un ensemble de spécifications conçues par les laboratoires RSA en Californie. La société RSA Security est spécialisée dans les solutions de sécurité cryptographiques. Elle est également propriétaire de licences d’exploitations de plusieurs algorithmes (dont RSA avant l’expiration de son brevet le 21 septembre 2000). C’est pour ces raisons que la société a développé et promu les PKCS, permettant l’implantation des techniques de cryptographie à clé publique.

La société RSA Security n’est pas un organisme de normalisation, et pourtant, elle contrôle complètement l’élaboration et l’évolution des PKCS. L’appellation des PKCS comme standards au sens strict est donc abusive. Répondant à un réel besoin technique, les PKCS ont néanmoins été très largement adoptés par le milieu informatique. Le groupe de travail PKIX de l’IETF a depuis reformulé certains des PKCS dans des RFC, les standards Internet. L’abus de langage confondant le PKCS au lieu de la RFC correspondante est très répandu.

1- revenir sur la place de la cryprographie dans dans le cadre plus large de la cryptologie.

2- flash back sur l’histoire de l’entreprise RSA (https://fr.wikipedia.org/wiki/RSA_Security) ( y compris le leak de 2011)

3- faire une lecture croisée de ressources francophones et internationales

RSA Security

#PKCS1 se prête très bien à l’illustration d’un des « standards »

Read that f… RFC 1421 : Privacy Enhancement for Internet Electronic Mail

and follow those precious links :

https://lapo.it/asn1js
https://docs.microsoft.com/en-us/windows/win32/seccertenroll/about-encoded-length-and-value-bytes
http://javadoc.iaik.tugraz.at/iaik_jce/current/iaik/x509/PublicKeyInfo.html
https://medium.com/@bn121rajesh/understanding-rsa-public-key-70d900b1033c

# Generate 1024 bit Private key
$ openssl genrsa -out myprivate.pem 1024
# Separate the public part from the Private key file.
$ openssl rsa -in myprivate.pem -pubout > mypublic.pem
# Display the contents of private key
$ cat myprivate.pem

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDRFNU++93aEvz3cV8LSUP9ib3iUxT7SufdVXcgVFK9M3BYzvro
A1uO/parFOJABTkNhTPPP/6mjrU2CPEZJ1zIkpaSNJrrhpp/rNMO9nyLYPGs9Mfd
BiWUPmHW5mY1oD0ye4my0tEsHOlgHC8AhA8OtiHr6IY0agXmH/y5YmSWbwIDAQAB
AoGAAj/IH3pUI6FqqTrF+/gYzCRsL4AXTLC8l8vwkR93GGPyRHJNjqtik8I3WrXJ
zUiBGZ0iNouIsL/+QQuNlGiw/c5i2X3nTntREDS9xs2M0x+MWD/5qI1sn0Qk0HNP
BbDczlvO8wXNFGIHiTiPVEawoeNwhMqJDyGcbsEOZp2pLokCQQDvlMBU6dOeOP9a
jnENFSlrvzNR0nugFeoGmfq6s4Czz2QtUd9baKqBfEBSdJskwFVHgxbFA1Dc7iFu
rJkoQEeFAkEA32j9ibSVryxLvWUZngKNwo2xE+wcYDAYVBMsYC3OBU3FXhVkFD06
ZVnJsY/4bd2VdQI+bI2KV99aHutMJG2WYwJABMn2ZjweTMVa5VZ/kAFiSJMT1Yjd
i7+kY+lkB6Na6T02BWnjixI2hkwThRJrn3pwufM2201Lqn7gEDRHA3T1eQJBAKZG
1RUNo6558HEo8vUIf4vCu33RaJkqkqDYmFmJHeISrQfGMfNiUrkmJ5iRR9w1ZExu
/Bj9C281XDTQ+Z3PNnMCQQCan+pvj0OZH6o0PAMJGBBwRECPpfZ6mUjwA2YD3g61
MHjtIYmKKGmn64Qs8zQ4mNEDboQqyaov3Ij/I6c0ZQlc
-----END RSA PRIVATE KEY-----

Privacy Enhanced Mail (PEM)

Privacy Enhanced Mail (PEM) is a Base64 encoded Distinguished Encoding Rules(DER)
PEM file is human readable as it uses 64 printable characters for encoding.
It is easy to share PEM file.

Display the contents of public key PEM file

# Display the contents of public key PEM file
$ cat mypublic.pem

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRFNU++93aEvz3cV8LSUP9ib3i
UxT7SufdVXcgVFK9M3BYzvroA1uO/parFOJABTkNhTPPP/6mjrU2CPEZJ1zIkpaS
NJrrhpp/rNMO9nyLYPGs9MfdBiWUPmHW5mY1oD0ye4my0tEsHOlgHC8AhA8OtiHr
6IY0agXmH/y5YmSWbwIDAQAB
-----END PUBLIC KEY-----

Distinguished Encoding Rules (DER) format of public key

DER is encoded in Type-Length-Value (TLV) format.
DER is in binary format for PEM file and follows certain structure for public key.

# Convert PEM file to DER format using openssl rsa
$ openssl rsa -pubin -inform PEM -in mypublic.pem -outform DER -out mypublic.der
# Dump the DER file in hex format.
$ xxd -g 1 -u mypublic.der | cut -c -57
00000000: 30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
00000010: 05 00 03 81 8D 00 30 81 89 02 81 81 00 D1 14 D5
00000020: 3E FB DD DA 12 FC F7 71 5F 0B 49 43 FD 89 BD E2
00000030: 53 14 FB 4A E7 DD 55 77 20 54 52 BD 33 70 58 CE
00000040: FA E8 03 5B 8E FE 96 AB 14 E2 40 05 39 0D 85 33
00000050: CF 3F FE A6 8E B5 36 08 F1 19 27 5C C8 92 96 92
00000060: 34 9A EB 86 9A 7F AC D3 0E F6 7C 8B 60 F1 AC F4
00000070: C7 DD 06 25 94 3E 61 D6 E6 66 35 A0 3D 32 7B 89
00000080: B2 D2 D1 2C 1C E9 60 1C 2F 00 84 0F 0E B6 21 EB
00000090: E8 86 34 6A 05 E6 1F FC B9 62 64 96 6F 02 03 01
000000a0: 00 01

Structured DER file content

1:30 81 9F // Type: 30 (SEQUENCE) Length: 0x9F
2:| 30 0D // Type: 30 (SEQUENCE) Length: 0x0D
3:| | 06 09 // Type: 06 (OBJECT_IDENTIFIER) Length: 0x09
4:| | - 2A 86 48 // 9 bytes OID value. HEX encoding of
5:| | - 86 F7 0D // 1.2.840.113549.1.1.1
6:| | - 01 01 01
7:| | 05 00 // Type: 05 (NULL) Length: 0x00
8:| 03 81 8D // Type: 03 (BIT STRING) Length: 0x8D
9:| | - 00 // Number of unused bits in last content byte
10:| | 30 81 89 // Type: 30 (SEQUENCE) Length: 0x89
11:| | | 02 81 81 // Type: 02 (INTEGER) Length: 0x81
12:| | | - 00 // Leading ZERO of integer
13:| | | - D1 14 D5 3E FB DD DA 12 FC F7 71 5F 0B 49 43 FD
14:| | | - 89 BD E2 53 14 FB 4A E7 DD 55 77 20 54 52 BD 33
15:| | | - 70 58 CE FA E8 03 5B 8E FE 96 AB 14 E2 40 05 39
16:| | | - 0D 85 33 CF 3F FE A6 8E B5 36 08 F1 19 27 5C C8
17:| | | - 92 96 92 34 9A EB 86 9A 7F AC D3 0E F6 7C 8B 60
18:| | | - F1 AC F4 C7 DD 06 25 94 3E 61 D6 E6 66 35 A0 3D
19:| | | - 32 7B 89 B2 D2 D1 2C 1C E9 60 1C 2F 00 84 0F 0E
20:| | | - B6 21 EB E8 86 34 6A 05 E6 1F FC B9 62 64 96 6F
21:| | | 02 03 // Type: 02 (INTEGER) Length: 0x3
22:| | | - 01 00 01 // Public Exponent. Hex for 65537

DER file contains Object Identifier, Modulus and Public exponent in HEX format.

Lines 4, 5, 6 is the HEX encoding of OID.
Lines 13 to 20 is the modulus (n).
Line 22 is the public exponent.

You can also have a look at Lapo ASN.1 javascript decoder :

Javascript ASN.1 decoder

Modulus and Public exponent from public key using openssl

# Get Modulus and Public exponent from public PEM file
$ openssl rsa -pubin -inform PEM -text -noout < mypublic.pem

Public-Key: (1024 bit)
Modulus:
00:d1:14:d5:3e:fb:dd:da:12:fc:f7:71:5f:0b:49:
43:fd:89:bd:e2:53:14:fb:4a:e7:dd:55:77:20:54:
52:bd:33:70:58:ce:fa:e8:03:5b:8e:fe:96:ab:14:
e2:40:05:39:0d:85:33:cf:3f:fe:a6:8e:b5:36:08:
f1:19:27:5c:c8:92:96:92:34:9a:eb:86:9a:7f:ac:
d3:0e:f6:7c:8b:60:f1:ac:f4:c7:dd:06:25:94:3e:
61:d6:e6:66:35:a0:3d:32:7b:89:b2:d2:d1:2c:1c:
e9:60:1c:2f:00:84:0f:0e:b6:21:eb:e8:86:34:6a:
05:e6:1f:fc:b9:62:64:96:6f
Exponent: 65537 (0x10001)

Exponent and modulus printed by openssl rsa matches with the Public exponent and modulus from DER file content.

More information on recommended syntax for interchanging RSA public keys between implementations is given in Appendix A.1.1 of rfc3447 ( PKCS#1);

RSA key representation

Object Identifier

OID describes the object. It is a series of nodes separated by period.

OID Value: 1.2.840.113549.1.1.1

OID description: Identifier for RSA encryption for use with Public Key Cryptosystem One defined by RSA Inc.

OID Encoding rules:

1 – The first two nodes of the OID are encoded onto a single byte. The first node is multiplied by the decimal 40 and the result is added to the value of the second node.
2 – Node values less than or equal to 127 are encoded on one byte.
3 – Node values greater than or equal to 128 are encoded on multiple bytes. Bit 7 of all bytes except the rightmost byte is set to one. Bits 0 through 6 of each byte contains the encoded value.

OID Encoding Example © Rajesh Bondugula

Representing length in ASN.1 encoding

If number of value bytes is < 128 (0x80) then length is represented in 1 byte. In this case most significant bit is 0. (Ex: Line 2: 0x81=10000001 => 1 octet, Line 3 in structured DER content above)

If number of value bytes is >= 128 (0x80) then length is represented in multiple bytes. Most significant bit (bit 7) of first byte is 1 indicating multiple byte length. Bits 0–6 represent number of subsequent bytes for length. (Ex:  Line 1: 0x82=10000010 => 2 octets, Line 4 in structured DER content above)

References

DER encoding of ASN.1 types (MSDN)
Public Key Info structure (Java doc)

[ajout de août 2021 suite plaintes]

– Mais du coup … tu n’as pas répondu  la question ?
[lm] C’est pas faux, mais si tu révises le fonctionnement de l’encodage base 64, à partir d’un contenu DER qui commence toujours par la même syntaxe:

xxd -r -p <<<30819F | base64
MIGf

Bon ok, j’ai vraiment eu du mal à prendre le train en marche, passionné que j’étais par l’élection de miss France.

Tout à commencé par le message de l’ANSSI annonçant la suppression de l’une des branches de son IGC, puis j’ai aperçu le communiqué de Google et le flot de commentaires plus ou moins éclairés sur ma TL avant de terminer par les articles des « Gala » de l’informatique (JdN, 01, ZDNet, …) ou pire, la presse nationale (Le Monde).

Heureusement, Olivier Laurelli nous a pondu une bonne synthèse sur reflets.info qui m’a permis de me remettre à niveau.

Du coup ce matin, de très bonne heure, j’ai attrapé mes crayons de couleurs pour essayer de griffonner ce que j’avais cru comprendre du bazar. Cela donne la synthèse suivante, qui confirme très bien les doutes émis par mes profs de dessin du collège sur mes talents de graphistes 😉

ANSSInTheMiddle caught by Google

 J’ai aussi tenté de trouver un nom rigolo à l’image ainsi créée, mais une fois encore j’ai pu évaluer le chemin à parcourir pour rattraper Laurent Baffie ou comment s’appelle-t-il déjà celui qui essaie toujours de se faire passer pour plus beauf qu’il n’est réellement pour que son public se sente à l’aise à ses côtés ? Ah oui, Bigard (celui qui à un « e » près ne laissera pas de trace dans l’histoire).

Donc, traduction du gribouillis et explications de la situation:

Tout le monde sait aujourd’hui à Bercy comme au ministère des Finances ou chez ma mère que la messagerie c’est le diable.

C’est en effet par la messagerie que toutes les tares des SI se propagent et par ces mêmes tuyaux que tout fuite … d’autant plus si les systèmes utilisés s’appellent GMail ou Yahoo.

Pour tenter d’ y remédier, quelqu’un de de  la Direction Générale du Trésor à la bonne idée d’écouter les échanges entre ses utilisateurs et Google (en ayant apparemment pris soin de prévenir lesdits utilisateurs). Bref, jusque là un grand classique. Pour cela,  il insère donc un équipement de sécurité interne (boitier Netasq) sur le réseau dans lequel il place un certificat émis par l’une des branches de l’autorité de certification de l’ANSSI. Pour la très grande majorité des utilisateurs qui croient communiquer directement avec Google, c’est complètement transparent. L’espion/indiscret/contrôleur réalise un MITM classique.

Un quoi ?

Un « Man In The Middle » les amis … difficilement traduisible en France où on continue de s’arracher les cheveux entre l’Homme du milieu (typé pègre, Cosa Nostra, marseillais, politique …) ou l’Homme au milieu (plus orienté Marc Dorcel).

La page Wikipedia en français sur le sujet est d’ailleurs remarquablement légère …

Placé entre l’utilisateur et Goggle, il se fait passer pour l’un ou l’autre aux yeux de ces derniers pouvant ainsi observer leurs échanges.

Jusqu’au moment où Google dénonce l’imposture 😉 Alors là…, Google jouant les vierges effarouchées, ça vaut le meilleur de Jean Roucas !

Dès que la nouvelle apparaît sur la toile, quelques grand défenseurs des libertés individuelles peu inspirés (merci pour nous, il y en a qui font un réel bon boulot) crient au scandale : « L’ANSSI se lance dans le surveillance style NSA/Prism » et autres délires paranoïaques. Bahhh non les gars, le besoin n’est pas là, c’est quand on aura découvert que Orange fait la même chose qu’il faudra crier 😉

Jean-Pierre Pernaut n’ayant pas été alerté, le soufflet semble retomber… mais peu se posent aujourd’hui la bonne question : comprendre comment Google a été informé de tels agissements et pourquoi a-t-il dénoncé aussi rapidement publiquement le stratagème qui devait forcément gêner son business.

Des pistes de réponse à la première question :

– l’utilisation de Chrome qui enverrait (parfois à l’insu de notre plein gré) à Google des informations relatives aux certificats utilisés (et peut-être d’autres),

– des contrôles OSCP depuis le poste client pour vérifier en  ligne la non répudiation d’un certificat,

– l’information par des utilisateurs de la DGT,

– des plugins variés navigateurs remontant de l’info à Google…

Bref, pour l’instant on ne sait pas ! On confirme tout juste que Google en sait, pour sa part, vraiment beaucoup sur nos moindre faits et gestes… y compris les pseudo-boulettes avouées par l’ANSSI.

SSL/TLS à La Cantine

J’ai assisté le  20 septembre 2013 de 19h00 à 23h00 avec une cinquantaine de personnes à la conférence donnée par Benjamin Sonntag (@vincib).

Je vous en relate l’ambiance ci-dessous :

J’arrive à18H45, un peu stressé et affamé. Je ne connais pas l’endroit et suis un peu intimidé par les pointures que je vais croiser.

Vu que je suis l’un des seuls en costard, les gus doivent penser que je suis de la NSA ou du service d’ordre. L’assemblée est en effet largement bigarrée, de 18 à 78 ans et rafraichie à la bière. Je n’ose pas aller au comptoir en commander une, de peur de perdre ma place privilégiée plein axe au troisième rang. On est loin de l’ambiance feutrée proutprout du salon « DSI  de l’année ». Ici, c’est cool attitude et coupe de cheveux hors standard. Les auditeurs arborent majoritairement le look hacktiviste assorti de l’ordinateur portable recouvert de stickers à l’effigie des grands rendez-vous du hacking. A côté d’eux, le moindre startuper de la Silicon Valley ferait BCBG coincé !

Je reconnais dans l’assemblée quelques visages révélés par Twitter.  Je remarque qu’il y a même quelques sujets féminins, un spectateur dont l’allure est quelque part entre clodo, Richard Stallman et Léo Ferré, un sosie du frère du père noël, quelques tronches de vieux hippies, une poignée d’étudiants en école d’informatique qui ont dû arrêter toute activité sportive en CE2, un couple de cinquantenaires visiblement égaré, quelques consultants encostumés, un extra-terrestre iroquois … et Benjamin Sonntag. On reconnait dans le regard de chacun d’eux la petite lueur de la passion.  On ne vient pas un vendredi soir après le boulot à la Cantine comme on va assister au dernier Workshop Microsoft Winbouse2013 ou au talk branché  Apple merde-I-5f pour se la couler douce une demi-journée.

Affairé à ses derniers préparatifs, Benjamin est serein et déterminé. On devine la maitrise du sujet à peine perturbée par les couacs du tcpDump.

Après avoir salué l’assistance, il nous embarque pour près de trois heures dans l’univers de TLS, des certificats et autorités de certification, des courbes elliptiques et de Diffie-Hellman… mais aussi dans le monde de la sécurité au sens large et du respect de la vie privée. Quelques centaines de minutes de discours posé, précis, argumenté, illustré d’exemples, de démos et d’anecdotes. Ca s’écoute comme une belle histoire… J’aurais pu venir avec ma mère. Ressurgissent régulièrement les références à son quotidien et ses activités au sein de La Quadrature de Net. Transparait le côté humaniste du personnage.

Dans l’assistance ça ne bronche pas, le bagage technique moyen étant élevé, on va pouvoir aborder une bonne partie de la technicité du problème sans lassitude. Je ne résumerai pas le contenu formel de la présentation, dont on retrouvera bientôt l’intégralité ici sur le web, de peur de le dénaturer et de ne pas en reproduire l’exhaustivité.

Reprenant Bruce Schneier et Snowden (Prix Nobel de la paix 2025 ?), Benjamin insiste largement sur le fait que la crypto nous apporte le niveau de sécurité et de confidentialité que l’on se doit d’attendre d’elle. Le chiffrement, malgré la fragilité du modèle de confiance fourni par les autorités de certification commerciales et les difficultés de protéger les sacro-saintes clefs privées est sûr ;  Même s’il est techniquement possible de casser du RSA 1024 pour quelques millions de dollars, le maillon faible est bien ailleurs … à la fois dans la faiblesse, l’inconsistance, et les motivations inavouables toutes malheureusement humaines. Ce sont celles-ci qui font qu’il existe aujourd’hui des implémentations de protocoles sécurisés pourries utilisant des algorithmes cassés ou conçus avec des portes dérobées ou pire, car de manière généralisée, fonctionnant sur des plateformes matérielles pour le moins dangereusement hermétiques.

Alors, pour se protéger, comment faire ?

Ne pas avoir une confiance aveugle envers les marchands de solutions de sécurité qui vous vantent/vendent leur « cryptage » propriétaire inviolable.  Faire confiance, avec un œil critique, à la crypto dont le code source est ouvert et auditable.  Comprendre les mécanismes mis en œuvre afin de vérifier que votre entreprise ne vous offre aussi gentiment que secrètement un joli certificat de chez Bluecoat qui lui permet de déchiffrer tous vos échange HTTPS. Etre en mesure d’expliquer à tout un chacun les objectifs de la sécurisation des échanges dans le  respect de la vie privée afin de ne pas tomber, sans s’en rendre compte dans le piège des Google, Paypal et consorts ou de se faire pirater ses comptes par le premier script kiddy en omettant le « s » de HTTPS.

@LauMarot

Toute la conf est disponible en vidéo et les diapositives du support sont téléchargeables ici. Du vraiment bon boulot !

SafeNet Luna SA 1U

Bonne introduction à la présentation des HSM Luna SA : http://geekcredential.wordpress.com/2012/07/02/luna-sa-hsm-concepts/comment-page-1/#comment-131

Fête de la musique dans le 44

Mince, j’ai loupé DJ Mosey au festiZad, le dernier apéro Facebouse à Notre Dame de la Glande … parait qu’il y avait un max de pervers pour pister les p’tites fugueuses 🙂

certificat et pkcs12

Comme le présente RSA : Personal Information Exchange Syntax Standard specifies a portable format for storing or transporting a user’s private keys, certificates, miscellaneous secrets, etc.

-> Télécharger le standard au format PDF

Le format PKCS#12 est utilisé pour stocker les clés privées et des certificats dans un seul fichier chiffré : par exemple Java l’utilise pour ses keystores.

L’extension de fichier pour les fichiers PKCS#12 est habituellement « .p12« , mais on les rencontre aussi en « .pfx« . Ces fichiers peuvent être créés, analysés et lus par exemple avec la sous-commande pkcs12 de OpenSSL.

Signature numérique

1. Calcul de l’empreinte (on dit aussi hash, ou parfois condensat/condensé ) des données à signer.
2. Chiffrement de l’empreinte à l’aide de la clé privée de l’émetteur dont lui seul dispose et qu’il conserve précieusement. Le résultat de ces deux action produit la signature des données.

=> Envoi des données en clair et de la signature au destinataire (avec éventuellement le certificat de l’émetteur contenant sa clef publique)

3. Déchiffrement de la signature avec la clé publique de l’émetteur qui est une information librement diffusée. Cela permet de retrouver l’empreinte associée aux données signées.
4. Calcul de l’empreinte des données signées. On vérifie que cette empreinte correspond à la précédente, auquel cas la signature est valide : les données sont donc intègres et l’identité de l’expéditeur est vérifiée.

Petite précision matinale suite à la lecture d’articles employant un vocabulaire approximatifs: on ne crypte pas, on CHIFFRE !

On chiffre avec une clé de chiffrement pour obtenir un cryptogramme.
Lorsque l’on a un cryptogramme à lire, deux possibilités s’offrent à nous… Soit on le déchiffre en employant la clé de chiffrement, soit on n’a pas la clé de chiffrement et dans ce cas, on le décrypte (on casse le code).
Cette explication étant donnée, on comprend que le terme –crypter– reviendrait à chiffrer sans clé … ce qui est impossible. Donc crypter n’existe pas (où alors peut être mettre dans une crypte mais cela n’a plus grand chose à voir avec notre sujet :-).

Voilà c’est dit, bonne journée à Bob et Alice !
Mais il y a un terme pire encore … : encrypter (une mauvaise traduction du mot -encryption- in english qui doit être traduit par -chiffrer-). Plus de détails sur wikipedia.

Vous avez entendu parler de Firesheep, l’extension pour Firefox qui permet de collecter toutes les mots de passe de votre entourage sur les réseaux WIFI ouverts ?

Vous n’avez pas envie que votre site et ses utilisateurs en soient les prochaines victimes ? Une solution simple : sécuriser votre site avec SSL/TLS/HTTPs.

Connectez-vous en tant que root et allez dans le répertoire de configuration de votre serveur Apache2 (généralement /etc/apache2 mais on peut évidemment en choisir un autre) et créez un répertoire appelé ssl. Vous vous placerez dans ce répertoire afin que les clés et les certificats soient créés à l’intérieur avant d’effectuer les opérations suivantes.

openssl genrsa 1024 > servwiki.key

Generating RSA private key, 1024 bit long modulus
 ..................++++++
 .................................................................++++++
 e is 65537 (0x10001)

less servwiki.key
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDQG9wvnuLC4aqzaJCAWGA1AxFzg00hjPObhq1mukzsGyuuWBFG
vj/k9vFNYX55DHctb/4cXtsZRWWvgcjtYnCVwRu+DAjFsk//kOMfhplmiv9xQ+ZL
8w/Xrnm8JWdSS+S4LCMnsuIiQtLbhMrQnUV02hAtbIZiSM3k6OjShEZhDQIDAQAB
AoGAHi0cBW+1k+qjFPbBlUq7UJSMUEKmyYmlvVSPCklTZB0gfVxZzPdDTpEcNks/
yo+rLFSD9Vsvy/9LGmLoXruadWlK67PCUnpM5/oRRGgy8t73YKrxflAU5Gtymjvc
ZCf0CAs6wBft3yLU31Qc4WqVM2vTyUH76jebVhxEw8k63OUCQQD/1OmAXV+TxBPG
ZTPFbzUeAE5rQqqOW4aoMNvM61Yn/19h6SzY2MfSQvF1BNns/efCRrqOMeyvPWUG
g1okfogTAkEA0D7pDf/D2Yu5msbOAGF4QBU1erLzpi/s6Rv6VEPYCGnHQlo3jbg9
FZbjHJ4UcYyYaA8jIrkY+FIJM88YlGbWXwJBAILEdvJ5R/CFCkKf2j2yIWmLaIol
En8fw43XI5L0PB7Hxx6KDLVu4XzVYQyahTZBdqR0eMlUNZJBhJE2tO3wi2cCQQCp
JkCFd3es0BrNxqfzlThozRFofcz88za7TldydL0YcFtC4Sb4vWsYizwktZ6jcPEm
rQz8Gl9W7MO+ynwLptB/AkEA1tsnFXoYzI71enmTdugGxbv0RqAd5iQpDYQkDSdn
2LImp/3YnXNJ9qpY91j87tKthh/Oetu6SHlmLg1LOYNIdw==
-----END RSA PRIVATE KEY-----

openssl req -new -key servwiki.key > servwiki.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:BRETAGNE
Locality Name (eg, city) []:Sulniac
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Lostihuel Braz
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:www.laurentmarot.fr
Email Address []:

less servwiki.csr

-----BEGIN CERTIFICATE REQUEST-----
MIIBsTCCARoCAQAwcTELMAkGA1UEBhMCRlIxFTATBgNVBAgTDENvcnNlIGR1IFN1
ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UEChMDTExCMREwDwYDVQQLEwhCVFMg
SU5GTzEYMBYGA1UEAxMPcHJvZi5idHNpbmZvLmZyMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDSUagxPSv3LtgDV5sygt12kSbN/NWP0QUiPlksOkF2NkPfwW/m
f55dD1hSndlOM/5kLbSBo5ieE3TgikF0IktjBWm5xSqewM5QDYzXFt031DrPX63F
vo+tCKTQoVItdEuJPMahVsXnDyYHeUURRWLWwc0BzEgFZGGw7wiMF6wt5QIDAQAB
oAAwDQYJKoZIhvcNAQEEBQADgYEAwwI4UvkfhBvyRrUXtjrLfZXLxZlF9o+URmHJ
ysvrLKfesVBEzdA9mqk1OwIwLfe8Fw2fhip2LGqvcCPxDMoIE/0cDkqGRg9iKp7D
DMuy69lPTEB6UtpVKO/1eage0oug6VqdfGAYMMSGyWFuO9FE4UE6HspVodb20wGV
4H8qZuk=
-----END CERTIFICATE REQUEST-----

openssl genrsa -des3 1024 > ca.key

openssl req -new -x509 -days 365 -key ca.key > ca.crt

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]: BRETAGNE
Locality Name (eg, city) []:SULNIAC
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Lostihuel Braz
Organizational Unit Name (eg, section) []:IT
Common Name (eg, YOUR name) []:myCA
Email Address []:

openssl x509 -req -in servwiki.csr -out servwiki.crt -CA ca.crt -CAkey ca.key\
-CAcreateserial -CAserial ca.srl

Signature ok
subject=/C=FR/ST=BRETAGNE/L=Sulniac/O=Lostihuel Braz/OU=IT/CN=www.laurentmarot.fr
Getting CA Private Key
Enter pass phrase for ca.key:

less servwiki.crt

-----BEGIN CERTIFICATE-----
MIICVDCCAb0CAQEwDQYJKoZIhvcNAQEEBQAwdDELMAkGA1UEBhMCRlIxFTATBgNV
BAgTDENvcnNlIGR1IFN1ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UEChMDTExC
MREwDwYDVQQLEwhCVFMgSU5GTzEbMBkGA1UEAxMSc2VydmV1ci5idHNpbmZvLmZy
MB4XDTA0MDIwODE2MjQyNloXDTA0MDMwOTE2MjQyNlowcTELMAkGA1UEBhMCRlIx
FTATBgNVBAgTDENvcnNlIGR1IFN1ZDEQMA4GA1UEBxMHQWphY2NpbzEMMAoGA1UE
ChMDTExCMREwDwYDVQQLEwhCVFMgSU5GTzEYMBYGA1UEAxMPcHJvZi5idHNpbmZv
LmZyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDSUagxPSv3LtgDV5sygt12
kSbN/NWP0QUiPlksOkF2NkPfwW/mf55dD1hSndlOM/5kLbSBo5ieE3TgikF0Iktj
BWm5xSqewM5QDYzXFt031DrPX63Fvo+tCKTQoVItdEuJPMahVsXnDyYHeUURRWLW
wc0BzEgFZGGw7wiMF6wt5QIDAQABMA0GCSqGSIb3DQEBBAUAA4GBALD640iwKPMf
pqdYtfvmLnA7CiEuao60i/pzVJE2LIXXXbwYjNAM+7Lov+dFT+b5FcOUGqLymSG3
kSK6OOauBHItgiGI7C87u4EJaHDvGIUxHxQQGsUM0SCIIVGK7Lwm+8e9I2X0G2GP
9t/rrbdGzXXOCl3up99naL5XAzCIp6r5
-----END CERTIFICATE-----

Vous pouvez alors passer à la configuration d’Apache2 pour supporter SSL.

1. ^[1]fichier servwiki.key↩
2. ^[2]Certificate Signing Request↩
3. ^[3]mot de passe long qui peut même contenir des espaces↩
4. ^[4]Certificate Autority↩