fix: allow icsf keys when using at-tls

[1000TurquoisePogs]

As noted in slack https://openmainframeproject.slack.com/archives/CC5UUL005/p1717504267648599
APIML cannot seem to read ICSF keys,

I have an ICSF key.
It looks like APIML cannot read it with java 8, so I am trying to use AT-TLS instead.
When I dont use AT-TLS, type=JCERACFKS does not work.
You get ZWEAM510E Invalid key alias 'site default icsf'
When type=JCECCARACFKS is used instead, you get
java.security.KeyStoreException: JCECCARACFKS not found
When I turn on AT-TLS, gateway still tries to read whatever is in yaml entry zowe.certificate, so even though it should work, the above errors still occur.

 certificate:
    keystore:
      type: "JCECCARACFKS"
      file: "safkeyring://username/ringname"
      alias: "site default icsf"
      password: "password"
    truststore:
      type: "JCECCARACFKS"
      file: "safkeyring://username/ringname"
      password: "password"

gateway:
    server:
      ssl:
        enabled: false
    spring:
      profiles:
        active: attls

The only combination that seems to work is preventing APIML from reading the zowe yaml keystore content.

Reading the truststore appears fine; I dont believe ICSF changes CA content type, so APIML should still be able to validate keys that are incoming.

This probably doesnt work for situations in which APIML needs a key for its own use - Perhaps client cert still works because the cert comes from ATTLS, but situations like provider=saf wont work, because the key wouldnt be visible to gateway at startup.

So, this is a fix, but also a tradeoff.

If you would like to put this under some variable we can do so, since it is a tradeoff. I just could not think of the right name so I leave it up to the squad.

Type of change

• fix: Bug fix (non-breaking change which fixes an issue)

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

[1000TurquoisePogs]

Notes:

• Lot of copy-paste for networking stuff in the start scripts. Better to move to a common script that is packaged with all of them?
• metrics service script doesnt have the java 17 logic I saw in the other scripts

[balhar-jakub]

As for the metrics-service. It's technical preview and extension and the current plan is to stop the support altogether, as such we aren't really looking into validating the service on Java 17.

[pablocarle]

LGTM, reusing parts of the scripts could be another issue / PR

[sonarqubecloud]

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 SonarCloud