eHealth-certificaten en versleuteling (ETEE)

De certificaten van het eHealth-platform laten een persoon of organisatie toe zich te authentiseren als zorgverlener of erkende instelling; een certificaat is vereist zodra een softwarepakket via een system-to-systemverbinding (dus niet via een webtoepassing) toegang wil tot de basisdiensten^[1]. Het Welcome Pack rekent eHealth-certificaten tot de basisdiensten, naast end-to-endversleuteling (lijst op p. 3)^[2]. Bij de webservices van het platform gebeurt de authenticatie van de service consumer op berichtniveau met X.509-certificaten, over een verplichte SSL/TLS-verbinding^[3].

Het certificaat identificeert en authenticeert de 'systeem'-partner (software of organisatie), terwijl de eID of een token de individuele gebruiker identificeert^[1]. Met een certificaat of eID verkrijgt de software bij I.AM STS een SAML-token voor SOAP-webservices^[3]; zie I.AM en I.AM Connect (Identity & Access Management).

Status: productie. De aanvraag verloopt via de webapplicatie eHealth Certificate Manager^[1]. Voor een organisatiecertificaat is een gevolmachtigd certificaathouder namens de rechtspersoon verantwoordelijk voor het correcte beheer^[4]. De backend voor aanvraag, hernieuwing en intrekking van certificaten en ETK's bestaat uit de diensten CertRA en EtkRA, gedocumenteerd in de cookbook "eHealth platform Certificates Manager (CertRA - EtkRA) - V2"^[1].

• Geldigheid: een productiecertificaat is 36 maanden geldig en hernieuwbaar vanaf 90 dagen vóór het verstrijken^[1][4]. Voor software-integratoren bestaan aparte acceptatiecertificaten, 3 jaar geldig maar zonder toegang tot productie^[5].
• Trust store: het eHealth-platform verspreidt zijn lijst van vertrouwde certificaten volgens de ETSI-specificatie voor Trusted Lists, zodat softwarepakketten hun trust store veilig en automatiseerbaar kunnen bijwerken^[1].
• ETEE en ETK: de ETEE-dienst (End to End Encryption, ook versleutelings- of encryptiedienst genoemd) is een reeks diensten om berichten aan zorgverleners of instellingen te versleutelen^[6]; hij wordt onder meer gebruikt binnen eHealthBox en Recip-e^[6]. Een ETK is geen andere naam voor die dienst, maar de publieke sleutel die aan het eHealth-certificaat van een gekende ontvanger gekoppeld is en via de ETK-webservice wordt opgehaald^[6]. Voor versleuteling naar een gekende bestemmeling biedt de ETEE-dienst ETKDepot (SOAP en REST) en KeyDepot (REST) aan^[7].
• KGSS: de dienst KGSS wordt gebruikt wanneer de identiteit van de bestemmeling van een versleuteld bericht niet op voorhand gekend is, maar bepaalde voorwaarden vervuld moeten zijn om de sleutel te verkrijgen^[6]; KGSS is beschikbaar als SOAP- en REST-dienst^[7]. Een voorbeeld (eigen illustratie): bij het voorschrijven is nog niet geweten welke apotheker zal afleveren. ETKDepot en KGSS zitten ook in globalere oplossingen zoals Recip-e, Hoofdstuk IV en eHealthBox^[6]. Ook de modulaire registratiecriteria voor huisartsensoftware van 2019 noemen de versleutelingsdiensten voor eHealthBox en Recip-e^[8].

Het eHealth-platform kondigt een overstap aan van RSA-2048 naar elliptische-curvecryptografie: ECC 384 zal 'binnenkort' RSA-2048 vervangen^[5]. Beide types blijven parallel bruikbaar, maar de eHealth Certificate Manager zal enkel nog ECC-certificaten genereren; de ETK's blijven RSA^[5]. De overstap is dus aangekondigd en niet voltrokken: voor een overgangsperiode in de acceptatieomgeving is een parallelle versie van de Certificate Manager beschikbaar waarmee nog RSA-certificaten besteld kunnen worden^[5]. Een datum voor productie is niet gevonden (gap).

Los daarvan vernieuwde het eHealth-platform in juli 2026 de certificaten en sleutels van zijn eigen I.AM-diensten (SAML-integraties IDP/STS/AA en de JWT-validatie van I.AM Connect); dat betreft niet de eHealth-certificaten van partners. Toepassingen met manueel metadata- of truststorebeheer moesten vóór 22/07/2026 aanpassen^[9]; de oude productiesleutel van I.AM Connect werd op 26/08/2026 verwijderd^[9]. Voor de connectoren is SHA256 verplicht sinds oktober 2023^[10].

• Technische voorwaarde: elke system-to-systemkoppeling van een ziekenhuistoepassing met eHealth-basisdiensten vereist een eHealth-certificaat^[1]. Voor MyCareNet-testen vraagt de leverancier een testcertificaat voor de sector aan^[11]; zie MyCareNet.
• Verantwoordelijkheid: bij een organisatiecertificaat draagt de gevolmachtigde certificaathouder de verantwoordelijkheid voor het correcte beheer namens de rechtspersoon^[4]; wie die rol invult, is een organisatorische keuze (interpretatie).
• Operationeel: certificaten verlopen na 36 maanden^[1]; een verlopen certificaat onderbreekt alle koppelingen die ermee authenticeren (afleiding).
• Aanbeveling (eigen): beheer certificaten centraal met een vervaldatumkalender (start hernieuwing ruim binnen het venster van 90 dagen), en test ECC-certificaten vooraf in acceptatie met alle toepassingen die hetzelfde certificaat delen, zolang daar nog RSA en ECC naast elkaar bestelbaar zijn.

Toegang tot webservices in de acceptatieomgeving vereist een acceptatiecertificaat en de integratie van de connector^[5]; zie eHealth-connectoren (eHealth platform services connectors) en Technische integratie met de eHealth-infrastructuur.

• De definitieve einddatum voor RSA-certificaten is niet gevonden; de bron zegt enkel dat ECC 384 RSA-2048 "binnenkort" vervangt^[5]. De claimzin van^[5] ('nieuwe certificaten ... zijn voortaan ECC') gaat verder dan zijn citaat en wordt hier niet gevolgd.
• De claimzin van^[6] noemt ETEE ten onrechte 'ook ETK'; het citaat zelf zegt 'versleutelings- of encryptiedienst'. De pagina volgt het citaat.
• Of alle ontvangende software ECC-certificaten ondersteunt, is niet gedocumenteerd in de gevonden bronnen (gap).