End Entities

End entities represent an entity outside the boundaries of the PKI like a web server or a person. Modelling end entities in the RA application gives the possibility to manage and work with such logical entities within the PKI system instead of certificates. The advantage is that it provides the users of the PKI with a natural rather than technical method to manage and view the PKI.

For example, a web server requests a certificate via ACME three times. Using end entities it is possible to represent this server as an entity which has three certificates attached to it, instead of just having three certificates within the PKI that are not related to this web server, apart that they share the same domain name. Using end entities this relation is explicit rather than implicit. In the RA it is mandatory to attach all actions and certificates to an end entity.

An end entity needs a certain characteristic to be specified as such. For example, in the case of web server this characteristic could be the domain name of the server. This characteristic is the so-called alias. This is an identifier which is used to identify this end entity.

There are cases when it is not possible to provide the alias of the end entity and therefore create it or assign a certificate to it is not obvious. Typical example is the request for certificate by an end entity via a protocol like ACME or EST. It is not possible to provide this type of information within the protocol, at least in a standard conform way. Because an end entity always requires a unique alias a mechanism to create aliases for end entities in the system is necessary. This mechanism utilizes the so-called strategies, with each strategy providing a method to create an alias for the end entity. The different strategies are described in Chapter 3.

The alias of an end entity is set via the following methods and cannot be modified afterwards:

RA Operators can choose among the following end entity alias strategies.

Available end entities for a realm can be viewed and searched for in the End Entities page. An option to export selected rows as Comma Separated Values (CSV) is available via the Actions → Export selected as CSV, along with and option to Add password to the selected End Entities. There is also a filter that an admin can use to view only the archived end entities. This filter can be triggered by pressing the Show Archived button in the Actions dropdown list.

The New End Entity page can be reached via the side menu or via the Create… quick access button at the top right.

Here, some of the most common X.509 certificate components can be defined like: Common Name (CN), Country (C), E-Mail (E), Organisation (O), Organisational Unit (OU). Only Common Name (CN) is required, the rest are optional. Additionally, a list of domain names, and a list of ip addresses can be provided, for inclusion in the Subject Alternative Name (SAN) extension. An optional External ID can be given to the created end entity that can be used to store additional identification information. Lastly, the list Custom CA Parameters can be provided to pass additional certificate template parameters (ident data) to MTG CARA (Example id.data=custom-data).

End entity modification is not supported.

A user can archive or unarchive a policy by entering the End Entities/Show tab. There, by pressing the end entity’s name, the user will be redirected to the end entity details page. By pressing Archive or Unarchive button the end entity will be archived or unarchived accordingly. Batch Archive and Batch Undo-Archive actions are also supported by selecting the checkboxes of the desired end entities and choosing the Archive All Selected and Undo-Archive All Selected buttons in the Actions dropdown. Upon end entity archive all child entities of the end entity will be archived too. Child entities of end entities are considered its certificates and certificate requests. Upon unarchive, end entity’s child entities are not affected. End entities associated with an active certificate can not be archived. Archived end entities, that belong to an archived realm can not be unarchived. Archived end entities can not be used for new operations.

A user can delete an archived end entity through the End Entity page, the Show Entities Table or the Administration/Archived Data Removal tab. In the End Entity page after archiving the entity a Delete button will appear. In the Show Entities Table by pressing Actions→Show Archived the table will show the archived entities, and here the end entities can be selected, and through Actions→Delete all selected they can be deleted. Furthermore, the user can delete one End Entity at a time by pressing the row actions button and then Delete End Entity. Finally, in the Choose entity to delete dropdown choose End Entities. As an extra safeguard there is the option to restrict the archived records that are going to be deleted by the date on which they were archived. In the Choose date calendar select the date, before which the records should have been archived, in order to be deleted with this action and press Delete. Upon deletion, all archived certificates, certificate requests and all end entity passwords linked to the deleted end entities will also be deleted.

For one or more existing end entities, a password can be generated. This password, together with the end entity ID, enables the end entity to authenticate itself to MTG Certificate Lifecycle Manager Server. Each password is bound to an existing policy and enables the end entities to issue certificates for themselves using the assigned policy. For each policy only one password can be created per end entity. Note that multiple end entities can share a common password.

By pressing Add Multiple tab, a panel with a file upload field is shown. A template with instructions is available, in which a user can add multiple certificates for creation. On successful creation the user is redirected to the Create End Entity Password page, in order to create the same password for the created end entities.