APIML not respecting zowe.verifyCertificates: DISABLED
@taban03 is already working on this.
Since Apr 22, 2026.
- Dominant language
- Java
- Stars
- 92
- Forks
- 81
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 46
Description
Describe the bug
When zowe.verifyCertificates is set to DISABLED in zowe.yaml, several internal APIML components continue to enforce SSL certificate validation. The Gateway rejects outbound connections to services with untrusted/self-signed certificates, and the ZAAS client SDK always performs strict certificate validation, even when the user has explicitly disabled verification.
The root cause is two independent code paths that build their own SSL contexts without checking the verifySslCertificatesOfServices flag:
-
ConnectionUtil.getSslContext()(ConnectionUtil.java) — Builds the NettySslContextused by Spring Cloud Gateway's reactiveWebClientfor all proxied traffic. It always loads the truststore into a realTrustManagerFactoryregardless of theverifySslCertificatesOfServicesvalue. Only hostname verification is conditionally disabled, not certificate trust validation. This affects thegatewayHttpClientFactory,webClient, andwebClientClientCertbeans in WebClientConfig.java. -
ZaasHttpsClientProvider(ZaasHttpsClientProvider.java) — Creates its ownSSLContextentirely independently ofHttpsFactory. It always initializes aTrustManagerFactorywith the truststore. Additionally, theConfigPropertiesclass for the ZAAS client doesn't even have averifySslCertificatesOfServicesfield — onlynonStrictVerifySslCertificatesOfServicesexists — so there is no way to propagate the DISABLED setting.
Note: The Apache HttpClient path (HttpsFactory.getSslContext() in common-service-core) and the secureSslContext Spring bean (exposed by HttpConfig) do correctly handle DISABLED by returning a trust-all SSLContext. Components that consume that bean (e.g., RefreshablePeerEurekaNodes, DiscoveryRestTemplateConfig) work correctly.
Summary of which components respect the setting:
| Component | Code path | Respects DISABLED? |
|---|---|---|
HttpsFactory (Apache HttpClient) |
common-service-core/.../HttpsFactory.java |
Yes |
secureSslContext bean consumers |
HttpConfig.java → HttpsFactory.getSslContext() |
Yes |
| Discovery Eureka peer nodes | RefreshablePeerEurekaNodes.java (uses secureSslContext bean) |
Yes |
| Eureka client registration | DiscoveryRestTemplateConfig.java (uses secureSslContext bean) |
Yes |
| Discovery x509 auth (server-side) | HttpsWebSecurityConfig.java |
Yes |
| Gateway WebClient (Netty) | ConnectionUtil.getSslContext() |
No — always validates |
| ZAAS client SDK | ZaasHttpsClientProvider |
No — always validates |
Steps to Reproduce
- Set
zowe.verifyCertificates: DISABLEDinzowe.yaml - Configure a backend service with a self-signed certificate that is NOT in the APIML truststore
- Register that service with the Discovery Service
- Access the service through the API Gateway
- Observe the Gateway returns 502/503 due to SSL handshake failure
Expected behavior
When zowe.verifyCertificates is set to DISABLED, all APIML components should skip certificate validation entirely — matching the behavior of other Zowe components. The Gateway should successfully proxy traffic to services regardless of their certificate status. The ZAAS client should connect without certificate errors.
Screenshots
N/A
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.