End Entities

End entities are the owners of certificates within the MTG-CLM ecosystem, representing the 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 (CN)

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

Country ©

The country code for the end entity.

E-Mail (E)

The email address associated with the end entity.

Organisation (O)

The organization name for the end entity.

Organisational Unit (OU)

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).

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 (DN):

  • Common Name (CN)

  • Organization (O)

  • Organizational Unit (OU)

  • Country ©

  • State or Province (ST)

  • Locality (L)

  • Email Address (E)

From Extensions:

  • Subject Alternative Names (SAN), 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.
After import, you will need to be manually enter fields not present in the CSR (such as External ID and Custom CA Parameters), if required for your use case.

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.

End Entity Passwords