Repository navigation
Test the G4 migration path end-to-end with CIBG test certificates (spec v1 and v2) #4604
Copy link
Copy link
Closed
Description
Parent: #4355. Kring Techniek tests the full migration path in the test environment with CIBG G4 test certificates before vendors are asked to apply it (planned: October 2026). #4589 covers the X509Credential part; this issue covers the rest.
Test scope
- Truststore: the nuts.nl/certs bundle (Publish PKIoverheid truststores (G1 + G4) on nuts.nl/certs #4603) contains only production PKIoverheid CAs, so for this test add the CIBG ACCEPTATIE G4 chain (root, intermediate,
ACCEPTATIE UZI Server - G4 Priv G-TLS SYS - 2025, from https://acceptatie.zorgcsp.nl/ca-certificaten) totls.truststorefileand the reverse proxy; G1 and G4 test chains both accepted - CRL reachability from the node:
crl.pkioverheid.nl(G4 root/intermediate CRLs) andwww.csp.uzi-register.nl/acceptatie.zorgcsp.nl(end-entity CRLs); PKI module downloads and verifies the RSASSA-PSS signed CRLs,/healthshows no CRL errors - Spec v1: node with a G4 test certificate in
tls.certfile/tls.certkeyfileconnects over gRPC to a peer that trusts the G4 chain, and is rejected by a peer that does not;/healthnetwork.auth_configok - mTLS on the FHIR endpoint with a G4 test client certificate against a proxy with the updated truststore (spec v1 and v2)
- Spec v2: updated discovery definition and access policy (G1 test + G4 test fingerprints) loaded; registration with a G4-based X509Credential visible via discovery and access token issued (Test issuance and usage of X509Credential backed by a G4 certificate #4589)
- Proxies/TLS stacks in use by Nuts handle RSASSA-PSS/SHA-512 and RSA 4096 (nginx version used in the e2e setup at minimum)
Result
Findings go into the vendor instructions (#4355 migration path) before they are shared (#4592).
Status
Tested locally (2026-10-12) with the real CIBG G4 test certificate (issued under ACCEPTATIE UZI Server - G4 Priv G-TLS SYS - 2025), image nutsfoundation/nuts-node:master. The setup is based on e2e nuts-network/direct-wan and is not committed, because it needs the real certificate and key.
| Item | Result |
|---|---|
| Truststore | Done. The G1 test chain (TEST Zorg CSP Private Root CA G1, TEST Zorg CSP Level 2 Private Services CA G1, TEST UZI-register Private Server CA G1) and the ACCEPTATIE G4 chain together in one truststore for node A, node B and nginx: all gRPC, health and mTLS checks above pass with it, and node A loads the G1 test CRLs without errors. A G1 test certificate itself was not tested (none available). |
| CRL | Done. Node A loads the live ACCEPTATIE CRLs (RSASSA-PSS signed) without errors; /health shows network.tls UP (chain and CRL check of its own certificate) and pki.crl UP. |
| Spec v1 (gRPC) | Done. Node A uses the G4 certificate (tls.certfile/tls.certkeyfile); node B connects to it. Node B without the G4 chain in its truststore refuses the connection (x509: certificate signed by unknown authority). With a node DID whose NutsComm is grpc://node.nuts-services.nl:5555, network.auth_config is UP. |
| mTLS (FHIR endpoint) | Done, with an nginx mTLS endpoint standing in for the FHIR endpoint, using the G4 certificate both as server certificate and as client certificate (curl). Accepted with the G4 chain in ssl_client_certificate; rejected without a client certificate and when the G4 chain is missing. |
| Spec v2 | Done. The HuisartsVVTInzage test definitions from toepassing-zorginzage-ha-vvt#52 (G1 test + G4 test fingerprints; only the endpoint changed to the local node) loaded in a node based on e2e oauth-flow/didx509. An X509Credential from the test certificate (Go toolkit) registers on the Discovery Service and is found, with organization_ura 90000380, organization_name, organization_city and fhir_base_url. An access token for scope HuisartsVVTInzage (with a NutsEmployeeCredential) carries the same organization claims. A credential from a CA that is not in the definition (the toolkit's fake CA) is refused on the id_uzicert_uracredential input descriptor. Not tested with a G1 test certificate (none available); the G1 fingerprint in the regex is unchanged. Earlier (#4589) the Java toolkit's credential from the same certificate also passed. |
| Proxies/TLS stacks | Done. nginx 1.25.1 (e2e version) and 1.30.5, HAProxy 3.3.0 and 3.4.6 (current latest and LTS), and Traefik 3.7.14 handle RSASSA-PSS/SHA-512 and RSA 4096: each serves the G4 certificate as server certificate and accepts it as client certificate. Each refuses a request without a client certificate, and refuses the G4 client certificate when the G4 chain is missing from its truststore. Tested with both the G4-only and the combined G1+G4 test truststore. |
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
Priority
None yet
Activity
reinkrul commentedon Oct 12, 2026
All items tested; results in the Status table above. Not tested: a G1 test certificate (none available).