PKI and signatures with protected keys.

The HSM protects a signing key within its intended boundary; it does not itself decide whether a software package should be approved for release. That is why we tie signing calls to identified applications, permissions and approvals. In code signing, the artifact and the approval are linked together, so that later changes are detectable. The CA software and the HSM provider must both support the algorithm and key access method in use. Trust stores, status checking and renewal are tested with representative counterparts.

A lost administrator card, expired certificates and a compromised issuing CA are different events. We create suitable procedures and test the agreed recovery path. Among other things, the acceptance test documents issuance, renewal, revocation and invalid requests. Existing certificate profiles, device classes and trust relationships help plan parallel operation during migration.

We check the integration supported by the respective product, for example through a CNG Key Storage Provider, PKCS #11 or a Java provider. An identical algorithm name alone does not guarantee compatibility: mechanisms, key attributes, padding and provider version must also match. For existing certificate authorities, we clarify whether a permitted key transfer is possible or whether a new CA with a transition phase is needed. The trust relationships of the connected systems are explicitly covered in the test.

The pipeline should not permanently hold a freely usable production key. We separate the build from the signing approval, bind jobs to an identified system and define which artifacts may be signed with which key. Timestamps, proof of the artifact hash and logging are planned to fit the signature format. Here, an HSM is a protective component: reviewing the code and deciding on a release remain tasks of the development and release process.

An organization already manages certificates for devices, users and internal services. OTOKO® records certificate profiles, distribution and trust chains, and first tests the intended HSM integration outside production. We then plan the switch-over, including renewal, revocation information and fallback boundaries. Before handover, specific counterparts are tested: an issued certificate is only a success once login, service access or signature verification works in the intended system.