Certificats eHealth et chiffrement (ETEE)

Les certificats de la Plate-forme eHealth permettent à une personne ou à une organisation de s'authentifier comme prestataire de soins ou comme établissement agréé ; un certificat est requis dès qu'un logiciel veut accéder aux services de base via une connexion system-to-system (donc pas via une application web)^[1]. Le Welcome Pack classe les certificats eHealth parmi les services de base, à côté du chiffrement de bout en bout (liste à la p. 3)^[2]. Pour les services web de la plate-forme, l'authentification du service consumer se fait au niveau du message avec des certificats X.509, sur une connexion SSL/TLS obligatoire^[3].

Le certificat identifie et authentifie le partenaire « système » (logiciel ou organisation), tandis que l'eID ou un token identifie l'utilisateur individuel^[1]. Avec un certificat ou une eID, le logiciel obtient auprès d'I.AM STS un token SAML pour les services web SOAP^[3] ; voir I.AM et I.AM Connect (Identity & Access Management).

Statut : production. La demande se fait via l'application web eHealth Certificate Manager^[1]. Pour un certificat d'organisation, un titulaire de certificat mandaté est responsable de la gestion correcte au nom de la personne morale^[6]. Le backend pour la demande, le renouvellement et la révocation de certificats et d'ETK se compose des services CertRA et EtkRA, documentés dans le cookbook « eHealth platform Certificates Manager (CertRA - EtkRA) - V2 »^[1].

Interfaces techniques

• Validité : un certificat de production est valable 36 mois et renouvelable à partir de 90 jours avant son expiration^[1][6]. Pour les intégrateurs de logiciels, il existe des certificats d'acceptation distincts, valables 3 ans mais sans accès à la production^[7].
• Trust store : la plate-forme eHealth diffuse sa liste de certificats de confiance selon la spécification ETSI pour les Trusted Lists, de sorte que les logiciels puissent mettre à jour leur trust store de manière sûre et automatisable^[1].
• ETEE et ETK : le service ETEE (End to End Encryption, aussi appelé service de chiffrement ou d'encryptage) est un ensemble de services permettant de chiffrer des messages destinés à des prestataires de soins ou à des établissements^[5] ; il est utilisé entre autres au sein d'eHealthBox et de Recip-e^[5]. Un ETK n'est pas un autre nom pour ce service, mais la clé publique liée au certificat eHealth d'un destinataire connu et récupérée via le service web ETK^[5]. Pour le chiffrement vers un destinataire connu, le service ETEE propose ETKDepot (SOAP et REST) et KeyDepot (REST)^[4].
• KGSS : le service KGSS est utilisé lorsque l'identité du destinataire d'un message chiffré n'est pas connue à l'avance, mais que certaines conditions doivent être remplies pour obtenir la clé^[5] ; KGSS est disponible comme service SOAP et REST^[4]. Un exemple (illustration propre) : lors de la prescription, on ne sait pas encore quel pharmacien délivrera. ETKDepot et KGSS font aussi partie de solutions plus globales comme Recip-e, le Chapitre IV et eHealthBox^[5]. Les critères d'enregistrement modulaires de 2019 pour les logiciels de médecine générale citent eux aussi les services de chiffrement pour eHealthBox et Recip-e^[8].

État et feuille de route

La plate-forme eHealth annonce un passage de RSA-2048 à la cryptographie sur courbes elliptiques : ECC 384 remplacera « prochainement » RSA-2048^[7]. Les deux types restent utilisables en parallèle, mais l'eHealth Certificate Manager ne générera plus que des certificats ECC ; les ETK restent en RSA^[7]. Le passage est donc annoncé et non réalisé : pour une période de transition, une version parallèle du Certificate Manager est disponible dans l'environnement d'acceptation, avec laquelle des certificats RSA peuvent encore être commandés^[7]. Une date pour la production n'a pas été trouvée (lacune).

Indépendamment de cela, la plate-forme eHealth a renouvelé en juillet 2026 les certificats et les clés de ses propres services I.AM (intégrations SAML IDP/STS/AA et la validation JWT d'I.AM Connect) ; cela ne concerne pas les certificats eHealth des partenaires. Les applications dont la gestion des métadonnées ou de la truststore est manuelle devaient s'adapter avant le 22/07/2026^[9] ; l'ancienne clé de production d'I.AM Connect a été supprimée le 26/08/2026^[9]. Pour les connecteurs, SHA256 est obligatoire depuis octobre 2023^[10].

• Condition technique : toute connexion system-to-system d'une application hospitalière avec les services de base eHealth requiert un certificat eHealth^[1]. Pour les tests MyCareNet, le fournisseur demande un certificat de test pour le secteur^[11] ; voir MyCareNet.
• Responsabilité : pour un certificat d'organisation, le titulaire de certificat mandaté porte la responsabilité de la gestion correcte au nom de la personne morale^[6] ; savoir qui remplit ce rôle est un choix organisationnel (interprétation).
• Opérationnel : les certificats expirent après 36 mois^[1] ; un certificat expiré interrompt toutes les connexions qui s'authentifient avec lui (déduction).
• Recommandation (propre) : gérez les certificats de manière centralisée avec un calendrier des dates d'expiration (entamez le renouvellement largement dans la fenêtre de 90 jours), et testez au préalable les certificats ECC en acceptation avec toutes les applications qui partagent le même certificat, tant que RSA et ECC y restent commandables en parallèle.

Conditions de mise en œuvre et limites

L'accès aux services web dans l'environnement d'acceptation requiert un certificat d'acceptation et l'intégration du connecteur^[7] ; voir Connecteurs eHealth (eHealth platform services connectors) et Intégration technique avec l'infrastructure eHealth.

• La date de fin définitive pour les certificats RSA n'a pas été trouvée ; la source dit seulement qu'ECC 384 remplacera « prochainement » RSA-2048^[7]. La phrase de claim de^[7] (« les nouveaux certificats ... sont désormais en ECC ») va plus loin que sa citation et n'est pas suivie ici.
• La phrase de claim de^[5] appelle ETEE à tort « aussi ETK » ; la citation elle-même dit « service de chiffrement ou d'encryptage ». La page suit la citation.
• Les sources trouvées ne documentent pas si tous les logiciels destinataires prennent en charge les certificats ECC (lacune).