Certificate Providers
To issue digital certificates, MTG CLM connects to various Certificate Authorities (CAs). A Certificate Provider acts as the dedicated connection or integration between MTG CLM and these underlying CAs.
Configuring certificate providers allows your organization to centralize certificate requests. Instead of manually interacting with different internal servers or external public CAs, users can request, issue and manage all certificates from a single interface. Once a provider is selected in a policy, it dictates exactly where those certificate requests are routed.
|
Certificate providers are configured on a per-realm basis. You can assign and manage the available providers for a specific realm during its initial creation, or modify them later by editing the realm’s settings. |
|
MTG CARA is the native certificate provider for MTG CLM.
It is always present and pre-configured in the |
Managing Certificate Providers
Providers can be created, modified, archived and deleted according to any evolving PKI needs.
-
Creation & Modification: When creating a provider, you must define its Name, Type and type-specific connection parameters.
| Once created, the provider’s Type cannot be changed. |
-
Connection Testing: MTG CLM checks the connection to all providers upon application startup. You can also trigger a manual Check Connection at any time to troubleshoot pending or failing requests.
-
Archiving & Deletion: Providers must be archived before they can be deleted. If a provider is currently linked to active Policies, you must first reassign those policies to a new provider (or archive the policies) before the system will allow you to archive the provider.
Provider Capabilities and Limitations
Because each underlying CA operates differently, not all cryptographic algorithms, request modes or integrations are supported by every provider. When selecting a provider for your policies, make sure to review the following limitations.
Supported Certificate Request Modes
MTG CLM can process certificate requests in three ways:
-
PKCS#10: The client generates the key pair and submits a standard Certificate Signing Request (CSR).
-
Server-side key pair: MTG CLM generates and securely delegates the key creation.
-
Public Key: The public key is provided in raw format.
| PKCS#10 | Server-side key pair | Raw Public Key | |
|---|---|---|---|
MTG CARA |
YES |
YES |
YES |
Microsoft NDES |
NO |
YES |
NO |
Microsoft CA |
YES |
YES |
NO |
GlobalSign |
YES |
YES |
NO |
PSW |
YES |
YES |
NO |
Supported Cryptographic Algorithms
The following table outlines which cryptographic algorithms can be used with each provider type.
| RSA | ECC | EdDSA | |
|---|---|---|---|
MTG CARA |
YES |
YES |
YES |
Microsoft NDES |
YES |
NO |
NO |
Microsoft CA |
YES |
NO |
NO |
GlobalSign |
YES |
YES |
NO |
PSW |
Depends on PSW product |
Depends on PSW product |
Depends on PSW product |
Supported ERS Components
There are several ERS components that integrate with MTG CLM, like MTG EST, MTG SCEP, etc. For MTG CARA certificate provider all components are supported. Due to internal limitations of other providers and special properties of different PKI protocols, it is not always feasible to use these components with other providers than MTG CARA. Specifically, MTG SCEP server, MTG CMP server and MTG Auto-Enrollment Connector are exclusively supported by MTG CARA certificate provider, since they require signing or encryption/decryption of data, operations that are not available for providers of different type.
| ACME | EST | SCEP | CMP | AEC | |
|---|---|---|---|---|---|
MTG CARA |
YES |
YES |
YES |
YES |
YES |
Microsoft NDES |
YES |
YES |
NO |
NO |
NO |
Microsoft CA |
YES |
YES |
NO |
NO |
NO |
Globalsign |
YES |
YES* |
NO |
NO |
NO |
PSW |
YES |
YES* |
NO |
NO |
NO |
PCSP |
YES |
YES* |
NO |
NO |
NO |
*For providers that do not allow downloading the CA chain before certificate issuance, it might be necessary to previously download the CA chain, import the CA certificates in CLM and configure them as additional CAs for the policy in use.