Secure Software Manager
New/Enhancements
CSR generation support from API and UI - To better support end entity certificate issuance from non-Digicert managed PKI hierarchies, SSM has now extended the CSR generation for SSM protected keypairs both in secure disk and on HSM. This will allow users to get CSRs for their protected keys and bring those CSRs to other CA service providers like in popular use-cases for Apple CA and Microsoft CA amongst others.
Advanced GPG Signing Workflows - Building upon the June MVP release for GPG Keypairs, in this release we now bring more keypair feature parity for GPG Keypairs as is the case for traditional keypairs. GPG Keypairs now accommodate keypairs being brought online and offline as well as support for keypair deletion. We have also introduced capabilities for GPG keypairs to be created on HSM to complement the secure key storage, but please note HSM keypairs do not support import or export now or in the future. Finally, we have brought parity to GPG Test Keypairs whereby test keys will expire after 30 days like is the case with traditional keypairs.
Manual Refresh of dynamic and rotation pool keys - In this release, we have given SSM users additional optional manual controls to help tailor their signing workflows for dynamic keys and rotation keys. As a result, users can now refresh their dynamic keys at any time via the SSM UI, via SSM APIs or by using the SMCTL (CLI) which will give users confidence that the key and certs being used to sign have now been used before. We also delivered equivalent functionality for Keypair rotation pool, where if required users can force the keypair rotation ahead of the planned rotation schedule via the SSM UI, via SSM APIs or by using the SMCTL (CLI).
SMCTL Sign no longer requires user to provide local cert for windows signing - Until this release, users undertaking Microsoft signing had to either sync the certificate to their certificate store or download the public version of the certificate to allow for signing using Signtool, Nuget, Mage etc… We have now removed the burden on the customer to download/sync the cert before signing when our users use the SMCTL to sign. Going forward, users who use the most recent SMCTL release just need to supply the keypair alias relative to signing and our SMCTL will download the current default certificate associated with the keypair so that it can be used for signing. This process works for static keypairs (production and test), dynamic keypairs (production and test) and keypairs rotation pools (production only).
SSM doc updates
Circle CI/CD SSM integration for PKCS11 - Extending our support for CircleCI, we have now documented workflows to show integration with SSM PKCS11 client here
GitHub Actions CI/CD SSM integration for PKCS11 - Extending our support for Github Actions, we have now documented workflows to show integration with SSM PKCS11 client here
Container signing with CoSign and Sigstore - SSM has the capability to integrate with CoSign and Sigstore for key protected signing workflow and have documented those integration steps here
Open Container Inferface (OCI) signing with Podman - With the introduction of our SSM-SCD, we can now support an integration with Podman which supports secure signing workflows for Open Container standard as documented here
Osslsigncode signing with PKCS11 - For Linux customers with a requirements of large file signing of Authenticode formatted files, OSSLSigncode is a great alternative to Jsign and integration instructions are clearly documented here
Fixes
New version of SSM App in the Azure DevOps Marketplace Our SSM app in the Azure DevOps Marketplace was showing some vulnerable libraries messages and the team took action to release new version v1.4.0 on 29th June to replace the libraries in question. The new version of the app can be downloaded here.
Dynamic test keypair refresh bug fix - A bug was noted in relation to the certificates associated with test dynamic test keypairs not getting refreshed when the dynamic test keypair cert expired. This bug has now been addresses and the dynamic test key and associated certs will both now be refreshed when either the key expires or the cert expires, whichever happens first.