Description

SSLUtils.initSSLContext() installs the trust-all context, enables external DTD resolution across all XML parsers, and disables hostname verification for the JDK HTTP client:

SSLUtils.java:52-55

sslContext.init(keyManagerFactory.getKeyManagers(), getFakeTrustManagers(), null);

System.setProperty("javax.xml.accessExternalDTD", "all");
System.setProperty("jdk.internal.httpclient.disableHostnameVerification", "true");

View source →

getFakeTrustManagers() returns an X509TrustManager whose checkServerTrusted() and checkClientTrusted() are empty methods and whose getAcceptedIssuers() is empty, so every certificate is accepted:

SSLUtils.java:71-85

public static TrustManager[] getFakeTrustManagers() {
    return new TrustManager[] { new X509TrustManager() {
        @Override
        public void checkClientTrusted(X509Certificate[] chain, String authType)
            throws CertificateException {}
        @Override
        public void checkServerTrusted(X509Certificate[] chain, String authType)
            throws CertificateException {}
        @Override
        public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
    }};
}

View source →

The CXF HTTP transport applies the same trust-all context through ClientFactory (tlsParams.setSslContext(createFakeSSLContext())), and ServicePortProvider additionally turns off the common-name check (tlsParams.setDisableCNCheck(true)) and installs a permissive hostname verifier (hostnameVerifier((h, s) -> true)). The CN-check disable applies regardless of whether the certificate or non-certificate authentication path is taken.

This is the transport-layer half of a two-layer gap: the application layer does not authenticate the VAU server either (see med-united: VAU Server Authentication Bypass in epa4all). The two are independent; with TLS verification off there is nothing to fall back on, and even with it restored the VAU server still needs application-layer verification.

Impact

An attacker on the network path between epa4all and a backend (the ePA Aktensystem, the IDP, or the Konnektor) terminates the TLS connection with any certificate, including a self-signed one, and relays the traffic. The connection is established because no certificate or hostname check rejects it.

The intercepted traffic carries patient identifiers, document content, IDP credential exchanges, and SMC-B card operations. The attacker can read and modify all of it. If the IDP credential exchange or SMC-B operations are captured, the reach extends beyond the patient being processed at the time to any patient the intercepted SMC-B card can act on.

In the production deployment model the attacker model fits the LAN: epa4all runs as an on-premise container in a doctor's practice, reachable from the local network and connecting outbound to gematik infrastructure.

Mitigation

Update to a build dated 2026-05-20 or later, which restores certificate and hostname verification and pins the gematik TI PKI via a Telematik-TSL-based keystore. No workaround exists for affected builds. Note that restoring the JVM default trust store alone is not sufficient: the ePA Aktensystem, VAU proxy, and IDP present certificates rooted in the gematik TI PKI (for example GEM.RCA-X), which is not in the default Mozilla root list. A default-trust configuration would accept publicly-issued certificates while failing to authenticate the legitimate gematik origin, so the trust anchors must be the published TI PKI roots, with the hostname check left on. Pair this fix with med-united: VAU Server Authentication Bypass; both are required.

Defender's Checklist

Update to the 2026-05-20 build or later.

All 1.0.0-SNAPSHOT builds before that date are affected. The fix restores certificate and hostname verification and adds the Telematik-TSL keystore.

Confirm the trust anchors are the TI PKI roots, not the system default.

The gematik backends present certificates rooted in the TI PKI (GEM.RCA-X), which the default JVM/Mozilla trust store does not contain. Bind a dedicated trust store built from the published gematik root CAs to the CXF/WebClient transport for those hosts, and leave the hostname check on.

Verify no permissive hostname verifier survives.

Check that jdk.internal.httpclient.disableHostnameVerification, tlsParams.setDisableCNCheck(true), and any hostnameVerifier((h, s) -> true) are gone from the production code path. A trust store with the hostname check disabled is still bypassable by any certificate that chains to a trusted root.

Pair this fix with the VAU server-authentication fix.

TLS pinning authenticates the transport, not the VAU server's signed public keys. Both layers must verify; see med-united: VAU Server Authentication Bypass.

Severity Reasoning

AV:AThe attacker must sit on the network path between epa4all and its backends. In the on-premise deployment that is the clinical LAN segment, an adjacent-network position rather than arbitrary internet origin.AC:LA single self-signed certificate is accepted; no timing or environmental conditions.PR:NNo credentials required beyond the network position.UI:Nepa4all opens the outbound connections on its own schedule; no user interaction.S:UImpact is bounded to the traffic epa4all exchanges with its backends.C:HPlaintext access to patient identifiers, document content, and IDP credential exchanges on the intercepted connections.I:HThe attacker can modify the relayed traffic in both directions, including document content and authentication exchanges.A:NNo availability impact.

TLS Certificate Verification Disabled

Description

Impact

Mitigation

Defender's Checklist

Severity Reasoning

References

How We Can Help

Who We Are

Dr. rer. nat. Simon Weber

Dipl.-Inf. Volker Schönefeld

Looking for a Penetration Test?