Enhancement: Add Optional Expiration Date Validation for Certificates in JS7 Encryption/Decryption Scripts

Current Behavior

JS7 encryption/decryption (such as from PowerShell cmdlets and from Shell scripts) makes use of JS7 Java classes that allow use of expired certificates for encryption operations. The corresponding private key can be used for decryption. The Java classes do not currently validate a certificate’s expiration date.

A certificate can expire, but that does not mean that it is invalid for cryptographic operations. Expiration mainly indicates the period during which the certificate can be trusted for identity verification. However, cryptographic operations like encryption and decryption rely on the underlying key material, which remains valid beyond a certificate’s expiration date as long as the private key is not changed. There is no security issue from the fact that an expired certificate is used.

Similarly, our current encryption/decryption Java classes focus on the usability rather than enforcing certificate expiration checks. It is up the user to verify certificate expiration and to renew certificates in good time.

Desired Behavior

Introduce an optional, configurable check in the JS7 encryption/decryption Java classes to validate a certificate’s expiration date before performing cryptographic operations. The change will be made available for Shell Scripts and PowerShell cmdlets used for encryption/decryption. Java classes, Shell Scripts and PowerShell cmdlets are added the following cmdline switch: 

--check-expiration

Making this check optional provides flexibility, allowing users to enforce stricter validation as needed to comply with their internal security policies. Users who apply strict expiration checks should be aware that encryption jobs will fail with the day on which the certificate becomes valid or expires.