In a secure network, certificates play a crucial role by enabling the establishment of secure connections using TLS. They also ensure the authenticity and integrity of data in transit .
Both the Sending System and Receiving System expose endpoints that must be protected from unauthorized and malicious interactions. More specifically, access control measures must be applied to the following endpoints:
-
Receiving System: Notification endpoint (FHIR Task endpoint)
-
Sending System: Resource endpoint
Mutual TLS shall be used to protect these endpoints in the following ways:
-
Authentication: The sending and receiving systems are mutually verifying each other's identity before establishing a secure connection. In this way only systems that are trusted (are a GtK) are allowed to set up connections.
-
Encryption: an mTLS connection is encrypted. This means that only the sending and receiving systems can read the exchanged data and no third, unauthorized party can ‘listen in’.
-
Integrity: mTLS assures that the data has not been modified by any unauthorized party during transmission. Any tampering attempts would alert the recipient.
-
Protection against replay attacks: Each message sent over the connection includes a sequence number, and the recipient keeps track of the sequence numbers it has received. If a message with a previously received sequence number arrives, it is considered a replayed message and is rejected. This prevents attackers from intercepting and resending previously valid messages.
Terminology
-
Certificate Authority (CA): A trusted entity responsible for issuing and managing certificates used in secure network connections.
-
Certificate Revocation List (CRL): A list maintained by a Certificate Authority, containing revoked certificates to prevent the use of compromised or invalid certificates.
-
Public Key Infrastructure overheid (PKIo): A PKI structure controlled by the Dutch government, governing the issuance and management of certificates in the Netherlands.
-
Trusted Service Provider (TSP): A party authorized to issue PKIo certificates within the PKIo infrastructure, ensuring the integrity and security of the certificates they issue.
Network level security: mTLS 1.3
At the network level, mutual TLS (mTLS) must be applied. The TLS-implementation must comply with the security level “Good” as specified by the National Cyber Security Centre (NCSC). At the time of writing, the https://www.ncsc.nl/documenten/publicaties/2025/juni/01/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2025-05 (Security guidelines for Transport Layer Security 2025-05) require version 1.3 of the TLS standard for the security level “Good”. In the case one or more of the cipher suites (Appendix B of the Security guidelines) are declassified by NCSC will this be described in a future version of the Twiin specification.
The exchange of a client certificate during the mTLS handshake does not only enable the server to authenticate the client on network level, but it also enables the server to issue certificate bound access tokens as specified in https://www.rfc-editor.org/rfc/rfc8705 as an additional security measure on application level. See section Resource server authorization: OAuth 2.0 for requirements on application level security using OAuth 2.0.
CRL / OCSP / CPS
The validity of a certificate shall be verified using a CRL, OCSP, or CPS check. A determined validity may be relied upon for a maximum of one hour, after which the verification must be performed again. If the validity of a certificate cannot be established, the connection shall be terminated, as it shall also be terminated if the certificate is found to be invalid.
PKIoverheid
Both the client and server certificates must be PKIo-certificates that are issued under the CA “Staat der Nederlanden Private Services CA – G1” (this includes UZI server certificates issued by UZI-registry (CIBG)). https://cert.pkioverheid.nl/
Note: the requirements specified in this chapter apply to Notification, FHIR, and token endpoints.