Standardizing Cryptographic Asset Issuance

The Cost of Unenforced Certificate Issuance

Allowing system administrators or application owners to dictate certificate parameters ad hoc introduces severe operational risks. When certificates are requested manually, inconsistent key lengths, unapproved algorithms and unauthorized Subject Alternative Names (SANs) inevitably enter the enterprise environment. This lack of standardization leads to failed compliance audits, weakened cryptographic postures and difficult remediation efforts when deprecated algorithms are discovered in production.

Enforcing Standards with MTG CLM

MTG CLM solves this by abstracting cryptographic complexity away from the end user. By configuring authoritative policies, enterprise security teams mandate exact parameters before a certificate request is ever sent to a Certificate Authority (CA).

This enforces consistency across the enterprise. End users simply select an approved policy and MTG CLM automatically applies the mandated security controls, rejecting any non-compliant requests.

Functional Implementation

To simplify issuance, administrators configure policies within MTG CLM UI. A policy binds together three core components: the destination CA, the cryptographic template and the operational constraints.

Selecting the Certificate Provider

First, the policy is bound to a specific CA. Administrators route the policy to the appropriate infrastructure by selecting a certificate provider, such as MTG CARA for internal PKI or a public CA like GlobalSign or PSW.

Applying a Template Signer

A a pre-validated Template Signer is applied to dictate the technical structure of the certificate. MTG CLM includes native templates such as:

  • Code Signing Certificate: For software and application signing

  • Machine: Device and system certificates

  • Person: Individual user certificates

  • Server: Server authentication certificates

  • Custom: Tailored templates for specific requirements

This is to ensure proper field configuration and extensions.

Bind to an End Entity

In MTG CLM, all certificates must be attached to an end entity. The policy enforces that the issued certificate matches the identity data (Common Name, Organization, Locality, SANs, and IP addresses) statically defined in the end entity object, preventing rogue domain issuance.

Define Approval Workflows (Optional) For high-value assets, administrators can configure the policy to require manual approval or a four-eyes (dual-control) authorization process before the CA processes the request.

Business Value Summary

Operational Risk MTG CLM Mechanism Business Outcome

Rogue or unauthorized domains

Mandatory End Entity Binding

Prevents issuance of certificates for external or unauthorized hostnames by locking issuance to pre-approved End Entity data.

Weak cryptographic standards

Centralized Template Signers

Guarantees all issued certificates meet current enterprise cryptographic baseline requirements without relying on user knowledge.

Inconsistent CA routing

Policy-to-Provider Binding

Ensures internal certificates are automatically routed to private PKI and public certificates to commercial CAs, reducing misconfigurations.

Unauthorized issuance of critical assets

Integrated Approval Workflows

Enforces dual-control over sensitive certificates (e.g., Code Signing), satisfying strict compliance and regulatory audit requirements.
Related Sections