End Entities

End entities are the owners of certificates within the MTG CLM ecosystem, representing real-world entities for which certificates are issued.

Examples of end entities

  • Web servers requiring SSL/TLS certificates

  • Individuals needing email or authentication certificates

  • Microservices requiring secure communication

  • IoT devices that need identity certificates

End entities exist within specific realms, creating a logical organization structure. Each realm can contain multiple end entities, but an end entity can only belong to one realm.

Purpose of End Entities

Comparison of Certificate Management Approaches
Without end entities With end entities

Certificates exist independently

Certificates are attached to their owners

No logical grouping by owner

Natural organization by entity

Relationships between certificates are implicit

Explicit relationships between certificates

Management focuses on technical certificate details

Management focuses on business entities

In a scenario where a web server named "api.example.com" needs multiple certificates over time:

Without end entities

You would see three separate certificates with the same domain name, but no explicit connection between them.

With end entities

You create one end entity "api.example.com" with three certificates attached to it, making the relationship clear and management more intuitive.

In MTG CLM it is mandatory to attach all actions and certificates to an end entity.

End Entity Fields

When creating an end entity in MTG CLM, you can define the following fields:

Common Name

The primary identifier for the end entity. This is the only required field.

Country

The country code for the end entity.

E-Mail

The email address associated with the end entity.

Organisation

The organization name for the end entity.

Organisational Unit

The organizational unit within the organization.

Domain Names

A list of domain names to be included in the Subject Alternative Name (SAN) extension.

IP Addresses

A list of IP addresses to be included in the Subject Alternative Name (SAN) extension.

External ID

An optional identifier that can be used to store additional identification information.

Custom CA Parameters

Additional certificate template parameters (ident data) that can be passed to MTG CARA (e.g., id.data=custom-data).

Locality

Specifies the city, town, or geographical area where the entity is located.

State

The State or Province field defines the broader regional jurisdiction, such as a state, province, or territory, associated with the entity’s physical location.

Serial Number

The Serial Number is a unique, positive integer assigned by the Certificate Authority (CA) to each issued certificate. It guarantees that no two certificates issued by the same CA share the same identifier.

Configurable Fields

MTG CLM administrators can define which data fields are available for end entities on a per-realm basis. Only enabled fields can be populated when creating an end entity within that specific realm. The Common Name field is universally required and cannot be disabled in any realm.

The availability of end entity fields is managed within the realm configuration:

  • Default State: In every realm, the fields Common Name, Country, E-Mail, Organisation, Organisational Unit, Domain Names and IP Addresses are enabled by default

  • Default Values: MTG CLM administrators can configure default values for any enabled field. If an end entity is created without explicitly providing a value for an enabled field, the system automatically applies the predefined default value.

Modifying Field Configurations

Enabled fields can be disabled at the realm level, provided no existing end entity within that realm currently uses the field. If an attempt is made to disable a field that is already populated in one or more existing end entities, the system blocks the action and returns an error.

Filling Data from PKCS#10 Requests

When creating an end entity, you can simplify the process by filling data directly from an existing PKCS#10 Certificate Signing Request (CSR). This approach ensures accuracy and consistency between the requested certificate and the end entity record in MTG CLM.

The system supports parsing PKCS#10 requests in two formats:

  • Plain text format: The raw CSR content.

  • PEM format: The Base64-encoded CSR with header and footer (BEGIN/END CERTIFICATE REQUEST).

When you press the Fill data from PKCS button the system:

  • Analyzes the PKCS#10 file to identify available fields.

  • Extracts information from both the Subject Distinguished Name (DN) and extensions.

  • Automatically populates corresponding end entity fields with the extracted data.

The system can extract and map the following information:

From Subject Distinguished Name :

  • Common Name

  • Organization

  • Organizational Unit

  • Country

  • State or Province

  • Locality

  • Email Address

From Extensions:

  • Subject Alternative Names (including domain names and IP addresses). Critical for modern certificates, especially for web servers, ensuring your certificates work properly across all browsers and devices.

  • Other certificate extensions present in the CSR.

The fields populated depend entirely on what’s present in the PKCS#10 file. Some CSRs may contain only a few fields, while others may contain most or all possible fields.
If required for your use case, you will need to manually enter fields that are not present in the CSR (such as External ID and Custom CA Parameters) post import.

This capability is particularly valuable when integrating with existing certificate request workflows or when migrating from another PKI system. It reduces manual data entry errors and ensures that the end entity accurately reflects the certificate that will be issued.

Related Sections