Skip to main content
Skip table of contents

SR Aanscherpen TLS-vereisten

Omschrijving Change

Korte omschrijving

Deze wijziging stelt TLS 1.3 verplicht voor alle backchannel-verkeer op het MedMij-netwerk en introduceert een Uitfaseringsregeling voor TLS 1.2.

TLS 1.2 is per 31 december 2026 niet meer toegestaan.

Aanleiding:
Het NCSC classificeert TLS 1.2 als "onvoldoende" en TLS 1.3 als "voldoende" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (versie 2025-05).

Het huidige Afsprakenstelsel staat TLS 1.2 nog toe als fallback. Om het beveiligingspostuur van het MedMij-netwerk te verhogen, wordt TLS 1.3 verplicht gesteld per 31-12-2026.

Samenvatting wijzigingen normteksten
--> core.tls.301: NCSC-verwijzing bijgewerkt naar versie 2025-05.
--> Tekst verbreed naar "geassocieerde configuratieparameters, zoals algoritmen". core.tls.305

(kernwijziging): TLS 1.3 verplicht voor alle deelnemers. TLS 1.2 verplicht voor clients (fallback), optioneel voor servers.

Uitfaseringsregeling TLS 1.2:
tot 31 december 2026. Na die datum is TLS 1.2 niet langer toegestaan op het MedMij-netwerk. core.tls.309: Validatietekst verduidelijkt; CRL-distributielink toegevoegd. core.tls.313: Tekstuele correctie (geen inhoudelijke wijziging).

core.tls.314: GEHEEL VERVALLEN.
De specifieke G1-certificaatlijst is niet langer als aparte verantwoordelijkheid opgenomen. Toegestane certificaten worden nu uitsluitend bepaald door core.tls.311.

Uitfaseringsregeling TLS 1.2: tot 31 december 2026. Na die datum is TLS 1.2 niet langer toegestaan op het MedMij-netwerk. core.tls.309: Validatietekst verduidelijkt; CRL-distributielink toegevoegd. core.tls.313: Tekstuele correctie (geen inhoudelijke wijziging).

Scope: Dit wijzigingsvoorstel betreft uitsluitend TLS.

Impact Alle DVP's en DVA's moeten TLS 1.3 ondersteunen op backchannel-endpoints. Deelnemers die uitsluitend TLS 1.2 ondersteunen (ca. 7%) moeten voor 31-12-2026 migreren. 93% van de deelnemers is reeds compliant.

Impact op:

☑ DVP ☑ DVA ☐ Geen van beiden

Moeten afbeeldingen/mockups aangepast worden?

☐ Ja ☑ Nee

Aan te passen versies afsprakenstelsel

2.3.0

Classificatie

☐ Patch ☑ Minor ☐Major ☐ N.v.t

Implementatie Termijn

Uitfaseringsregeling TLS 1.2: tot 31 december 2026. Na deze datum is TLS 1.2 niet langer toegestaan op het MedMij-netwerk.

MedMij Referentie

AF-587, AF-597, AF-609

Status

☐ Beta ☑ Release candidate ☐ Release

Akkoord bevonden door

☑ Product owner

☑ Architect afsprakenstelselteam

☑ Releasemanager

Uitwerking

Door te voeren wijzigingen

Locatie

Oude situatie

Nieuwe situatie

In te voegen links (optioneel)

Verantwoordelijkheden, Core TLS en certificaten, core.tls.301

Er wordt gebruikgemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste TLS-versie worden ondersteund. Hogere TLS-versies mogen worden aangeboden.

Er wordt gebruikgemaakt van TLS-versies en geassocieerde configuratieparameters, zoals algoritmen, die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2025-05 van het NCSC. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste TLS-versie worden ondersteund. Hogere TLS-versies mogen worden aangeboden.

NCSC TLS richtlijnen versie 2025-05

Verantwoordelijkheden, Core TLS en certificaten, core.tls.305

Als invulling van core.tls.302 geldt, in afwijking van core.tls.301: TLS 1.2 moet door elke deelnemer ondersteund worden. TLS 1.3 moet door elke deelnemer ondersteund worden, indien redelijkerwijs mogelijk. TLS 1.2 TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens eis 1b ondersteund mag worden. Bij deze release van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden in door sommigen gebruikte componenten. Daarom maken we gebruik van de mogelijkheid die regel 1c biedt om een afwijkende regeling te treffen. De afwijkende regeling bestaat eruit dat TLS 1.3 door iedere deelnemer aangeboden moet worden, indien redelijkerwijs mogelijk. Om redenen van interoperabiliteit moet iedere deelnemer TLS 1.2 blijven ondersteunen. Het voornemen is deze afwijking te schrappen zodra TLS 1.3 breed ondersteund wordt, waardoor verantwoordelijkheid 1b weer onverkort geldt en TLS 1.3 de enige toegestane versie wordt. Dit kan al dan niet met behulp van een snel door te voeren patch op het MedMij Afsprakenstelsel.

Als invulling van core.tls.302 geldt, in afwijking van core.tls.301: TLS 1.3 moet door elke deelnemer ondersteund worden. TLS 1.2 moet door elke client ondersteund worden. TLS 1.2 mag door elke server ondersteund worden. TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2025-05 van het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens eis 1b ondersteund mag worden. Omdat het uitfaseren van TLS 1.2 mogelijk disruptief is voor ons netwerk maken we tijdelijk nog gebruik van de mogelijkheid die regel 1c biedt om een afwijkende regeling te treffen. De afwijkende regeling bestaat eruit dat alle deelnemers TLS 1.3 zo snel mogelijk implementeren, maar clients nog wel TLS 1.2 moeten ondersteunen.

Uitfaseringsregeling

TLS 1.2 MedMij is van plan door middel van logging en testen TLS 1.2 gedurende 2026 gefaseerd uit te schakelen op het netwerk. Per 31 december 2026 vervalt deze uitfaseringsregeling. Vanaf die datum is TLS 1.2 niet langer toegestaan op het MedMij-netwerk. Verantwoordelijkheid core.tls.301 geldt dan onverkort: TLS 1.3 is de enige toegestane versie.


Deze verantwoordelijkheid vervalt per 1 januari 2027.

NCSC TLS richtlijnen versie 2025-05

Verantwoordelijkheden, Core TLS en certificaten, core.tls.309

Alle Backchannel Nodes valideren tijdens de TLS-handshake bij backchannel-verkeer aan het begin van een TLS-sessie of het een PKIoverheid-certificaat is en controleren bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. In geval van het falen van een van deze controles wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart.

Alle Backchannel Nodes valideren tijdens de TLS-handshake bij backchannel-verkeer aan het begin van een TLS-sessie of het ontvangen certificaat op het MedMij-netwerk toegestaan is (zie core.tls.311). Daarnaast controleren zij bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. Indien de controle faalt wordt het certificaat niet geaccepteerd en wordt de TLS-sessie niet gestart. CRL-lijsten voor PKIoverheid-certificaten zijn te vinden op https://crl.pkioverheid.nl/ en in het X509v3 CRL Distribution Points -veld in het ontvangen certificaat.

CRL PKIoverheid

Verantwoordelijkheden, Core TLS en certificaten, core.tls.313

PKI-certificaten moeten (in ieder geval op productie en acceptatie omgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij).

PKI-certificaten moeten (in ieder geval op productie en acceptatieomgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaatketen bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij).

Verantwoordelijkheden, Core TLS en certificaten, core.tls.314

Voor authenticatie en autorisatie bij backchannel-verkeer op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een G1-certificaat van een PKIoverheid TSP. Private Root CA (per medio 2020 de standaard voor m2m): Stamcertificaat: Staat der Nederlanden Private Root CA - G1 Domein Private Services, maar alleen de volgende: Staat der Nederlanden Private Services CA - G1 KPN PKIoverheid Private Services CA - G1 QuoVadis PKIoverheid Private Services CA - G1 Digidentity BV PKIoverheid Private Services CA - G1

GEHEEL VERVALLEN.

Deze verantwoordelijkheid wordt geheel verwijderd bij publicatie.

De specifieke G1-certificaatlijst is niet langer als aparte verantwoordelijkheid opgenomen. De toegestane certificaten voor backchannel-verkeer worden nu uitsluitend bepaald door core.tls.311, waarin zowel G1 als (toekomstig) G4 stamcertificaten zijn opgenomen.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.