Check certificate validity on startup

[1000TurquoisePogs]

It would be helpful if Zowe could validate your certificate both at init time and at runtime.
It's not uncommon to have a certificate with wrong EKU requirements, but its als possible to have your certificate be valid at one point, but then expire when you arent looking.

Keytool seems like a good way to check this. It can print out PKCS12 and keyring content, including ICSF keys (via hwkeyring instead.)

Prototype: if you added this logic here

zowe-install-packaging/bin/commands/internal/start/prepare/index.ts

Line 490 in f39938f

common.printFormattedInfo("ZWELS", "zwe-internal-start-prepare", "Zowe runtime environment prepared");

    let certAlias = ZOWE_CONFIG.zowe.certificate.keystore.alias;
    let keystore = ZOWE_CONFIG.zowe.certificate.keystore.file;
    let keystoreType = ZOWE_CONFIG.zowe.certificate.keystore.type;
    let javaHome = ZOWE_CONFIG.java.home;
    let pass = ZOWE_CONFIG.zowe.certificate.keystore.password;

    if (ZOWE_CONFIG.zowe.verifyCertificates != "DISABLED") {
      const errOut = shell.execOutSync('sh', '-c', `${javaHome}/bin/keytool -J-Djava.protocol.handler.pkgs=com.ibmkeytool -J-Djava.protocol.handler.pkgs=com.ibm.crypto.provider -list -v -keystore ${keystore} -storetype ${keystoreType} ${keystoreType != 'PKCS12' ? '' : '-storepass '+pass} -alias `+ certAlias);
      if (errOut.out.indexOf('ExtKeyUsage') != -1) {
        let fail = false;
        if (errOut.out.indexOf('1.3.6.1.5.5.7.3.1') == -1) {
          common.printFormattedError('ZWELS', "zwe-internal-start-prepare", "Missing TLS Web Server Authentication property for Extended Key Usage of certificate "+certAlias);
          fail=true;
        }
        if (errOut.out.indexOf('1.3.6.1.5.5.7.3.2') == -1) {
          common.printFormattedError('ZWELS', "zwe-internal-start-prepare", "Missing TLS Web Client Authentication property for Extended Key Usage of certificate "+ certAlias);
          fail=true;
        }
        if (fail) {
          common.printErrorAndExit('Error ZWEL0999E: Certificate invalid for Zowe. Correct or remove the Extended Key Usage property of '+certAlias, undefined, 999);
        }
      }
  
      let expirationText = errOut.out.split('Valid from:')[1].split('until: ')[1].split('\n')[0];
      let expireDate = new Date(expirationText);
      let currentTime = new Date();
      if (expireDate.getTime() < currentTime.getTime()) {
        common.printErrorAndExit(`Error ZWEL0999E: Certificate expired on ${expireDate}`, undefined, 999);
      }
    }

This will print out if you're missing EKU properties, or if your certificate has expired.
May need adjustment for timezones, hwkeytool, and pkcs12.

[pavel-jares-bcm]

What about using the Certificate Analyzer from the API ML? I am not sure if it supports everything, but it could be extended/modified. I guess verification could be done without reading a private key, so it should work even with ICSF.

[JoeNemo]

Does this Cert Analyzer work on all the latest Java versions? Does it allow its users to see EKU properties (and anything else) or does it hide things like keytool?

[pavel-jares-bcm]

It should work with all versions of Java because it is independent of Keytool. It is reading the value explicitly:

https://github.com/zowe/api-layer/blob/ec5d1a4255110f068aa9fbd8128cc9fe88ceb2dd/certificate-analyser/src/main/java/org/zowe/apiml/LocalVerifier.java#L66-L76

I am a little bit afraid the tool is doing too much (ie. remove verification https://github.com/zowe/api-layer/blob/v3.x.x/certificate-analyser/src/main/java/org/zowe/apiml/RemoteHandshake.java), but anyway, it could be a good entry point to replace verification feature. We can improve it for our purposes (list of verification, return code, etc.)

[pavel-jares-bcm]

I have created a small PR (zowe/api-layer#4017) to support more validation and test it locally. It seems that it is working well. If you decide to use it, we can also implement to parse zowe.yaml file and take the information from there (keystore + truststore, hostnames: externalDomain + LPARs, if cert validation is strict, if X509 is enabled, etc.).

[JoeNemo]

@1000TurquoisePogs is investigating this and some other approaches. Thanks for the info, @pj892031

[1000TurquoisePogs]

Thanks @pj892031 ! I will try this soon.
Do you know if certificate analyzer gets shipped in zowe today, and what versions of java it targets?

[pavel-jares-bcm]

It is not shipped as part of Zowe, but it is released (https://zowe.jfrog.io/artifactory/libs-snapshot-local/org/zowe/apiml/sdk/certificate-analyser/). The PR is in the v3 branch and uses Java 17 as the default. Anyway, it is not an issue to update also v2 (cherry-pick) to run with Java 8 as well.

[1000TurquoisePogs]

@pj892031 Which jar on jfrog corresponds to your new PR?

I got a few of the builds working (v2 and v3) but they don't seem to be from the PR.
So far I did

java -Djava.protocol.handler.pkgs=com.ibm.crypto.provider \
-jar certificate-analyser-3.2.2-20250124.152053-1.jar -l \
-k safkeyringjce://user/ZoweKeyring -kt JCERACFKS -kp password -a alias \
-t safkeyringjce://user/ZoweKeyring -tt JCERACFKS -tp password

It looks like this program tests more than just a certificate. It's also testing network connectivity. That's fine, but to be able to use it for startup verification it needs some more enhancement.

• It seems to pick a random port to listen on. Need to provide a port argument, then we can check against a specific Zowe port. Otherwise, companies will get permission denied a lot.

• --localhost is kind of what I want, but really it needs to take IP as an argument too. We'll provide 0.0.0.0 just like the rest of Zowe, but even that is customizable in latest Zowe.

• It appears to not exit when finished. that's not going to work for a startup check, it really needs to exit with rc=0 if successful, or non-zero if unsuccessful for whatever reason it prints out.

• Can the EKU check be a flag so that it is conditional? EKU is needed by APIML but if for some reason an environment was only using ZSS for example, its not required. Then the startup can pass the EKU flag depending on which components are enabled.

[pavel-jares-bcm]

The SNAPSHOT for the PR is available at https://zowe.jfrog.io/artifactory/libs-snapshot-local/org/zowe/apiml/sdk/certificate-analyser/3.1.12-PR-4017-SNAPSHOT/ . It is the version3 (Java 17).

As you mentioned the application offers more than you need. For the Zowe start-up, it is probably reasonable to make a local check. The provided arguments should be:

-t keystore/localhost/localhost.truststore.p12 # path to thr truststore
--keypasswd password # password to keyring / keystore
-k keystore/localhost/localhost.keystore.p12 # path to keyring / keystore
-a localhost # alias of server certificate
-d dvipa,lpar1,lpar2 # all used domains (each lpar + the external one)

The -l is trying to make local handshake. I guess it is more for analyzing of an issue. Do you really need to use that? I guess the static check of the certificate should be enough. Otherwise, we have to improve that.

Of course, we can add a flag to check additional EKU. But I guess to check 1.3.6.1.5.5.7.3.2 and 1.3.6.1.5.5.7.3.2 should be done always, right? Or shall we use these EKUs as the default value (if there is no EKU defined)?

[pavel-jares-bcm]

I would mention that there is a new issue. It is noticed that there is also a requirement for a certificate algorithm, see zowe/api-layer#4109

I have also added this validation into the Certificate Analyzer tool (zowe/api-layer#4121) and updated the docs (zowe/docs-site#4489)