Policies

Available policies for a realm can be viewed and searched for in the Policies page. An option to export selected rows as Comma Separated Values (CSV) is available via the Actions → Export selected as CSV. There is also a filter that an admin can use to view only the archived policies. This filter can be triggered by pressing the Show Archived button in the Actions dropdown list. A user also view the connected with a certificate provider policies through the available tables in the Certificate Provider Details page.

The New Policy page can be reached via the side menu or via the Create…​ quick access button at the top right. Required fields are the name for the new policy, the certificate provider along with the required MTG CARA template signer that should be used with this policy and the end entity strategy to be used for this policy, that defines how the end entity alias is generated upon certificate creation. For the MTG CARA template signer the user can also use the Include RA Template Signers checkbox to include the RA template signer options for the selection.

The manual approval required field is responsible for the certificate creation procedure. If No is selected, the certificate is issued immediately, otherwise an authorized user must approve or decline the certificate request in the Certificate Requests section. The Dual Control field is used along with the manual approval required. If both are set to true, two different authorized users must approve the specific certificate request under the two-man rule. In case that manual approval required is set to false this field will be ignored.

The E-mail verification required field enables end entity email verification. Upon certificate creation, if the selected policy has E-mail verification required set to true, an email will be sent to the end entity’s associated email with a link to verify the email possession. While the end entity has not verified its email address, the certificate request status is set to REQUIRES_EMAIL_VALIDATION. In case the end entity does not have an email, the email verification step will be skipped.

The Enforce Active Certificate Uniqueness field adds the restriction that no more than one active Certificates can exist for the same End Entity at the same time with the exception of a specified amount of days before they expire for renewal purposes. The field Enforce Active Certificate Uniqueness Before Expiration In Days defines that number of days so no two Certificates can be issued for one End Entity before one reaches the last N days of its active period. Also, an appropriate error will be displayed when trying to create a Certificate that does not apply to the above restriction.

The user can check the Enable CMP checkbox to make the Policy available to be used with CMP. By pressing the checkbox the required CMP Certificate Provider field will appear which specifies the concrete mechanisms that are used to perform signing operations when using the Policy through CMP. After setting a certificate provider two additional required fields appear, the CMP Signer ID that specifies the ID of the Signer in CARA that will operate the signing, and the CMP Signature Algorithm that specifies the algorithm that will be used for the signing operation.

Furthermore, the Allowed Valid For Values, Allowed Key Pair Modes, Allowed Crypto Algorithms, Allowed RSA Key Sizes and Allowed EC Named Curves can be specified. When no values are selected in these fields, by default, all values will be available upon certificate creation. Otherwise, only the chosen values will be available when a user creates a certificate with this policy.Finally, the user can check the Set End Entity Rules checkbox and set restrictions for the selected End Entities upon certificate creation. This means that if a policy with end entity rules is selected while creating a certificate, the second step, which is End Entity selection, will have to obey these restrictions. The user may also use Java Regular Expressions (Regex) to set a broader range of such restrictions. A Regular Expression is a sequence of characters that form a pattern, used to describe what a search operation shall return. For example the dot symbol (.) in a Regular Expression matches any character. In practise that means that when a user sets an End Entity Rule as 'exampl.', then the corresponding End Entity field can be set to any values that meet that rule, e.g. 'example' or 'exampla' or even 'exampl1'. For a detailed documentation in Java Regex follow the link: docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

A user can modify a Policy by entering the Policies/Show tab. There, by pressing the Policy’s name, the user will be redirected to the Policy details page. An Edit button is available here, which starts the Edit functionality. Then, by pressing Cancel the Policy values return to the original ones, otherwise by pressing Save the Policy updates.

The following fields can be modified: Name, Certificate Provider, Allowed Valid For Values, Allowed Key Pair Modes, Allowed Crypto Algorithms, Allowed RSA Key Sizes, Allowed EC Named Curves, Enforce Active Certificate Uniqueness, Enforce Active Certificate Uniqueness Before Expiration In Days, Enabled CMP and End Entity Rules. Additionally, when the selected certificate provider for the policy is of type MTG CARA then the Template Signer field is available for modification and when the enabled CMP is active and the certificate provider is of type MTG CARA then the Signer ID and CMP Signature Algorithm are available for modification.

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

A user can delete an archived policy through the Policy page, the Show Policies Table or the Administration/Archived Data Removal tab. In the Policy page after archiving the entity a Delete button will appear. In the Show Policies Table by pressing Actions→Show Archived the table will show the archived entities, and here the policies can be selected, and through Actions→Delete all selected they can be deleted. Additionally, the user can delete one Policy at a time by pressing the row actions button and then Delete Policy. Finally, in the Choose entity to delete dropdown choose Policies. 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 certificates and certificate requests linked to the deleted policy will also be deleted. All end entity passwords that are linked to the policy will be deleted. Furthermore, if the deleted policy is the default policy of an API client the default policy will be unset. Only archived policies can be deleted.