(mis à jour le 29 déc. 2015, puis 6 sept. 2016)
Le logiciel libre i-Parapheur expose une librairie de Web-Services SOAP, à l'usage d'application métier tierces.
Les spécifications de ce contrat de services sont librement disponibles sur la Forge ADULLACT.net : fichier WSDL + descriptif PDF. Voir plus bas...

Ce dialogue applicatif se fait obligatoirement au travers d'une connexion sécurisée HTTPS s'appuyant sur TLS/SSL, de type "2WAY authentication + BASIC" : autrement dit, il s'agit d'une authentification mutuelle par certificats (autrefois connue sous l'acronyme MCA, ou le vocable plus commun "Mutual Authentication") complétée par la présentation d'un couple "login + mot de passe).
L'accès à i-Parapheur passe donc par la mise en place maîtrisée de certificats électroniques d'authentification.

 

Le but de ce  billet : présenter et expliquer ce procédé le plus clairement possible, pour que la mise en place d'un connecteur métier à i-Parapheur ne laisse aucune ambiguïté technique.
Pré-requis : un peu de culture d'informatique moderne, notamment sur la notion de contrat WSDL, ainsi que la génération et gestion de certificat X.509/TLS. Cette prose technique apporte quelques clés, mais ne prétend pas remplacer un cours d'informatique, ni quelques allers-retours sur Bing/Google/Qwant ou Wikipedia.
Remarque: On parle aujourd'hui de sécurisation TLS ou TLS/SSL plutôt que "SSL" tout simplement. En effet TLS est une évolution technologique de SSLv3, mais le protocole historique SSL a été banni en 2014 suite à la faille "Poodle". 

Sommaire de cet article :

  • De quoi a-t-on besoin pour se connecter à i-Parapheur avec les Web-Services?
  • Généralités sur les keystore/truststore
  • Quels formats : JKS/PEM/P12/... je m'y perds!
  • Test de connexion : outils

Bon à savoir pour commencer, dans les dialogues entre i-Parapheur et une application tierce via ce contrat WSDL: i-Parapheur agit en serveur pur , il répond à des requêtes de l'application tierce. Donc l'application tierce (bureautique, métier quelconque) est à considérer comme un client qui exploite une API. Toujours.

 

De quoi a-t-on besoin pour se connecter à i-Parapheur avec les Web-Services? :

L'établissement de la communication SOAP web-services avec i-Parapheur se fait par "2WAY" + BASIC : authentification mutuelle par certificats puis identifiant/mdp. (Attention à ne pas confondre "two-way authentication" avec "two-factor authentication", qui n'a absolument rien à voir.)

Concrètement, le client et le serveur "échangent" des informations sur leurs identités respectives, les vérifient, avant de construire une session chiffrée de confiance. Seulement après le client présente un identifiant/mdp applicatif permettant d'interagir.

Voici les éléments nécessaires :

  • URL d'accès aux web-services, de la forme:
    https://secure-iparapheur.mon-domaine.fr/ws-iparapheur
    ou https://secure-iparapheur.mon-domaine.fr/ws-iparapheur-no-mtom (le choix de l'un ou l'autre dépend du choix d'implémentation de l'éditeur: SOAP-MTOM ou SOAP-XOP)
  • un KeyStore (voir ci-dessous) éventuellement protégé par un mot de passe
  • un TrustStore (voir ci-dessous) éventuellement protégé par un autre mot de passe
  • un identifiant de compte utilisateur dédié pour l'application métier (pré-existant dans i-Parapheur)
  • un mot de passe , pour le compte utilisateur métier

 

Généralités sur les keystore/truststore:

Le schéma ci-dessous illustre la cinématique de négociation d'une session TLS/SSL selon le mode d'Authentification mutuelle. C'est une cinématique dans laquelle les deux pairs s'authentifient l'un l'autre: le client authentifie le serveur, et vice-versa. Ainsi, chaque pair a l'assurance de dialoguer avec une entité légitime dite "de confiance", en minimisant fortement le risque de fraude (usurpation).

Sans trop rentrer dans les détails de la séquence de négociation TLS (appelée phase de "handshake"), ça veut dire ceci :

  1. Le client (l'application qui cherche à discuter) requête le serveur (i-Parapheur) sur une URL de la forme https://secure-iparapheur.mon-domaine.fr/ws-iparapheur , avec un message "ClientHello".
  2. Le serveur répond poliment "ServerHello", puis dans un message "Certificate" donne au client son identité numérique (en gros: la partie publique de son certificat HTTPS) pour que le client soit en confiance.
    Il en profite pour envoyer aussi un message "CertificateRequest" pour signifier au client qu'il requiert son identité en retour, et conclut par "ServerHelloDone".
  3. Le client, à réception du certificat HTTPS serveur, vérifie (normalement) sa qualité: est-il fourni par une AC (Autorité de Certification) de confiance? est-il expiré? est-il révoqué? Correspond-il au serveur que je souhaite atteindre? Les bonnes pratiques de sécurité imposent cela : c'est pourquoi le client a besoin d'un "truststore" (magasin de confiance) qui stocke sa politique de sécurité, relative au(x) service(s) qu'il souhaite exploiter.
  4. Une fois la vérification faite (avec succès, sinon la négociation s'arrête là), le client se doit de fournir son certificat (appelé identité numérique d'authentification client) pour que le serveur soit à son tour également en confiance: ce qu'il fait avec un message "Certificate". C'est pourquoi le client a besoin d'un autre magasin de clés (keystore) pour stocker son identité métier d'authentification client (certificat + clé privée).
  5. Naturellement, à réception le serveur vérifie la qualité du certificat électronique fourni, et en particulier s'il est compatible avec sa politique de sécurité (AC de confiance connue, plus autres critères à discrétion de l'exploitant).
  6. D'autres joyeusetés cryptographiques se passent pour achever la négociation (construction et partage d'une clé de chiffrement symétrique), et permettre une session d'échange chiffré.

Vu de l'application cliente, ce mécanisme impose donc la présence de :

  1. keystore: afin de présenter un certificat d'authentification client compatible avec la politique de sécurité du serveur i-Parapheur.
    C'est le fameux keystore: une structure de données contenant un certificat X.509 + sa clé privée.
    Le certificat doit être issu d'une Autorité de Certification (AC) référencée par la politique de sécurité des AC de confiance de i-Parapheur : par défaut, cette politique comprend toutes les AC qualifiées RGS ainsi que les AC d'Adullact.
    Autrement dit, tout certificat d'authentification client acquis auprès d'un opérateur qualifié RGS va convenir.
    De même, un keystore généré à partir de la PKI Adullact (pki.adullact.org) est normalement accepté par les installations par défaut de i-Parapheur.
    PS: Ne pas utiliser le certificat SSL serveur du i-Parapheur (avec sa clé privée), pour d'évidentes raisons de sécurité, contrairement à des croyances parfois tenaces chez certains éditeurs tiers. Je me tiens à la disposition de quiconque pour toute tentative d'argumentaire contradictoire.

  2. truststore: pour  vérifier et valider que le certificat SSL serveur du i-Parapheur est "de confiance".
    C'est le fameux truststore: il contient la plupart du temps la chaîne de certification de l'AC qui a fourni le certificat serveur de i-Parapheur, parfois complété par le certificat serveur lui-même.
    Ce truststore est donc directement dépendant du choix du fournisseur de certificat TLS/SSL serveur utilisé pour sécuriser le i-Parapheur de l'organisme (de la collectivité). Autrement dit, il est spécifique au choix de sécurisation HTTPS par l'exploitant/hébergeur du i-Parapheur:

    • Si le i-Parapheur est protégé avec un certificat fourni par l'AC "Adullact G3 SERVEURS", le truststore doit contenir la chaîne d'AC G3. Logique.
    • Si le certificat a été acheté chez Thawte, GlobalSign, ou ailleurs (chambersign RGS SSL, etc.), il faut la chaîne d'AC qui va bien du fournisseur en question...

    Astuce: Pour savoir de quelle autorité de certification provient le certificat HTTPS, il suffit d'une tentative de connexion depuis son navigateur préféré sur l'URL web-services : le navigateur est capable de montrer les détails du certificat SSL serveur présenté. Testé avec succès depuis Firefox, voir ce qu'affiche le petit cadenas ("plus d'informations" sur la connexion sécurisée, puis onglet "Sécurité" et bouton "Afficher le certificat"...). Une autre astuce en ligne de commande est proposée en toute fin de l'article.

 

Quel format : JKS, CER, P12, PEM ?... Je m'y perds !!

Les certificats X.509v3, il y a des tas de façons de les stocker. Sur la question du type/format de fichier conteneur de certificats X.509 à utiliser dans l'application cliente : ça dépend directement de la technologie de développement de l'application métier (cliente de i-Parapheur), de la capacité de cette application cliente à lire/interpréter/exploiter le keystore et/ou truststore présenté.

Il y a pléthore de formats pour encapsuler un keystore (ou un truststore), parmi les plus usités: PKCS12, JKS, BKS, PEM, P7B....
Il convient de se rapprocher de l'éditeur pour connaître le format de keystore et truststore attendus.
Chaque éditeur est libre de choisir le type de conteneur de certificat qui lui convient le mieux, c'est d'ailleurs souvent orienté par ses propres choix technologiques de développement logiciel. Cela n'a aucun impact sur la capacité à établir une connexion sécurisée.

Pour un keystore d'authentification client, on rencontrera tous les conteneurs aptes à recevoir une clé privée: PKCS12, JKS, PEM

Pour un truststore, les formats les plus couramment usités: JKS, PEM (fichiers à extension .pem, .cer ou .crt).

A la question: «j'ai un certificat format XXX, mais l'application me réclame le format YYY, help?» → Internet est ton ami, une simple recherche "comment transformer un certificat XXX vers YYY" devrait orienter favorablement la résolution du problème.
Pas la peine de consommer des crédits au support technique de votre fournisseur, n'est-ce pas?

 

Test de connexion Web-Services - outils :

Il est possible de qualifier la disponibilité et la bonne santé du point d'entrée Web-Services de i-Parapheur avec l'outil SoapUI : il s'agit d'une application permettant le test de web-service, la version community est publiée sous licence LGPL. Technologiquement neutre, c'est un parfait "juge de paix" en cas de doute sur la configuration/disponibilité des Web-Services d'une instance i-Parapheur.

Autre possibilité: disponible sur la forge ADULLACT, le projet getDocParapheur est un mini-client SOAP-MTOM dédié à i-Parapheur, logiciel libre écrit en langage Java, qui permet également de vérifier la disponibilité des WebServices (getdocparapheur en usage "ping").

NB: Ces deux outils digèrent du certificat au format JKS dans la version actuelle (année 2015). Sous licence GPLv3, toute contribution est appréciée pour lui permettre d'accepter d'autres formats de conteneur.
Les keystore/truststore au format JKS sont aisément façonnables avec le libriciel "PorteCle" (hébergé sur SourceForge).

Cas de keystore format PEM encodé Base64 : les deux éléments clé privée et certificat se succèdent dans un fichier texte comme suit (à peu près):

    -----BEGIN PRIVATE KEY-----
    MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDjgbZm3IpNPn6T
    8cGG6CrsYHpS7CtkTNGWZYlAA42CtXBNjJYqVPATS4AjmFYsjOeHBq7jVzikAx/B
     [....]
    WWhTK7kd15TeXqxB93WGRO85
    -----END PRIVATE KEY-----
    -----BEGIN CERTIFICATE-----
    MIIEvDCCA6SgAwIBAgIJAMXb2wwwEe7bMA0GCSqGSIb3DQEBBQUAMIGYMQswCQYD
    VQQGEwJGUjEQMA4GA1UECBMHSGVyYXVsdDEYMBYGA1UEChMPQURVTExBQ1QtUHJv
     [....]
    aI4sMpE2XfSFX2lfQgT4zJMqLYj21aUDFY5GC/6+y/Q0DvrTnG6Zga2YT+k+ADX2
    zQTAPlHkAUt5Kwtlp9xk7w==
    -----END CERTIFICATE-----

A contrario, un truststore ne contiendra pas de clé privée, mais un ou plusieurs certificat(s), constituant la chaîne de certification attendue.

Par exemple, avec un certificat TLS/SSL issu de "Adullact G3 SERVEURS" (qui n'est pas racine, donc besoin de la chaîne complète d'AC), voici la chaîne:

-----BEGIN CERTIFICATE-----
MIIHyzCCBbOgAwIBAgIUbyl4BzfA+DWwMPJHFgkdXxI7UGswDQYJKoZIhvcNAQEF
BQAwgbUxCzAJBgNVBAYTAkZSMRAwDgYDVQQIDAdIZXJhdWx0MRQwEgYDVQQHDAtN
b250cGVsbGllcjEdMBsGA1UECgwUQXNzb2NpYXRpb24gQURVTExBQ1QxHDAaBgNV
BAsME0FDX0FEVUxMQUNUX1JPT1RfRzMxHDAaBgNVBAMME0FDX0FEVUxMQUNUX1JP
T1RfRzMxIzAhBgkqhkiG9w0BCQEWFHN5c3RlbWVAYWR1bGxhY3Qub3JnMB4XDTEy
MTEwODExMzU1MloXDTIyMTEwNTExMzU1MlowgacxCzAJBgNVBAYTAkZSMRAwDgYD
VQQIDAdIZXJhdWx0MR0wGwYDVQQKDBRBc3NvY2lhdGlvbiBBRFVMTEFDVDEgMB4G
A1UECwwXQUNfQURVTExBQ1RfU0VSVkVVUlNfRzMxIDAeBgNVBAMMF0FDX0FEVUxM
QUNUX1NFUlZFVVJTX0czMSMwIQYJKoZIhvcNAQkBFhRzeXN0ZW1lQGFkdWxsYWN0
Lm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANN56tTMCxjCbR27
kJ7su7bp34wQm9Tt3V8rUpdObHA4o4ZUC1HRuw44ZyL166tSRuf7yUXBKnyf56Gt
pHP3S7zNhGYqOw98LjxRHEPtjOToiSNV3xMcElq5WYY+0g3f4pmRU3Ba468Rq5WH
N1JW6pkqirT4U+Df7dn5YtDbaRXno7OqL/rhJMOKBZGt5BzJeHJLTwZOCe7F1IAD
lr/MGXeg52xBSkg8uxMi1v3Jj2ZJxrb0VAY3pI9DbAPAKhma0vcHtbufFPksNLqL
wK9+SgXQQJjo/w2L+wC/um7S+aCNnWMtglb1TS1h0pzHB4zoMWDRFpuCmKdcAfP3
c1uwufQkCOi7MNZ2GEFHBOA3zSf86Qve82oZ0WMcrkN/Tf6691FA0zd/8iAMjABw
nV/7DtvJ4TjUjdeGuHKGDLl8Qcz3H4R6BoBI/8Zbu5EzVxQaSUOyM8rmp3gcK8I3
fUE97trYC4h/IxrhGNCiT2Rwcs4i2PBuB3YKHIFQE/hCO893dAB6PPxRDbrWkDVM
rNxXxm/G7uf1mCCqVQESan9tbxMJB12oLOigcc3fBuEzOoEcJRWUF3oqcg1rTw1m
g6Yoe4O6KTxfVKzUuqCKGdfMXgYSFXVtaczYHAwO7IyDxzFI+NP7TY+HZNi3RWwK
JjiscTO4rC/rCpUWCNxBdj6CpJi3AgMBAAGjggHdMIIB2TAPBgNVHRMBAf8EBTAD
AQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUOWdoprXvaxQw/bHIkXltkAA+LBgw
geoGA1UdIwSB4jCB34AUXE3s1qwf7RD5lMHLioAHb4BdAHihgbukgbgwgbUxCzAJ
BgNVBAYTAkZSMRAwDgYDVQQIDAdIZXJhdWx0MRQwEgYDVQQHDAtNb250cGVsbGll
cjEdMBsGA1UECgwUQXNzb2NpYXRpb24gQURVTExBQ1QxHDAaBgNVBAsME0FDX0FE
VUxMQUNUX1JPT1RfRzMxHDAaBgNVBAMME0FDX0FEVUxMQUNUX1JPT1RfRzMxIzAh
BgkqhkiG9w0BCQEWFHN5c3RlbWVAYWR1bGxhY3Qub3JnggkA30rXXlCA8C8wHwYD
VR0RBBgwFoEUc3lzdGVtZUBhZHVsbGFjdC5vcmcwHwYDVR0SBBgwFoEUc3lzdGVt
ZUBhZHVsbGFjdC5vcmcwMAYJYIZIAYb4QgENBCMWIUF1dG9yaXRlIGRlIGNlcnRp
ZmljYXRpb24gcmFjaW5lLjA5BglghkgBhvhCAQQELBYqaHR0cDovL2NybC5hZHVs
bGFjdC5vcmcvQUNfUk9PVF9DUkxfZzMucGVtMA0GCSqGSIb3DQEBBQUAA4ICAQCB
61GymTVacQezU3pW1yvXc1WgGs2lKbEkpjR+sJQLh6p2jeW1h8zbZm82aHep/SlM
k9xeuiGnv5eGy+PaV6iZuC0L1aUVRIPl2hZHIl1VzRy7kGSG+/6PKc+/YOEFNMJB
H+Ga2NsUKZuzX+x1aYBfhWPFURXmDTOQtBrmBsk+lk/PDkXUOFYU14LyoRgwxaby
QkwPmseXLIKbkj9hcS/b7X1z26RtY8IQWpZbs2Ugrr/7lwE4II01ENp7b/n+UvDl
Jh71olVXPnFOg5El+7jxHjUezY8FzmjLgPzyoTsUKosywU7xNQ0y35NLbBGhCNiY
9HmhPELblEt6/z+ounG8IXAZ2ZTN8xaO2lVrtz6ykfgxt7daQUWdZiKylc8sqBEb
/G8nIw2xZRjLrFtwNTf0QmBl0Ha63QW2dILvm2689P0aEze0Li3rgW6YNIJG81Vt
5RbO/9cKoZJi7SOhCB2emXXLvBGXZeuEW8WhFElvMkMeAr8MYqx96xhk44bHcHuC
4g/k4UJw/r9DleG9Zosh2vKfv+gDmiWHAoPrsqf2IzD9aUE/sUJU5PyA0T+D4fEl
MuV+2AK/j0IADBTRb/Fx/K94nMEc/X/4KbsIxpaDnzwv8aStIC826n+OEPQ/zEPw
2raC0ozDCnDiKiXlYPsGe7cL4UqNYo2jIcU7gNCxoQ==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIHrjCCBZagAwIBAgIJAN9K115QgPAvMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYD
VQQGEwJGUjEQMA4GA1UECAwHSGVyYXVsdDEUMBIGA1UEBwwLTW9udHBlbGxpZXIx
HTAbBgNVBAoMFEFzc29jaWF0aW9uIEFEVUxMQUNUMRwwGgYDVQQLDBNBQ19BRFVM
TEFDVF9ST09UX0czMRwwGgYDVQQDDBNBQ19BRFVMTEFDVF9ST09UX0czMSMwIQYJ
KoZIhvcNAQkBFhRzeXN0ZW1lQGFkdWxsYWN0Lm9yZzAeFw0xMjExMDgxMTI4NDJa
Fw0yMjExMDYxMTI4NDJaMIG1MQswCQYDVQQGEwJGUjEQMA4GA1UECAwHSGVyYXVs
dDEUMBIGA1UEBwwLTW9udHBlbGxpZXIxHTAbBgNVBAoMFEFzc29jaWF0aW9uIEFE
VUxMQUNUMRwwGgYDVQQLDBNBQ19BRFVMTEFDVF9ST09UX0czMRwwGgYDVQQDDBNB
Q19BRFVMTEFDVF9ST09UX0czMSMwIQYJKoZIhvcNAQkBFhRzeXN0ZW1lQGFkdWxs
YWN0Lm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMEF0bGoI0Gg
TN+Jarap9McOeykvns4FBY9kRl1LaKq6bwYjmx0+DepuIaOcKKTTFdT+8K7hAjFp
b0IF/0XVG1O6Du7UG9SZHqK6oqTgQ8+EXhQKajB0ENxp/qln3BrdqA2LzNdAyLJm
pS908LkyqF05rKQkYQrF5QCYmM42K2ZTLeriOpfJwk/ftCleVNgmhSygYi9FPymO
ozlTcPkU398AzoENQ6rvk4b4wT1w7WbUY3CaSLV7iyVEyNPx0hNnZQVPljCS0nIT
slybx+bYNKP/bLw22cXQr+X4ULEB5+MeXsfAD+3FpXPDr4YQEnXTVGzghge4sLDF
3qna5NymbmZHv6ThfnSw/5WL331OuledeJ+SDuGRVDXLx6PF+ouc3vQvORPieYm5
rGycPd2Y6a+ljLJ6aD6BWCzBUqBbYxTnjJhrNiKTRWog2g1HzQBIro+yr7qXDjDI
nZg31XFx9satch7OM/Qy+DibTdex50SJfn+ght9ig3RmpeQNSOvAQzyNhYBDecPH
oqsQOn4+K3w/asLo5Jlb4TkQhuu+XgYdi9hNuHXMDG9YBy7V7JBx8pkYcJrQlx8c
7UBAWllnvPHoSOaaEx47dMCBbYY8HxvTVzw86alyFp5ukLSFH1P9I5MCbZ5TJAiQ
HlhTaxAu+pnZJIXKhTxkNIo716O7Qz93AgMBAAGjggG9MIIBuTAdBgNVHQ4EFgQU
XE3s1qwf7RD5lMHLioAHb4BdAHgwgeoGA1UdIwSB4jCB34AUXE3s1qwf7RD5lMHL
ioAHb4BdAHihgbukgbgwgbUxCzAJBgNVBAYTAkZSMRAwDgYDVQQIDAdIZXJhdWx0
MRQwEgYDVQQHDAtNb250cGVsbGllcjEdMBsGA1UECgwUQXNzb2NpYXRpb24gQURV
TExBQ1QxHDAaBgNVBAsME0FDX0FEVUxMQUNUX1JPT1RfRzMxHDAaBgNVBAMME0FD
X0FEVUxMQUNUX1JPT1RfRzMxIzAhBgkqhkiG9w0BCQEWFHN5c3RlbWVAYWR1bGxh
Y3Qub3JnggkA30rXXlCA8C8wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAQYwEQYJ
YIZIAYb4QgEBBAQDAgAHMB8GA1UdEQQYMBaBFHN5c3RlbWVAYWR1bGxhY3Qub3Jn
MB8GA1UdEgQYMBaBFHN5c3RlbWVAYWR1bGxhY3Qub3JnMDsGA1UdHwQ0MDIwMKAu
oCyGKmh0dHA6Ly9jcmwuYWR1bGxhY3Qub3JnL0FDX1JPT1RfQ1JMX2czLnBlbTAN
BgkqhkiG9w0BAQUFAAOCAgEAwOv2cRCnJc0WmDfGdos8mO9HOpQsposm2R+UbQ2b
98E4Q/d7hueQ4ErRQ//4fqiP9kj6zPls8ygbX9YbX/CfEkfKQ1Nj4pgD0kynBaDA
2m0A2NeZnLOMyWdiIQIzudstTRm+5+DLwNPGFqGy4PMQXbzZUGrAIdSOd+tRVMdy
JQ1yD09s/UkUsEQHanf+/bBCzN5phOapkwyN9e7hJ087VS+zgG7Qpo60iqJ6sFxm
KZ2hZfDXQEsCFO9N6313OM5PmdGFdpAAPW8E2EWQV4sA392GC0KFpzeSvz6KlBRs
jJueAYYbPQVXpziJa7m6mY0+/KJSp+h9BiIXIBcFAB9LcKHLgDIKNS9FEsFMcNlk
SxU5x20wVy54NM/Rlpn8VR6NeHa+up4ixpB5R9CspH1wcLAS0o5YG0zSvWS9ng07
gh9XzIGvhMDsmDqhW5Qd0rnZMFFLV2f83hNA0iXlXSnL69QhVOMUzMtypBmZDUp6
/P+NdBCIHCLA7DSsQzDOq3HJ43KYkEVTF7f9vJLnjRB4QrtYvI+SdH8luWKNXaZg
9s2H3XiXGqSxnoCcJyVjHDhAeII8LxEuGx5hYmMVwuUdV7n+hj6S2LP0bpsJ2C0X
oJMlk5gvY6tZ82UXtr/qu06Dd9RwFPDPpNy1KCYaXDY2WL2wzFlb4tnU4cP983kQ
HUA=
-----END CERTIFICATE-----

Et puisqu'on n'est plus à une astuce près, voici pour finir un exemple de commandes (en Bash pour Unix/Linux/MacOS) pour produire un truststore format PEM en ligne de commande, auprès d'un serveur i-Parapheur (si le nom est secure-iparapheur.mon-domaine.fr):

echo "" | openssl s_client -connect secure-iparapheur.mon-domaine.fr:443 -prexit 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' > /tmp/cert-telecharge.pem

(Attention, la commande est sur une seule longue ligne; comme on le devine, le fichier généré se trouve dans le répertoire /tmp ).

En espérant que cet article est utile à quelqu'un, il peut cependant toujours être amélioré: les commentaires et critiques sont bienvenus sur le formulaire de contact, ou écrire directement à l'Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser..