Skip to content

Test the G4 migration path end-to-end with CIBG test certificates (spec v1 and v2) #4604

Closed

Description

@reinkrul

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) to tls.truststorefile and the reverse proxy; G1 and G4 test chains both accepted
  • CRL reachability from the node: crl.pkioverheid.nl (G4 root/intermediate CRLs) and www.csp.uzi-register.nl / acceptatie.zorgcsp.nl (end-entity CRLs); PKI module downloads and verifies the RSASSA-PSS signed CRLs, /health shows no CRL errors
  • Spec v1: node with a G4 test certificate in tls.certfile/tls.certkeyfile connects over gRPC to a peer that trusts the G4 chain, and is rejected by a peer that does not; /health network.auth_config ok
  • 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.

Activity

  1. reinkrul commented on Oct 12, 2026

    @reinkrul
    MemberAuthor

    All items tested; results in the Status table above. Not tested: a G1 test certificate (none available).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions