fix: verifyCertificates configuration being ignored

[richard-salac]

Description

Mark Ackert reported on Dec 17 2025:

I took the latest APIML build today and ran my AT-TLS against it with modulith disabled. Things are looking better, however I'm seeing one failure I haven't seen before: z/OSMF SSLHandshakeException. The error stack is here:

2025-12-17 20:26:02.960 ZWEAGW1:reactor-http-nio-1:67174828 [35mZWESVUSR [0;39m [36mDEBUG [0;39m ((o.z.a.g.c.GatewayExceptionHandler)) SSL exception on http://AAAAAA:7554/ibmzosmf/api/v1/zosmf/restjobs/jobs?owner=XXXXX&prefix=* javax.net.ssl.SSLHandshakeException: No name matching AAAAAA found

This environment is AT-TLS enabled for Zowe alone, with ZOSMF_SCHEME set to HTTPS, verifyCertificates set to DISABLED, and the Zowe keyring contains the z/OSMF Certificate Authority. Originally verifyCertificates was set to NONSTRICT, and that failed as well. I should call out that the certificate for z/OSMF is 100% using the wrong SAN, it's set to BBBBBB when the real host is AAAAAA. I'd expect this error to be ignored.

Earlier in the log, it was ignored:

2025-12-17 20:26:18.559 ZWEAZS1:DiscoveryClient-InstanceInfoReplicator-%d:83951969 [35mZWESVUSR [0;39m [36mDEBUG [0;39m ((o.z.a.z.s.s.z.ZosmfService)) Verifying z/OSMF accessibility on info endpoint: https://AAAAAA:10443/zosmf/info 2025-12-17 20:26:18.569 ZWEAZS1:DiscoveryClient-InstanceInfoReplicator-%d:83951969 [35mZWESVUSR [0;39m [36mDEBUG [0;39m ((o.z.a.z.s.l.Providers)) z/OSMF is registered and propagated to the DS: true and is accessible based on the information: true

Update: fixing the z/OSMF certificate domain / ip addressed the issue. So the verify_certificates setting isn't respected in my deployment.

Analysis

Tested in GH actions without AT-TLS. The verifyCertificates config is working fine. The configuration was applied via environment variables as the GH actions docker images are not started via start.sh

Tested for hostname not in SAN for the mock-services and discoverable-client containers. Two new test jobs were added to test the verifyCertificates: NONSTRICT configuration: CITestsModulithUnknownHostnames and CITestsUnknownHostnames that passed.

The AT-TLS investigation is pending.

Linked to # (issue) Part of the # (epic)

Type of change

Please delete options that are not relevant.

• [ ] fix: Bug fix (non-breaking change which fixes an issue)
• [ ] feat: New feature (non-breaking change which adds functionality)
• [ ] docs: Change in a documentation
• [ ] refactor: Refactor the code
• [ ] chore: Chore, repository cleanup, updates the dependencies.
• [ ] BREAKING CHANGE or !: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• [ ] My code follows the style guidelines of this project
• [ ] PR title conforms to commit message guideline ## Commit Message Structure Guideline
• [ ] I have commented my code, particularly in hard-to-understand areas. In JS I did provide JSDoc
• [ ] I have made corresponding changes to the documentation
• [ ] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing unit tests pass locally with my changes
• [ ] The java tests in the area I was working on leverage @Nested annotations
• [ ] Any dependent changes have been merged and published in downstream modules

For more details about how should the code look like read the Contributing guideline

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud