--- version: "8.15" language: "en" --- # Nexus Certificate Manager ## Documentation * ### [Certificate Manager news](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-news.md) * [Certificate Manager release notes](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-release-notes.md) * [Supported versions of Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/supported-versions-of-certificate-manager.md) * ### [Certificate Manager overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-overview.md) * [Certificate Manager architecture overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-architecture-overview.md) * [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md) * [Certificate Manager clients](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-clients.md) * [Certificate Manager interfaces and APIs](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-interfaces-and-apis.md) * [Common Criteria certification for Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/common-criteria-certification-for-certificate-manager.md) * ### [Certificate Manager - requirements and interoperability](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-requirements-and-interoperability.md) * [CM 8.15.x - Requirements and interoperability](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cm-8-15-x-requirements-and-interoperability.md) * [CM requirements and interoperability - earlier versions](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cm-requirements-and-interoperability-earlier-versions.md) * ### [Install Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate-manager.md) * [Recommended setup of Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/recommended-setup-of-certificate-manager.md) * [Configure database for use with Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/configure-database-for-use-with-certificate-manager.md) * [Install Certificate Manager server components on Kubernetes](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate-manager-server-components-on-kubernetes.md) * [Install Certificate Manager server components using Podman](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate-manager-server-components-using-podman.md) * [Migrate existing CM installation to Podman](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/migrate-existing-cm-installation-to-podman.md) * [9 more pages](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate-manager.md) * ### [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Authority types in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-types-in-certificate-manager.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Use cases in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/use-cases-in-certificate-manager.md) * ### [Registration officer tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-officer-tasks-in-certificate-manager.md) * [General certificate tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/general-certificate-tasks-in-certificate-manager.md) * [Smart card tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/smart-card-tasks-in-certificate-manager.md) * [Software token tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/software-token-tasks-in-certificate-manager.md) * [Attribute certificate tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/attribute-certificate-tasks-in-certificate-manager.md) * [PIN/PUK letter tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/pin-puk-letter-tasks-in-certificate-manager.md) * [2 more pages](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-officer-tasks-in-certificate-manager.md) * ### [Certificate Manager system administration](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-system-administration.md) * [Start Certificate Manager server components](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/start-certificate-manager-server-components.md) * [Backup and restore of Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/backup-and-restore-of-certificate-manager.md) * [Administer system keys in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administer-system-keys-in-certificate-manager.md) * ### [Certificate Manager integrations](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-integrations.md) * [PKIMetal linting in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/pkimetal-linting-in-certificate-manager.md) * [Use the Secure Key Injection Protocol in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/use-the-secure-key-injection-protocol-in-certificate-manager.md) * ### [Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md) * [Install Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-protocol-gateway.md) * [Initial configuration of Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/initial-configuration-of-protocol-gateway.md) * [Configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/configuration-in-protocol-gateway.md) * [Configuration examples in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/configuration-examples-in-protocol-gateway.md) * [Configure Tomcat for TLS client authentication in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/configure-tomcat-for-tls-client-authentication-in-protocol-gateway.md) * [2 more pages](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md) * ### [Certificate Manager Web UI](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-web-ui.md) * [Certificate Manager Web UI news](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-web-ui-news.md) * [Overview of Certificate Manager Web UI](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/overview-of-certificate-manager-web-ui.md) * [Install Certificate Manager Web UI](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate-manager-web-ui.md) * [Certificate Manager Web UI communication flow](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-web-ui-communication-flow.md) * [Open source components in Certificate Manager Web UI](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/open-source-components-in-certificate-manager-web-ui.md) * [2 more pages](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-web-ui.md) --- version: "8.15" language: "en" --- # acme.properties This article is valid for Certificate Manager 8.4.1 and later. The ***acme.properties*** file contains the configuration parameters used by the ACME servlet. ## **Request URL** http://[:]/pgwy/acme/ Relative paths specified below are relative the ***\***. ## ***\*** path The ***\.properties*** file are stored in the ***\*** path. ***\*** corresponds to the following paths: ### **Windows \** %ALLUSERSPROFILE%/Nexus/cm-gateway/ #### **Linux \** /var/cm-gateway/ ## Parameters | **Parameter** | **Description** | |-------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | start | Controls if the ACME servlet should start or not. XML start = false | | tokenProcedure | The token procedure name that will be used to issue certificates from CF. | | orderExpiryDuration | The amount of time that an ACME order is valid until it expires. | | externalAccountRequired | If true, will require that ACME clients include a value for externalAccountBinding when creating new ACME accounts. When using certbot as ACME client, this is done with the --eab-kid and --eab-hmac-key parameters. This also requires that the keyid and HMAC key is pre-registered in CF before the ACME account can be created. | | baseUrl | By default, the ACME directory url will give paths to the caller by examining the URL of the incoming request. If the URL of the incoming requests is not the same as the externally accessible URLs for this installation, such as if the incoming requests have been re-written by a load-balancer, then it is possible to configure a base url here, that will be used in all URL responses. | | nonceSize | The size, in bytes, of the random nonce that is requested from CF for use in ACME protocol messages. Minimum value 16, max value 21. | | nonceExpiryDuration | The amount of time that a nonce that is created by CF is valid until it expires and is allowed to be removed from the CF DB by cleaning process. | | addAccountContactEmail | If true, adds the contact email address from the requesting account to the Rfc822 name field to the SAN extension in the certificate request. | ## Define handlers The parameter values in the default section are used by all handlers unless overridden in the handler section. ### **Example: default values for handlers** #default.orderExpiryDuration = PT10M #default.externalAccountRequired = false #default.baseUrl = https://example.localdomain:8443/pgwy/acme #default.nonceSize = 16 #default.nonceExpiryDuration = P1D #default.addAccountContactEmail = false Each handler defines a mapping between the filter (from the URL) and the ACME directory that should process each filter. #### **Example: handlers** handler.0.filter = directory handler.0.format = acme/directory handler.0.tokenProcedure = ACME TLS Web Server Token ## Multiple CAs It is possible to support multiple token procedures and thereby multiple CAs. To configure Protocol Gateway to use ACME with different CAs, more than one ACME directory handler can be configured in ***acme.properties*** with different token procedures: ### **Example: Multiple CAs** #handler.1.filter = directory-for-other-ca #handler.1.format = acme/directory #handler.1.tokenProcedure = Token Procedure from other CA ## Identity Manager tenant To issue certificates using an Identity Manager tenant, configure like this: ### **Example: IDM tenant** #handler.1.filter = idm/directory #handler.1.format = acme/directory #handler.1.tokenProcedure = ACME Order Registration #handler.1.idm.tls.token = client-tls.p12 #handler.1.idm.tls.password = abcd1234 #handler.1.idm.certTemplate = ScmCtServerCertificateP10 #handler.1.idm.requestUrl = https://example.idm:18444/prime_explorer/ws/processes/{{\ process }}/start?tenantId={{ tenant }}&task={{ taskId }} Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # ACME support in Certificate Manager This article is valid for Certificate Manager 8.1 and later. For more information about the support for the protocol Automatic Certificate Management Environment (ACME) in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM), see: * [What is ACME?](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/what-is-acme.md) * [Request certificate via ACME and Protocol Gateway in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/request-certificate-via-acme-and-protocol-gateway-in-certificate-manager.md) * [Manage ACME accounts in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/manage-acme-accounts-in-certificate-manager.md) ## Additional information Useful links * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Smart ID Identity Manager](https://doc.nexusgroup.com/pub/smart-id-identity-manager.md) * [Example: ACME configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-acme-configuration-in-protocol-gateway.md) * [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555) * [ACME Client Implementations](https://letsencrypt.org/docs/client-options/) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Activate OCSP in Certificate Manager for reporting of certificate status This article describes how to activate [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM) in order to report certificate status via OCSP for certificates produced by CM. This task is done in [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md). ## Prerequisites This task requires that: * The Certificate Controller (CC) is running. * The officer has the following role: * Manage OCSP Activation * Enough information is known to identify the certificate in the database. ## Activate OSCP 1. To locate the certificate(s), enter the search criteria in the **Search** pane in the [CC user interface in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cc-user-interface-in-certificate-manager.md) and click **Search**. The matching certificates will appear in the upper half of the result pane. 2. Open the **Action** drop down list and select the operation **OCSP Activation**. 3. Select one or more certificates in the upper half of the result pane. (Press the Ctrl key on the keyboard to make multiple selections.) 4. Click **Add** to move the certificate(s) to the lower half of the result pane. 5. Click **Submit**. 6. Enter your PIN code in **Signature PIN**. 7. Click **OK**. ## Related information * [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md) * [CC user interface in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cc-user-interface-in-certificate-manager.md) * [Connect to a Certificate Manager host](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/connect-to-a-certificate-manager-host.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Search for certificates in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/search-for-certificates-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # ActiveEntitiesTool command-line tool in Certificate Manager This article is valid for Certificate Manager 8.4 or later. ActiveEntitiesTool is a command based tool in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md), used to count the number of current active certificates, which were issued by CAs that belong to the provided domain and its subdomains in the provided time period. ActiveEntitiesTool also counts the number of distinct subject entries connected to them. The tool counts the distinct SubjEntryNr in Certificates table which results in having an offset in corner cases, for example, a device could have two certs with two different SubjCommonName, hence two SubjEntryNr. ## Location The program is located in the ***\/tools*** directory relative to where CM is installed. ## Commands `help` Shows the help text. `domain` The domain to search in. `from` Limits the search starting from this date. The date should be in ISO-8601 format, for example, 2011-12-03T10:15:30, in system time zone. `today` Counts only active entities issued today. ## Use ActiveEntitiesTool Example 1 - counts the number of distinct subjects and active certificates which were issued by CAs under 'System Domain' from date 2020-01-01T00:00:00 until now. java -jar cm-tools.jar ActiveEntitiesTool -domain "System Domain" -from "2020-01-01T00:00:00" Example 2 - counts the number of distinct subjects and active certificates which were issued by CAs under 'System Domain' today. java -jar cm-tools.jar ActiveEntitiesTool -domain "System Domain" -today Example 3 - counts the number of ALL distinct subjects and active certificates which were issued by CAs under 'System Domain'. java -jar cm-tools.jar ActiveEntitiesTool -domain "System Domain" ## Configure ActiveEntitiesTool Use the following environment variable to configure ActiveEntitiesTool: | **Environment variable** | **Description** | |--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | CM_HOME | (optional) Specifies a directory where the CM configuration is installed, usually referred to as ***\*** . Specifying this environment variable allows the program to use database connection details from ***cm.conf*** if placed in a nonstandard location. If this environment variable is not specified, and the program is placed in the default directory of ***\/tools***, the program will automatically find the CM configuration and the database connection details. | Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Administer system keys in Certificate Manager This article describes how to replace keys and certificates in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). ## Run Bootstrap procedure During the installation of a new system, you shall run the bootstrap procedure, see [Bootstrap Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/bootstrap-certificate-manager.md). During the bootstrap procedure, all keys and certificates delivered with the system are replaced. This enables the site to control the expiration dates of the system certificates. The keys and certificates can be stored in an HSM or stored as software tokens. ### Update or replace certificates For client security policy reasons, and since system certificates have expiration dates, you may need to update or replace the certificates in order for the system to function correctly. ### Keep track of expiration dates To keep track of expiration dates for certificates, you can: * Check expiration dates for officer, CA and TLS server certificates using the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). * Use [Expiry Check Service](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/configure-expiry-check-service-in-certificate-manager.md) (ECS) to detect and renew system certificates. (See Technical Description for more information.) ### Decide what action to take The following table indicates situations where system certificates must be changed and what actions to take in order to replace them. ### Decide actions for certificate replacement Click the links to see descriptions of the different tasks to perform. | **Situation** | **Reason** | **To perform** | | **Change to a new CA certificate** | Replace the keys and certificates issued by Nexus. | Run [bootstrap procedure](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/bootstrap-certificate-manager.md) | | **Change to a new CA certificate** | | **Change to a new CA certificate** | |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------| | The CA certificate is about to expire and must be replaced. | Run task [task 1](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-1-change-to-new-ca-in-certificate-manager.md), [task 2](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-2-change-to-another-existing-ca-in-certificate-manager.md), [task 3](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-3-change-tls-server-certificate-in-certificate-manager.md) and/or [task 4](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-4-generate-new-system-key-for-pin-encryption-in-certificate-manager.md) | | Client security policy reasons. | Run task [task 1](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-1-change-to-new-ca-in-certificate-manager.md), [task 2](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-2-change-to-another-existing-ca-in-certificate-manager.md), [task 3](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-3-change-tls-server-certificate-in-certificate-manager.md) and/or [task 4](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-4-generate-new-system-key-for-pin-encryption-in-certificate-manager.md) | | Client security policy reasons. | | The TLS server certificate is about to expire and must be replaced. | Run [task 3](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-3-change-tls-server-certificate-in-certificate-manager.md) | | Client security policy reasons. | Run [task 3](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-3-change-tls-server-certificate-in-certificate-manager.md) | | The PIN encryption key certificate is about to expire and can be replaced. **Note!** The expiration date of the PIN encryption key certificate is not used by Certificate Manager. Any pre-personalized cards can be used even though the PIN certificate has expired. | Run [task 4](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-4-generate-new-system-key-for-pin-encryption-in-certificate-manager.md) | | Client security policy reasons. | Run [task 4](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-4-generate-new-system-key-for-pin-encryption-in-certificate-manager.md) | | The KEK certificate is about to expire and must be replaced. | Run [task 5](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-5-generate-new-kek-for-kar-in-certificate-manager.md) | | Client security policy reasons. | Run [task 5](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-5-generate-new-kek-for-kar-in-certificate-manager.md) | ## Related information * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Bootstrap Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/bootstrap-certificate-manager.md) * [Task 1 - Change to new CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-1-change-to-new-ca-in-certificate-manager.md) * [Task 2 - Change to another existing CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-2-change-to-another-existing-ca-in-certificate-manager.md) * [Task 3 - Change TLS server certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-3-change-tls-server-certificate-in-certificate-manager.md) * [Task 4 - Generate new system key for PIN encryption in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-4-generate-new-system-key-for-pin-encryption-in-certificate-manager.md) * [Task 5 - Generate new KEK for KAR in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/task-5-generate-new-kek-for-kar-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Administration tasks in Certificate Manager This article describes the [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) (CM). The tasks are done by administration officers in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). Certification of all officers is based on an already existing smart card or software key with an associated end-user certificate. In addition to the traditional end-user certificate, all officer data is stored in the CM database. In the CM clients, including AWB, the functions available depend on the roles given in assigned officer profile, see [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md) and [Create officer profile in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-profile-in-certificate-manager.md). ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Create officer in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-in-certificate-manager.md) * [Create officer profile in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-profile-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Administrator's workbench (AWB) The [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) is used by administration officers for setting up CA-unique configurations. ## Tasks done in AWB Instructions for all tasks that are done in the AWB can be found here: * [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md). ## More information * [AWB user interface in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/awb-user-interface-in-certificate-manager.md) * [Change operation mode of Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/change-operation-mode-of-certificate-manager.md) * [Start a second instance of AWB in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/start-a-second-instance-of-awb-in-certificate-manager.md) * [Customize format in AWB](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/customize-format-in-awb.md) * [Export items from Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/export-items-from-certificate-manager.md) * [Import items to Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/import-items-to-certificate-manager.md) * [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Allowed domain names for preregistration in Certificate Manager This article is valid for Certificate Manager 8.1 and later. When creating a pre-registration, you can also define a comma-separated list of domain names for which a client is allowed to request certificates. If the list of domain names in a pre-registration is empty, then all domain names are allowed. Challenge validation must still be completed even if the list of domain names is empty. Any requested domain name whose suffix matches one of the domain names in the pre-registration is allowed. ## Examples These are examples of values for domain names: | **Pre-registration** | **Requested domain name** | **Outcome** | |-----------------------------|---------------------------|-----------------------------------------------------------------------| | example.com | example.com | OK | | example.com | nexusgroup.com | Not allowed | | example.com, nexusgroup.com | cm.example.com | OK, requested domain name has a suffix allowed by the preregistration | | example.com, nexusgroup.com | nexusgroup.com | OK | | example.com, nexusgroup.com | nexusgroup.se | Not allowed | Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Attribute certificate tasks in Certificate Manager This article lists the attribute certificate (AC) tasks that are done by registration officers in [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM), using both the [Registration Authority (RA) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-authority-ra-in-certificate-manager.md) and the [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md). ## Attribute certificates Attribute certificates are signed objects that assert additional properties with respect to some identity certificate (also called base certificate). An attribute certificate has no associated key pair and consequently cannot be used to establish identity. Attribute certificates can be thought of as extensions to identity certificates, even if the attribute certificate may be signed by a different CA than the base certificate. When the associated attributes are mainly used for the purpose of authorization, an attribute certificate is called **authorization certificate** . Attribute certificates typically have a much shorter lifetime than X.509 certificates. [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) supports attribute certificates version 2, as specified in [RFC 3281](https://tools.ietf.org/html/rfc3281), as well as the ***No Revocation Available*** (`NoRevAvail`) extension as specified in [RFC 5755](https://tools.ietf.org/html/rfc5755). An attribute certificate format with this extension is included in the Certificate Manager installation. An attribute certificate with the `NoRevAvail` extension is not possible to revoke. ## Related information * [Certificate Manager clients](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-clients.md) * [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Registration officer tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-officer-tasks-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Audit tasks in Certificate Manager This article is valid for Certificate Manager 8.0 and later. These articles describe the audit tasks within [Nexus](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md)[Smart ID Certificate Manager](https://nexusdoc.atlassian.net/wiki/pages/createpage.action?spaceKey=ncm&title=Smart%20ID%20Certificate%20Manager&linkCreation=true&fromPageId=1447467155) (CM). Audit notifications are generated by the component parts of the Certificate Factory (CF) and all significant actions performed by or within the system are logged. The tasks are done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Nexus](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md)[Smart ID Certificate Manager](https://nexusdoc.atlassian.net/wiki/pages/createpage.action?spaceKey=ncm&title=Smart%20ID%20Certificate%20Manager&linkCreation=true&fromPageId=1447467155) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Authentication and preregistration for EST This article is valid for Certificate Manager 8.4 and later. Security in EST is handled through client certificate authentication. HTTP-based authentication as client authentication is only supported if the device has been pre-registered by an administrator and the communication occurs over TLS. For more information, see [Device preregistration for automated enrollment](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/device-preregistration-for-automated-enrollment.md). HTTP Basic or Digest Authentication can also be implemented directly in the Tomcat instance, but then Protocol Gateway still requires a valid client certificate to issue any certificate to the device. Instead of the intermediate RA being assigned with an RA certificate, it can use a certificate that has a CM officer role. Therefore, the extension `id-kp-cmcRA`, has been left out. ## Certificate verification in simpleenroll The EST endpoint `/simplereenroll` uses a format that checks that the PKCS#10 request is for the same subject as the used client certificate. This means that to use this function, the clients require certificates with the extended key usage ***Client Authentication***. Protocol Gateway also verifies that the client certificate has not been revoked. For a configuration example, see [Example: EST configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-est-configuration-in-protocol-gateway.md). ### Match last issued certificate The `/simplereenroll` endpoint can also be configured to require that the used client TLS certificate matches the last issued certificate for the requested subject. To enable this, set allowRenewalWithOldCertificates to 'true' in the configuration file [est.properties](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/est-properties.md). * If `dNSName` and `iPAddress` is not set in the PKCS#10 request to an EST enrollment endpoint, they will be set by copying from `unstructuredName/commonName` and `unstructuredAddress`. * If `commonName` is not set in the PKCS#10 request it will be set by copying from `dNSName`. ### EST with authentication certificates The `/simpleenroll` endpoint can be set up to require a preregistered authentication/factory certificate matched to the commonname of the incoming request. To configure this requirement, set the following fields on the certificate procedure connected to the token procedure of the configured simpleenroll handler: * Certificate format: `estenroll` * Custom format fields: * `enroll.use-authentication-cert` = true * `enroll.mandatorypassword` = false * `enroll.check-subject-values` = true You add Custom format fields using the advanced button next to the certformat when modifying a certificate procedure. ### Manual authorization for EST using IDM The `/simpleenroll` endpoint can be set up to require manual authorization using Smart ID Identity Manager \[IDM\]. In this case, an Identity Manager Operator must approve the request before a certificate is issued. This is an example of a handler configuration: #### **Example: Handler configuration** handler..filter = registersimpleenroll-basic-idm-auth handler..format = est-simpleenroll-idm handler..tokenprocedure = EST Registration and Enroll Procedure handler..authtype = Basic handler..realm = EST Realm handler..idm.requestUrl = https://localhost:8443/idm/ws/processes/... handler..idm.tls.token = protocol-gateway-ra.p12 handler..idm.tls.password = abcd1234 ## challengePassword attribute not supported The EST specification describes a `tls-unique` attribute that can be used as a `challengePassword` inside the request after connecting, proving that the client has access to the private key at the time of the request. Protocol Gateway does **not** support this attribute and the default behavior is to deny all requests containing the `challengePassword` attribute. ## Related information * [EST support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/est-support-in-certificate-manager.md) * [Example: EST configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-est-configuration-in-protocol-gateway.md) * [Device preregistration for automated enrollment](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/device-preregistration-for-automated-enrollment.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Authority administration tasks in Certificate Manager The information gathered in these articles describes the tasks that are done during administration of the Certificate Authority (CA) in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). The administration is done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). Before any tasks can be done in the AWB, you must set up a connection between the AWB client and a CM host. This is described in [Certificate Manager client connection tasks](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-client-connection-tasks.md). To be able to do this, you must be an administration officer with the role **Use AWB** . See also [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md). The authorization system of CM is based on individual smart cards used by the operators. The smart cards are primarily used to: * authenticate the different operators * sign operator requests from the various clients, and establish encrypted communication between the different system components. ## Additional information Useful links * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Authority types in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-types-in-certificate-manager.md) * [Certificate Manager client connection tasks](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-client-connection-tasks.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Authority types in Certificate Manager This article is added for Certificate Manager 8.10. Certificate Manager supports the authority types listed below. ## Certificate Authority (CA) The CA type is responsible for signing and issuing certificates and CRLs. ## Registration Authority (RA) The RA type is intended for special use cases, for example, V2X functionality. The RA functionality will be extended to cover more use cases in the future. ## Signing Authority (SA) The SA type is responsible for signing data for various purposes, for example, code signing. Configuration is similar to CA but limited to the needs of a signing server. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # AWB user interface in Certificate Manager This article includes updates for Certificate Manager 8.10. The [Administrator's workbench](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) (AWB) used for the administration of [Authorities](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-types-in-certificate-manager.md). Officers with appropriate roles are able to create, configure, and remove the various entities that make up an Authority, such as: * Domains * Certificates * Keys * Policies * Officers The AWB user interface is an Explorer style browser where an entity can be selected and its information viewed. You can perform actions on the entities using commands in the menu bar, toolbar or by using shortcut menus. ![AWBclient.jpg](https://doc.nexusgroup.com/__attachments/a_59a3c2fe4988c91052f06dec13e7488df6ec199828ce0e41043b05917218c772/AWBclient.jpg?cb=bc97bfd8b9f2699e1da46e986b10e514) The main window presents: * a hierarchical view of the entities in the left-hand pane (explorer bar) * information about a selected entity or a system summary in the right-hand pane (information pane) Some of the functionalities described is only available if the present license enables it. The license is checked when starting AWB. Functions and items related to key archiving and recovery, attribute certificates and card verifiable certificates will only be visible in the GUI when permitted by the license. The signing authority functionality requires a license as well. These are the CA administration entities: | **Domain Hierarchy** | [Domains](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/domain-tasks-in-certificate-manager.md)can be used to separate hosted tenants in the system by use of access rights per domain, or to group geographically separated regions. The top domain is called Root. In general, officers can only manipulate objects that belong to their own domain or sub domain. Super objects can be used and viewed, but not modified, if they are marked as visible in sub domain. If an object does not have a domain association, it belongs to the Root and it can be referenced from all domains. | | **Authority Hierarchy** | The Authority Hierarchy group provides access to all the CAs, secondary CAs, RAs and SAs of the system displayed as hierarchical authority chains under the group icon. The root of each authority chain is either a self-signed CA or a CA with an absent signer. | | **Key Registry** | The Key Registry group provides access to the Authority keys that have been created in the system, organized into three subgroups: * Not In Use - those not yet used in an Authority. * In Use - those currently being used. * Retired - those no longer in use. | | **Policy** | The [Policy](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-policy-tasks-in-certificate-manager.md) group provides access to the procedures, rules, and formats used for issuing tokens and end-user certificates with the Authorities. There are several organizational subgroups: * Token, Attribute Certificate, Certificate, Signing, Key, Publication, CRL procedures * Formats and Distribution rules * Attribute Certificate, Certificate, Signing, Key Procedure, Publication, CIL and CRL formats | | **Officer Profiles** | The [Officer Profiles](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officer-profile-tasks-in-certificate-manager.md) group provides access to the officer profiles created for the system. Officers are assigned roles, which allow them to perform various tasks. Roles are defined in officer profiles and one officer profile has to be selected for each officer created. | | **Officers** | The [Officers](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officer-tasks-in-certificate-manager.md) group provides access to the officers created for the system. | | **Audit** | [Audit](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/audit-tasks-in-certificate-manager.md) provides access to the audit logs. All significant actions performed by or within the system are logged. Unlike the other groups, all information presented here is strictly read-only. There are no organizational subgroups, only two static entities: CIS log and Request log. | | **Repository** | Selected entities from the other groups may be organized in [folders](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/repository-tasks-in-certificate-manager.md) in the same way as files are organized in a hierarchical file system. This can be useful for collecting all information relevant to a particular authority in a single folder. | |-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| The names of the entities shown in the explorer bar are user-defined. It is recommended to use a logical naming convention. ## Additional information Useful links * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [CA tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-tasks-in-certificate-manager.md) * [CA key tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-key-tasks-in-certificate-manager.md) * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Audit tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/audit-tasks-in-certificate-manager.md) * [Domain tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/domain-tasks-in-certificate-manager.md) * [Officer tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officer-tasks-in-certificate-manager.md) * [Officer profile tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officer-profile-tasks-in-certificate-manager.md) * [Policy tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-policy-tasks-in-certificate-manager.md) * [Repository tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/repository-tasks-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Backup and restore of Certificate Manager This section describes how to backup and restore [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md). * [Backup and restore of the Certificate Issuing System in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/backup-and-restore-of-the-certificate-issuing-system-in-certificate-manager.md) * [Backup and restore of the Certificate Factory in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/backup-and-restore-of-the-certificate-factory-in-certificate-manager.md) * [Backup and restore of the Key Generation System in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/backup-and-restore-of-the-key-generation-system-in-certificate-manager.md) Last updated: August 10, 2026 --- version: "8.15" language: "en" --- # Backup and restore of the Certificate Factory in Certificate Manager This article describes backup and restore routines for the Certificate Factory (CF) in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). ## Backup strategy Most data in the database cannot be reconstructed in the event of a total disk crash. Therefore, it is essential to have suitable backup routines in place and ensure correct management of the data. It is important to perform regular backups of the installation. If you perform regular backups, you will be able to recover from a failure, by restoring the most recent backup. ### Backup databases 1. Backup the CMDB database on a regular basis. See backup information from the respective database vendor. The format of the CMDB database is described in the Technical Description. 2. In the event of a database failure, recover by restoring the latest backup, and then update the database with help of the transaction log. ### Backup configuration files * Backup all configuration files in the ***\/config*** directory and its sub directories after any changes. ### Backup system keys * Backup the Key Encryption Key (KEK), the TLS server key and the PIN decryption keys. These keys are stored in the ***\/certs*** directory. If an HSM is used to handle system keys, see backup information from the respective HSM vendor. ## Reset database users with MSSQL ### Reset database users After moving or restoring an MSSQL-hosted CMDB, it might be necessary to reset the database users. The username used to log in to the MSSQL server is by default LCMReq. The SID number may have changed and then you are not able to log in. 1. Generate a report to find out whether a database user has a changed SID number: use exec sp_change_users_login 'Report' 2. Example: For MSSQL server, execute these commands: use exec sp_change_users_login 'Auto_fix','',Null,'' Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Backup and restore of the Certificate Issuing System in Certificate Manager This article describes the backup strategy for the Certificate Issuing System (CIS) in Nexus Certificate Manager (CM). The CIS log, ***cis.conf*** and any soft token files should be backed up on storage media on a regular basis. All requests received by the CIS are logged, and one log file per day is generated. You handle the CIS log file in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md), see also [Search the CIS log in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/search-the-cis-log-in-certificate-manager.md) in [Audit tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/audit-tasks-in-certificate-manager.md). Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Backup and restore of the Key Generation System in Certificate Manager This article describes the strategy for backup of the Key Generation System (KGS) in Nexus Certificate Manager (CM). Backup the Key Generation System (KGS) using the methods for a normal workstation. The backup must be maintained under the same strict security controls as the KGS itself. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Bootstrap Certificate Manager This article includes updates for Certificate Manager 8.11. ![CAHierarchy.png](https://doc.nexusgroup.com/__attachments/a_8863b7dc725729a59a5f6d01b1106513e3747e8a37ddf1c33784482fdd2833bb/CAHierarchy.png?cb=38709605d1e8d47b5452d487119b36ee) The shaded objects show the foundation of the Certificate Manager PKI environment, which is created in the bootstrap procedure. This article describes how to bootstrap [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md). The purpose of the bootstrap procedure is to build the foundation for a PKI environment, including certificate authorities (CAs) and officers, and revoke the bootstrap CA. A bootstrapping must be performed after a new system installation, before the system can be used for production of certificates. When performing the bootstrap procedure you will be using the two Certificate Manager clients [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) and [Registration Authority (RA) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-authority-ra-in-certificate-manager.md), as well as other utility programs described below. In addition to using software tokens for TLS and PIN encryption it is possible to store the tokens in hardware security modules (HSMs). It is also possible to combine one software token with one stored in HSM. The bootstrap procedure will differ depending on the use of HSM. Use the two bootstrap officers soft tokens in the boot kit until you have created two officers, and after that use the smart cards that you have then personalized. For the bootstrap officers, two step signing is disabled. ## Create Officer and System CA ### To create an Officer and System CA key 1. Generate a new CA key for the **Officer and System CA** , according to [Create CA key in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-ca-key-in-certificate-manager.md). 2. . In **Key name** , enter `Officer and system CA key. `In **Device** , select an ***RSA*** type. ### Create Officer and System CA 1. Use the key `Officer and system CA key` created in the previous step, to create an **Officer and System CA** , according to [Create CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-ca-in-certificate-manager.md). 2. In **Authority name** , enter `Officer and system CA`. 3. Do the following selections in the **Authority Request** dialog box: * **Issuing CA** - select ***Self-signed*** * **Usage** - ***Certificate signing*** * **Format** - self-signed ca-cert * **Country** - current country * **Common name** - ***Officer and system CA*** * **Organization** - current organization No distribution rule is required but can be added later if necessary. ## Create bootstrap officers ### Create certificate procedure for officer certificates To create a certificate procedure: 1. Create a certificate procedure to be used when issuing smart cards based on the `Officer and System CA key`. See [Create certificate procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-certificate-procedure-in-certificate-manager.md). 2. Do the following selections in the **Certificate Procedure Request** dialog box: * **Procedure name** - ***Officer certificates*** * **Key usage** - do not select any key usage * **Issuing CA** - ***Officer and System CA*** * **CA chain** - none * **Certificate format** - ***rfc5280*** * Set the **Validity** and **Signature algorithm** parameters as required. ### Create token procedure for officer smart cards To create a token procedure for smart cards: 1. Create a token procedure to be used when issuing smart cards based on the certificate procedure you created in the previous step. See [Create token procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-token-procedure-in-certificate-manager.md) 2. Do the following selections in the **Token Procedure Request** dialog box: * **Procedure name** - ***Officer cards*** * **Storage profile** - ***Smart Card*** * **Card serial number** - ***Yes*** * **Serial number range** - Mandatory * **PIN procedure** - ***Show PINs in client*** * **Issuer certificates** - do not store any * **Certificate procedure** - ***Officer certificates*** Smart cards are recommended. If, for some reason, it is not possible to use smart cards, PKCS#12 tokens can also be used as storage profiles. ### Personalize two officer smart cards To personalize two smart cards: 1. Produce two pre-personalized smart cards in your Key Generation System (KGS). See [Produce smart cards in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/produce-smart-cards-in-certificate-manager.md). 2. Register the two smart cards with information concerning two subjects who should become officers 1 and 2 of your system. See [Issue smart card certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/issue-smart-card-certificate-in-certificate-manager.md). 3. In the **Smart Card** tab of the **Registration Authority** application window, do the following steps for each of the two cards: 1. Select action **Add** for each displayed key. 2. Select the procedure you created in the previous step. 4. Make a note of the PIN codes assigned for the cards. If PKCS#12 has been chosen as storage profile in the token procedure, use the **Soft Token**tab in Registration Authority (RA) to issue certificates for your officers. If you use PKCS#12 officer tokens it is recommended to store the associated keys in an HSM. ### Create two officers To create two officers: * Create two officers based on the smart cards from the previous step. See [Create officer profile in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-profile-in-certificate-manager.md) and [Create officer in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-in-certificate-manager.md). Any certificate on the smart card may be selected in the **Officer Request** dialog box. ### Create certificate procedure for TLS, KAR and PIN encryption To create a certificate procedure for TLS, KAR and PIN encryption: * Create a certificate procedure according to [Create certificate procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-certificate-procedure-in-certificate-manager.md). Use the following parameters: * **Key usage** - do not select any key usage * **Issuing CA** - ***Officer and System CA*** * **Certificate format** - ***server certificate*** * Set the **Validity** and **Signature algorithm** parameters as required. It is normally not necessary to select distribution rules for these certificates. ## Set up tokens for secure system communication You can create hardware tokens or software tokens for TLS and PIN encryption. ### Create hardware tokens for TLS and PIN encryption These tasks are related to administrative system hardware tokens only, when a hardware security module (HSM) is used. Hardware tokens are an alternative to software tokens. #### Create a token procedure with storage profile PKCS#10 To create a token procedure with storage profile PKCS#10: * Create a token procedure, according to [Create token procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-token-procedure-in-certificate-manager.md). Use the following parameters: * **Storage profile** - ***PKCS#10*** * **Issuer certificates** - do not store any * **Certificate procedures** - the certificate procedure created for TLS, KAR and PIN encryption. #### Prepare hardware security module for TLS token To prepare the hardware security module (HSM) for TLS tokens: 1. Run **hwsetup** to generate a key pair with sign property, according to [Generate DSA/EC/RSA key pair](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-dsa-ec-rsa-key-pair.md). Example: `hwsetup -libname crypto -slot 0 -pin abcd -id tls -genrsa 2048 -sign` 2. Run **hwsetup** to create a PKCS #10 request based on the generated key pair, according to [Generate PKCS #10 certificate request](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-pkcs-10-certificate-request.md). Include the key usage extension. Example, (on one line): `hwsetup -libname crypto -slot 0 -pin abcd -id tls -keyusage -genreq "cn=localhost,o=Nexus"` 3. Use RA to issue a certificate to a file, ***tls.crt***, based on the PKCS #10 request. 4. Run **hwsetup** to store the certificate in HSM, according to [Install certificate](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate.md). #### Prepare hardware security module for PIN encryption token To prepare the hardware security module (HSM) for PIN encryption tokens: 1. Run **hwsetup** to generate an RSA key pair, according to [Generate DSA/EC/RSA key pair](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-dsa-ec-rsa-key-pair.md). The private key needs the sign property to sign the PKCS #10 request. Example: `hwsetup -libname crypto -slot 0 -pin abcd -id pin -genrsa 2048` 2. Run **hwsetup** to create a PKCS #10 request based on the generated key pair, according to [Generate PKCS #10 certificate request](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-pkcs-10-certificate-request.md). Include key usage extension with `dataEncipherment`. Example: `hwsetup -libname crypto -slot 0 -pin abcd -id pin -keyusage dataEncipherment -genreq "cn=PIN encryption,o=Nexus"` 3. Use RA to issue a certificate to a file, ***pin.crt***, based on the PKCS #10 request. 4. Run **hwsetup** to store the certificate in the HSM, according to [Install certificate](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate.md). #### Prepare hardware security module for KAR token This step is only performed if the key archiving and recovery (KAR) option has been licensed and enabled during installation. The purpose of this step is to create a key encryption key (KEK). The KEK is used by the KARFactory in order to encrypt and decrypt archived keys. The KEK can be either a symmetric AES or DES3 key or an asymmetric RSA key pair. ##### AES or DES3 key 1. Run **hwsetup** to generate a symmetric AES or DES3 key, see [Generate AES or 3DES key](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-aes-or-3des-key.md). Example: `hwsetup -libname crypto -slot 0 -pin abcd -id kekaes256 -label kekaes256 -genkey AES-256` ##### RSA keypair 1. Run **hwsetup** to generate an asymmetric RSA key pair, see [Generate DSA/EC/RSA key pair](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-dsa-ec-rsa-key-pair.md). The private key needs the sign property to sign the PKCS #10 request. Example: `hwsetup -libname crypto -slot 0 -pin abcd -id kekrsa -label kekrsa -genrsa 2048` 2. Run **hwsetup** to create a PKCS #10 request based on the generated key pair (see [Generate PKCS #10 certificate request](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-pkcs-10-certificate-request.md)). Include key usage extension with `keyEncipherment` and `dataEncipherment`. Example: `hwsetup -libname crypto -slot 0 -pin abcd -id kekrsa -keyusage "keyEncipherment,dataEncipherment" -genreq "cn=KEK,o=Nexus"` 3. Use RA to issue a certificate to a file, ***kek.crt***, based on the PKCS #10 request. 4. Run **hwsetup** to store the certificate in HSM, according to [Install certificate](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate.md). ### Create software tokens for TLS and PIN encryption These tasks are related to administrative system software tokens only. Software tokens are an alternative to hardware tokens. #### Create token procedure for TLS and PIN encryption To create a token procedure for TLS and PIN encryption: * Create a token procedure, according to [Create token procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-token-procedure-in-certificate-manager.md). Use the following parameters: * **Storage profile** - ***PKCS#12*** * **Pin procedure** - ***Show PINs in client*** * **Issuer certificates** - do not store any * **Certificate procedures** - the certificate procedure created for TLS, KAR and PIN encryption. #### Issue software token for TLS To issue a software token for TLS: 1. Issue a software token based on the token procedure for TLS and PIN encryption, according to [Issue software token in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/issue-software-token-in-certificate-manager.md). 2. Name the file ***tls.p12***. 3. Make a note of the assigned PIN code. 4. Save the file to a removable media for use in later tasks. Elliptic Curve keys using Brainpool curves are not supported for TLS. #### Issue software token for PIN encryption To issue a software token for PIN encryption: 1. Issue a software token based on the token procedure for TLS and PIN encryption, according to [Issue software token in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/issue-software-token-in-certificate-manager.md). 2. Name the file ***pin.p12***. 3. Save the PIN encryption certificate to the file ***pin.crt***. 4. Make a note of the assigned PIN code. 5. Save the files to a removable media for use in later tasks. ## Prepare data for CIS ### Change key for signing logs in Certificate Issuing System (CIS) Do these preparations for the Certificate Issuing System (CIS): 1. In AWB, go to **Key Registry \> In Use \> Officer and System CA key** , and note the value of **Identifier**. 2. Open ***\/config/cis.conf*** for editing. 3. Find the parameter `logsignkey` and set it to the value of **Identifier** found in the AWB (see step 1). 4. Place the certificate file in CIS trust store: ***\/config/cistrust/system_ca.cer***. 5. Remove the Boot CA file from CIS trust store: ***\/config/cistrust/bootca.cer***. ### Stop the system 1. Stop the Nexus Certificate Issuing System (CIS) service (if external CIS service is installed). 2. Stop the Nexus Certificate Factory (CF) service. 3. Stop the clients. If you have installed and started the Nexus SNMP service, you may stop it, but it is not mandatory. ## Use tokens for secure system communication ### For software token: Change the TLS token If you have issued a TLS software token, it must be installed and configured in CF (or in all computers running CF and CIS in case of a distributed configuration). To install and configure the TLS software token: 1. Make a backup copy of the current file ***tls.p12*** in the CF. 2. Copy the token from the removable media to replace the old file ***\/certs/tls.p12***. 3. Set parameter `SSL.file` and `cis.ssl.file` in ***cm.conf*** and `SSL.file` in ***cis.conf*** to the file path of the TLS soft token file. 4. Set parameter `SSL.pin` and `cis.ssl.pin` in ***cm.conf*** and `SSL.pin` in ***cis.conf*** to avoid manual intervention during start of CM servers (also called Optional PIN). 5. After you have tested that the new TLS server certificate works properly, delete the file ***tls.p12*** from the removable media. ### For hardware token: Change the TLS token If you have prepared a TLS hardware token, it must be installed and configured in CF (or in all computers running CF and CIS in case of a distributed configuration). To configure the TLS hardware token: 1. Set parameter `SSL.cert` and `cis.ssl.cert` in ***cm.conf*** and `SSL.cert` in ***cis.conf*** to a case sensitive string value taken from the Distinguished Name in the TLS server certificate. (Open the file containing the certificate created in "Prepare hardware security module for TLS token" above.) 2. Set parameter `SSL.tokenlabel` and `cis.ssl.tokenlabel` in ***cm.conf*** and `SSL.tokenlabel` in ***cis.conf*** to a case sensitive string value taken from the device token label where the certificate/key resides. This task is optional, but it is recommended. 3. Set parameter `pkcs11.`, (where `` is a sequence number for each library starting with 1) in ***cm.conf*** and ***cis.conf*** to specify the PKCS #11 libraries that should be available for use in TLS authentication and that should be searched for the specified certificate. 4. Set parameter `SSL.pin` and `cis.ssl.pin` in ***cm.conf*** and `SSL.pin` in ***cis.conf*** to avoid manual intervention during start of CM servers (also called Optional PIN). 5. Set parameter `SSL.nopin`=true in ***cm.conf*** and ***cis.conf*** to avoid showing unnecessary dialogs when the HSM has a PIN pad or if it does not require a PIN code. ### For software token: Change the PIN encryption token If you have issued PIN encryption software tokens, they must be installed and configured in the CF. To install and configure the PIN encryption software tokens: 1. Make a backup copy of the current ***pin.p12*** file in the CF. 2. Copy the tokens from the removable media to replace the old file ***\/certs/pin.p12***. 3. Set parameter `pin.file` in ***cm.conf*** to the file path of the PIN soft token file. 4. Set parameter `pin.pin` in ***cm.conf*** to avoid manual intervention during start of CM servers (also called Optional PIN). ### For hardware token: Change the PIN encryption token If you have prepared a PIN encryption hardware token, it must be configured in CF. To configure the PIN encryption hardware token: 1. Set parameter `pin.cert` in ***cm.conf*** to a case sensitive string value taken from the Distinguished Name in the PIN encryption certificate. (Open the file containing the certificate created in "Prepare hardware security module for PIN encryption token" above.) 2. Set parameter `pin.tokenlabel` in ***cm.conf*** to a case sensitive string value taken from the device token label where the certificate/key resides. This task is optional, but it is recommended. 3. Set parameter `pkcs11.`, (where `` is a sequence number for each library starting with 1) in ***cm.conf*** to specify the PKCS #11 libraries that should be available for use in PIN encryption and that should be searched for the specified certificate. 4. Set parameter `pin.pin` in ***cm.conf*** to avoid manual intervention during start of CM servers (also called Optional PIN). 5. Set parameter `pin.nopin`=true to avoid showing unnecessary dialogs when the HSM has a PIN pad or if it does not require a PIN code. ### Optional: Change the KAR token This step should only be performed if KAR is enabled. The KEK token prepared in "Prepare hardware security module for KAR token" above must be configured in the CF. 1. In ***kar.conf*** , add the crypto library to the list of crypto libraries (in the parameter `kar.common.cryptolib..name`). 2. In ***kar.conf*** , add the new KEK to the list of tokens instead of the temporary KEK, that is, change the value of `kar.common.token.0.tokenlabel` and `kar.common.token.0.pin`. 3. In ***kar.conf*** , set the new KEK as the key to use for key archiving, that is, change the value of `kar.archive.kek.0.tokenlabel` and `kar.archive.kek.0.keylabel`. The value of `kar.archive.kek.0.keylabel` must be the label of the key. In case of an RSA key pair, it should be the label of the public key. You can look up the key label using the command **hwsetup -list** . For more information on **hwsetup** , see [Initializing Hardware Security Module](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/initialize-hardware-security-module-for-use-in-certificate-manager.md). ### Start the system 1. Start the Nexus CIS service (if external CIS service is installed. 2. Start the Nexus CF service. ## Remove Nexus boot components ### Revoke the Boot CA When everything works as expected, you can revoke the Boot CA. The bootstrap officers are prevented from logging in to Certificate Manager when revoking the Boot CA. To revoke the Boot CA: 1. Test all connections to verify that everything works as expected, for example: 1. Sign in to AWB with one of the new bootstrap officers. 2. Do an update and sign it, to test that both bootstrap officers function as expected. 2. Use the **Revoke Authority** command in the **Tools** menu to revoke the Boot CA with revocation reason *Cessation of Operation*. ### Remove the Boot CA key From the AWB, remove the Boot CA key, (which can be found in the "Retired keys" subgroup in the Key Registry), as described in [Modify CA key in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/modify-ca-key-in-certificate-manager.md). After removing this CA key, any procedures created with the Boot CA key can no longer be used and CIS log entries signed with this key can no longer be verified. ## Additional information Useful links The following tasks are done during the bootstrapping procedure. In [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md): * [Create CA key in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-ca-key-in-certificate-manager.md) * [Create CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-ca-in-certificate-manager.md) * [Create certificate procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-certificate-procedure-in-certificate-manager.md) * [Create token procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-token-procedure-in-certificate-manager.md) * [Create officer profile in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-profile-in-certificate-manager.md) * [Create officer in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-officer-in-certificate-manager.md) Using hwsetup: * [Initialize Hardware Security Module for use in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/initialize-hardware-security-module-for-use-in-certificate-manager.md) * [Generate AES or 3DES key](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-aes-or-3des-key.md) * [Generate DSA/EC/RSA key pair](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-dsa-ec-rsa-key-pair.md) * [Generate PKCS #10 certificate request](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/generate-pkcs-10-certificate-request.md) * [Install certificate](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-certificate.md) In Key Generation System: * [Produce smart cards in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/produce-smart-cards-in-certificate-manager.md) In [Registration Authority (RA) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-authority-ra-in-certificate-manager.md): * [Issue smart card certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/issue-smart-card-certificate-in-certificate-manager.md) * [Issue software token in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/issue-software-token-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Build CIL in Certificate Manager This article includes updates for Certificate Manager 8.6.1. This article describes how to manually trigger building of a Certificate Issuing List (CIL) within [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). This task is done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). ## Prerequisites The following prerequisites apply: * An administration officer must sign the request. * The officer must have the following roles: * Use AWB * Manual build of CRL and CIL * A connection to the CM host must have been established. See [Connect to a Certificate Manager host](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/connect-to-a-certificate-manager-host.md). * A CIL procedure must be available (see [Create CIL procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-cil-procedure-in-certificate-manager.md)) ## Build CIL 1. In AWB, select **Tools \> Build CIL** . A list of all available signed CIL procedures is shown. 2. Select which CIL procedure to use for this CIL. 3. The **Signature** dialog box appears. 4. Select the officer certificate and enter the PIN code for the key. 5. Click **OK**. ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Connect to a Certificate Manager host](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/connect-to-a-certificate-manager-host.md) * [Create CIL procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-cil-procedure-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [CA policy tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-policy-tasks-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Build CRL in Certificate Manager This article includes updates for Certificate Manager 8.6.1. This article describes how to build a Certificate Revocation List (CRL) upon revocation of a certificate within [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). This task is done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). ## Prerequisites The following prerequisites apply: * An administration officer must sign the request. * The officer must have the following roles: * Use AWB * Manual build of CRL and CIL * A connection to the CM host must have been established. See [Connect to a Certificate Manager host](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/connect-to-a-certificate-manager-host.md). * A CRL procedure must be available (see [Create CRL procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-crl-procedure-in-certificate-manager.md)) ## Build CRL 1. In AWB, select **Tools \> Build CRL** . A list of all available signed CRL procedures is shown. 2. Select which CRL procedure to use for this CRL. 3. The **Signature** dialog box appears. 4. Select the officer certificate and enter the PIN code for the key. 5. Click **OK**. Signing completes the task and returns you to the AWB window. ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Create CRL procedure in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-crl-procedure-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [CA policy tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-policy-tasks-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CA key tasks in Certificate Manager This article describes the available tasks in [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM) for managing Certificate Authority (CA) keys. The tasks are done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). * [Create CA key in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-ca-key-in-certificate-manager.md) * [Modify CA key in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/modify-ca-key-in-certificate-manager.md) ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: August 10, 2026 --- version: "8.15" language: "en" --- # CA policy tasks in Certificate Manager These articles describe the Certificate Authority (CA) policy tasks within [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). The tasks are done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CA tasks in Certificate Manager This article lists the Certificate Authority (CA) tasks in [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). The tasks are done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) (AWB). * [Modify CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/modify-ca-in-certificate-manager.md) * [Publish CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/publish-ca-in-certificate-manager.md) * [Revoke CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/revoke-ca-in-certificate-manager.md) * [Create request for cross CA certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-request-for-cross-ca-certificate-in-certificate-manager.md) * [Import external CA certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/import-external-ca-certificate-in-certificate-manager.md) * [Delete external CA certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/delete-external-ca-certificate-in-certificate-manager.md) * [Create CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-ca-in-certificate-manager.md) * [Process request for cross certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/process-request-for-cross-certificate-in-certificate-manager.md) * [Create Hybrid CA in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-hybrid-ca-in-certificate-manager.md) ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Authority administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Nexus Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: August 10, 2026 --- version: "8.15" language: "en" --- # CC user interface in Certificate Manager The [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md) is used by officers to publish and manage publications, activate OCSP, revoke, and reinstate certificates either individually or in groups. The CC user interface shows a number of certificates with various status as the result of a search. ![CC_UserInterface.png](https://doc.nexusgroup.com/__attachments/a_538ca712609bde983429ab45693446e6e7307328f0e0e61fceea873e67b95442/CC_UserInterface.png?cb=c9011a60c95d176c5feface57bd4460e) ## Reason codes Certificates can be published and revoked for various reasons. Each reason code has its own icon, which is used as a graphical indicator in the CC application window. All reason codes in the following table may not appear in your CC. Reason codes will only appear if the configuration has been set accordingly. Public key certificate icons have a green border while attribute certificates have a blue border. | Reason code | Icon | Description | |------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Key compromise | ![image2019-2-7_10-16-44.png](https://doc.nexusgroup.com/__attachments/a_61462b84111b3561fbea6c570d52a7e1473bf3c6a22d95125d28cc926237fe17/image2019-2-7_10-16-44.png?cb=be35823e021a6e31b0e1d1a1b4aa8ed8) | Used in revoking an end-entity certificate. It indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised. | | Affiliation changed | ![image2019-2-7_10-16-56.png](https://doc.nexusgroup.com/__attachments/a_d5ed334e2b4e8fcacf6dccd37ffdefe3687b17eda433b3fc46b869b609b0e614/image2019-2-7_10-16-56.png?cb=74a80e47027ca1d3268a9813a2fb4adb) | The subject's name or other information in the certificate has been modified. There is no cause to suspect that the private key has been compromised. | | Superseded | ![image2019-2-7_10-17-2.png](https://doc.nexusgroup.com/__attachments/a_0982034665d410af448753a3c411c53655d0bd58b5f9829b5e4fc946b5785049/image2019-2-7_10-17-2.png?cb=0c7c79b259215a5256191128bbf80341) | The certificate has been superseded. There is no cause to suspect that the private key has been compromised. | | Cessation of operation | ![image2019-2-7_10-17-13.png](https://doc.nexusgroup.com/__attachments/a_b3851af809d4f15fcdadd979ac223fa69746d451d658f30926a891fba6c62985/image2019-2-7_10-17-13.png?cb=3ba6cfc548038ffb009abc76b69a74c9) | The certificate is no longer needed for the purpose for which it was issued. There is no cause to suspect that the private key has been compromised. | | Privilege withdrawn | ![image2019-2-7_10-17-27.png](https://doc.nexusgroup.com/__attachments/a_8c8a8dfbabacc27b74c6f739eb8a7736a82e7ed1ee4df98f21ba4c9bf0bdc1dc/image2019-2-7_10-17-27.png?cb=4ba298588a90734720f4bac52791ca1c) | The certificate (public-key or attribute certificate) was revoked because a privilege contained within that certificate has been withdrawn. | | No reason | ![image2019-2-7_10-17-59.png](https://doc.nexusgroup.com/__attachments/a_b9e7be72ea5582f05cc3dca9b941e5ea6047a69500b55d0ad7b69e32089e3992/image2019-2-7_10-17-59.png?cb=0c87e5e3cbf27e07dd54ed91df9e0710) | The certificate is revoked without specification of a reason. | | Certificate hold | ![image2019-2-7_10-18-9.png](https://doc.nexusgroup.com/__attachments/a_0b34ee48d2e17970c599fd34a3a6cdcdf8ec8d32f299243a13c5e2deed620677/image2019-2-7_10-18-9.png?cb=37792cbe72a5c14773c1233ff0ae11a3) | The certificate is on hold, that is, temporarily invalid. | | | ![image2019-2-7_10-18-24.png](https://doc.nexusgroup.com/__attachments/a_66ce9ab1b682cffdde688cd21725c42ae8e3911aebcfe7803fe8f000f40110f3/image2019-2-7_10-18-24.png?cb=365f7a5efdec3c5f845d08c244d0f2fb) | A certificate without any restrictions, such as revocation or on hold. | Revocation of CA certificates can only be performed using the Administration Workbench (AWB) as described in [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md). ## Handle certificates on hold Once a certificate hold has been issued, you can handle it in one of the following ways: * Let the certificate remain on the Certificate Revocation List (CRL) with no further action, causing users to reject transactions issued during the hold period. OR * Let the certificate be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation. The revocation date shall be the date when the certificate was placed on hold. OR * Let the certificate be reinstated, that is, explicitly released and the entry removed from the CRL. ## Additional information Useful links * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Controller (CC) in Certificate Manager The [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md) is used by officers to publish and manage publications, activate OCSP, revoke, and reinstate certificates either individually or in groups. ## Tasks done in CC Instructions for the tasks that are done in the CC can be found here: * [General certificate tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/general-certificate-tasks-in-certificate-manager.md) * [Attribute certificate tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/attribute-certificate-tasks-in-certificate-manager.md) ([Revoke attribute certificate in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/revoke-attribute-certificate-in-certificate-manager.md)) ## Information about distribution rules End-user certificates issued by the Registration Authority (RA) are not necessarily distributed to an X.500/LDAP directory immediately. This depends on the token procedure selected during the issuing process. Refer to [Policy tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ca-policy-tasks-in-certificate-manager.md) within [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) for further information on the relationship between token procedures, certificate procedures and distribution rules. The certificate may not have been distributed to specific directories because the issuing authority requires confirmation from the user that the certificate/smart card has been received, before publishing. Certificates that have not been published can be located using the CC and then distributed to the relevant directories. All certificates have a validity period. A certificate may, for various reasons, be revoked before the validity period expires. It is also possible to inhibit a certificate temporarily. The certificate is then put on hold. A certificate on hold may be reinstated. Certificates that are on hold or that have been revoked are published in certificate revocation lists (CRLs). Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager architecture overview ![CM_architecture.png](https://doc.nexusgroup.com/__attachments/a_40328e93a3a0baa5ff772371e4c47d321b8cc1315b171964417949f3c36d2ceb/CM_architecture.png?cb=4d6096e4cb22f49da961d5c600e0128c) For more information about the components in Certificate Manager, see [Certificate Manager server components](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-server-components.md). Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager client connection tasks This article describes the available tasks to connect a [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM) client to a CM host. The tasks are done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). If no officer's card is inserted in the smart card reader, or no software tokens are available when the AWB is started, no connection to the CM host will be established. You may initiate the connection at any time. ## Related information * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager clients This article includes updates for Certificate Manager 8.10. This article describes the clients that are included in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md). ## Administrator's workbench (AWB) The [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) is used by administration officers for setting up CA-unique configurations. For example, these tasks are managed in the AWB: * Initiate creation of CA keys and CAs * Initiate creation of Signing Authorities * Implement CA policies, defining how certificates should be issued * Configure distribution rules for certificates and revocation lists * Manage officer roles and define officers * View request log and CIS log ### Registration Authority (RA) The [Registration Authority (RA) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-authority-ra-in-certificate-manager.md) is used by officers to send various kinds of certificate requests to the CM host. For example, these tasks are managed in the RA: * Create PKCS#12 files * Store certificates on smart cards * Import PKCS#10 requests * Recover archived keys * Issue attribute certificates ### Certificate Controller (CC) The [Certificate Controller (CC) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md) is used by officers to publish and manage publications, activate OCSP, revoke, and reinstate certificates either individually or in groups. For example, these tasks are managed in the CC: * Revoke attribute certificates * Searching for and view certificates * View certificate status and properties * Export search result to text file in comma separated value (.CSV) format * Import CSV format files with certificate content information for searching and revocation * Publish certificates * Revoke certificates * Put certificates on hold * Reinstate certificates * Activate OCSP * Update revocation password * Remove subjects ### Secure Printer (SP) The [Secure Printer (SP) in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/secure-printer-sp-in-certificate-manager.md) client is used by officers to search for, sort, create, and print PIN and PUK letters containing secret codes within a sealed envelope. PIN and PUK letters can be printed for personalized cards as well as not yet produced cards, in so called anonymous letters. Anonymous letters are associated with cards by using the RA. Printer templates are used for defining the printing layout. ## Additional information Useful links * [Troubleshooting Certificate Manager clients](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/troubleshooting-certificate-manager-clients.md) * [Launch Certificate Manager clients](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/launch-certificate-manager-clients.md) * [Certificate Manager overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-overview.md) * [Certificate Manager architecture overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-architecture-overview.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager (CM) REST API This article includes updates for Certificate Manager 8.14.0. This article describes the Certificate Manager REST API (RESTful application programming interface) in Certificate Manager. Certificate Manager REST API (RESTful application programming interface) is an HTTP-based service for x.509 and attribute certificates creation, certificate searching, certificate download, certificate revocation, certificate reinstatement, creation of PKCS#12 files and token procedure listing in Certificate Manager. The API requires client authentication over TLS using a CM officer certificate. Write operations like revoke, reinstate and certificate issuance requires the request data to be signed by a CM officer. The REST API server can also be configured to use a CM officer for signing the requests on the caller's behalf, enabling automated services for trusted clients. The accompanied files ***APISigningWithOpenSSL.sh*** and ***APISigningWithBouncyCastle.java*** referenced below can be found in a CM client installation together with the Protocol Gateway web archive file*,* see [Install Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/install-protocol-gateway.md). For more information, see: * [Example: Certificate Manager (CM) REST API configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-certificate-manager-cm-rest-api-configuration-in-protocol-gateway.md) * Description of the Secure Key Injection Protocol (SKIP): [Use the Secure Key Injection Protocol in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/use-the-secure-key-injection-protocol-in-certificate-manager.md) ## Date-time format The expected date-time format for time search fields is [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601). Example: 2021-12-20T08:01:30Z. [Open API Spec](https://doc.nexusgroup.com/__attachments/a_4c0a949e5bcfc13929932e0f2010490c32a1a2fab9f3099b5adb1ebb197b5ee9/spec.yaml.md?cb=6df54caa3c5a95b2ea6ca2db31303309) Last updated: July 30, 2026 --- version: "8.15" language: "en" --- # Certificate Manager integrations This article summarizes some of the integration possibilities of [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). ## Devices and software Various types of devices and software can be integrated through standard protocols and custom interfaces. See the following links: * [Certificate Manager interfaces and APIs](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-interfaces-and-apis.md) * [Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md) ### Other integrations All hardware security modiles that support PKCS#11 can be connected to CM. For more information, see [Certificate Manager requirements and interoperability](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-requirements-and-interoperability.md). Integration with Active Directory/LDAP server/X.500 directory can be set up by using distribution rules. See [Create distribution rule in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-distribution-rule-in-certificate-manager.md). OCSP Responder connection can be done by using distribution rules. See [Create distribution rule in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/create-distribution-rule-in-certificate-manager.md) Connection to Nexus' Smart ID Identity Manager is done according to the following link: [Integrate Identity Manager with Smart ID Certificate Manager](https://doc.nexusgroup.com/pub/integrate-identity-manager-with-smart-id-certifica.md) Use a secure key injection protocol for constrained devices in CM, see [Use the Secure Key Injection Protocol in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/use-the-secure-key-injection-protocol-in-certificate-manager.md). ## Related information * [Certificate Manager architecture overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-architecture-overview.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager interfaces and APIs This article includes updates for CM 8.11. ![Supported interfaces of Smart ID Certificate Manager](https://doc.nexusgroup.com/__attachments/a_f1b8e2bf3e00548ffe1b79c9e896d56f011f0b970a5808962949d3c2df06d43e/CM_interfaces.png?cb=b1251e4358a9c52e4513481fae16c894) To allow external clients to order certificates from [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM), the following interfaces and protocols are supported via [Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md): | **Interface** | **For more information** | |------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **ACME** | * [ACME support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/acme-support-in-certificate-manager.md) * [Example: ACME configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-acme-configuration-in-protocol-gateway.md) | | **CMC** | [CMC support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cmc-support-in-certificate-manager.md) | | **CMP** | * [CMP support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cmp-support-in-certificate-manager.md) * [Example: CMP configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-cmp-configuration-in-protocol-gateway.md) | | **CM SDK** | CM SDK is a Java API for certificate management. It provides the same functionality as the CM clients RA and CC except for support of PKCS #10 requests. The CM SDK is powerful and easy to use and can be operated using both real and virtual Registration Officers. | | **CM SDK Proxy** | [CM SDK proxy in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cm-sdk-proxy-in-certificate-manager.md) | | **Distribution point** | The [Distribution Point in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/distribution-point-in-certificate-manager.md) can be used by external applications to retrieve the CRL, CIL or CA certificate without having to authenticate. | | **EST** | * [EST support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/est-support-in-certificate-manager.md) * [Example: EST configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-est-configuration-in-protocol-gateway.md) | | **EST-coaps** | [EST over CoAPs support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/est-over-coaps-support-in-certificate-manager.md) | | **Ping** | * [Ping support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/ping-support-in-certificate-manager.md) * [Set up Protocol Gateway Ping](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/set-up-protocol-gateway-ping.md) | | **REST API** | * [Certificate Manager (CM) REST API](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-cm-rest-api.md) * [Example: Certificate Manager (CM) REST API configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-certificate-manager-cm-rest-api-configuration-in-protocol-gateway.md) The following enrollment method is also supported. However, migration to REST API is recommended: * CM Web Services (CM WS) - SOAP-based web service interface used for certificate management in CM, with functionality to enroll, revoke, search and fetch certificates. | | **SCEP** | The SCEP support includes **SCEP Intune** and **SCEP NDES**. * [SCEP support in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/scep-support-in-certificate-manager.md) * [Example: SCEP configuration in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/example-scep-configuration-in-protocol-gateway.md) | | **V2X REST API** | Read more on [Identities for vehicle-to-everything - V2X PKI](https://doc.nexusgroup.com/pub/identities-for-vehicle-to-everything-v2x-pki.md). For questions, [Contact Nexus](https://www.nexusgroup.com/contact/). | | **WinEP** | [Nexus Windows Enrollment Proxy - WinEP](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/nexus-windows-enrollment-proxy-winep.md) | ## Device authorization To control which devices can request certificates, authorization is required. Different enrollment protocols require different authorization. Certificate Manager allows different authorization rules for different protocols, by configuration of protocol handlers. The access to a protocol handler can be restricted to administrators that are CM Officers with the configured roles. The authorization condition can be specified as default for a protocol or per protocol handler. For more information, see each protocol description. ## Device preregistration The security of automated enrollment is enhanced with a preregistration feature: any authorized devices must be registered in the Certificate Manager database before they can receive certificates. All registration requests must be signed and can later be audited. This layer of security ensures strong control of all device identities. Devices must be preregistered before enrolling with SCEP or CMP. Preregistration can also be set up for other protocols, but it is not required. For more information, see [Device preregistration for automated enrollment](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/device-preregistration-for-automated-enrollment.md). ## Related information * [Certificate Manager overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-overview.md) * [CM architecture overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-architecture-overview.md) * [Configuration examples in Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/configuration-examples-in-protocol-gateway.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager news ## All release notes [Certificate Manager release notes](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-release-notes.md) ## Supported versions [Supported versions of Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/supported-versions-of-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager overview This article includes updates for Certificate Manager 8.10. ![Certificate Manager use cases](https://doc.nexusgroup.com/__attachments/a_ca77be4ee906f894ffc041ff0da41271df306a2edfde9f6f77740b33de5523b9/_CM_overview.png?cb=f172cb7aec3b5240188e7f2de8e2bd88) Certificate Manager use cases **Smart ID Certificate Manager** (CM) is a flexible, scalable, and high-security certificate authority (CA) software. Certificate Manager supports a wide range of certificate enrollment protocols, which enables you to issue, manage, and validate certificate-based electronic identities (eIDs) for people, infrastructure, software and devices. The component can be used for customized operations on-premises or in a hosted environment. Core certificate authority (CA) functionality is separated from remote administrative clients. Additionally, CM can establish Signing Authorities, SA, with HSM based key and trusted signing certificate, similar to how a CA operates when signing certificates. This allows clients using the CM REST API to request signing of arbitrary data by the SA, e.g. for code signing. ## Issue and manage certificate-based digital identities A public key infrastructure (PKI) provides a generic security mechanism that enables for example strong authentication, email encryption, digital signing, secure IoT applications and secure vehicle-to-everything communication. PKI provides people, software and devices with a digital identity, and provides the means for managing and validating these during their lifecycle. Certificate Manager is an easy to scale, high-security platform for issuing, managing and validating certificates for consumers, citizens, employees, communication services, software and equipment. Compliance with standards assures that eIDs can be used across networks and applications from different vendors in a large-scale federated environment. ## Store certificates on multiple bearers The eID certificates and keys can be stored on different bearers, for example smart cards, mobile phones, network equipment, computers, soft tokens, HSMs, and IoT devices. Third-party products can be integrated with CM via a number of different [interfaces](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-interfaces-and-apis.md), such as EST, SCEP and ACME. Compliance with these and other standards assures that eIDs can be used across applications from different vendors in large-scale environments. ## Manage complete lifecycle of certificates Certificate Manager handles the lifecycle of user's digital identities, for example Initial enrollment of a user, revocation and renewal of credentials. Revoked certificates are listed in certificate revocation lists (CRLs) and periodically distributed to services such as an external LDAP directory or the [Nexus OCSP Responder](https://doc.nexusgroup.com/pub/nexus-ocsp-responder.md). Instant update of revocation status to the OCSP Responder is possible by immediate issuance of a delta CRL when a certificate is revoked. Activation, or white-listing, of certificates is done in the OCSP Responder by use of Certificate Issuance Lists. A user's private keys that are used for encryption of data, for example for S/MIME use, can be encrypted and archived in the CM database. If a smart card with the encryption key is lost, the key can be recovered, which means that loss of encrypted data can be avoided. Key archiving and recovery is sometimes referred to as key escrow. ## Ensure high performance and scalability Certificate Manager has been verified in critical, large-scale, multi-CA deployments. High availability and performance scaling can be enabled with a traditional active-passive cluster or multiple active-active nodes. Multiple HSM instances are supported for high availability of keys and for separation of keys among tenants. ## Use an allround PKI platform Smart ID Certificate Manager is a part of Nexus' comprehensive PKI solutions designed for various use cases, such as these: * Workforce - to securely access Windows and company applications, encrypt emails and sign documents digitally. * [IoT](https://doc.nexusgroup.com/pub/manufacturing-pki.md) - to secure connected devices with automated processes * [Connected vehicles](https://doc.nexusgroup.com/pub/identities-for-vehicle-to-everything-v2x-pki.md) - to protect vehicle-to-everything (V2X) communication. * [Mobile operators](https://doc.nexusgroup.com/pub/telecom-network-pki.md) - to secure their LTE Backhaul. * [Manufacturing industry](https://doc.nexusgroup.com/pub/smart-id-iot.md) - to protect devices with digital identities and issue factory certificates. * [Workplace devices](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/acme-support-in-certificate-manager.md) - to secure routers, firewalls and machines. * Trust Service Providers - to support all kinds of certificate customers. These solutions can be combined with other Nexus Smart ID solutions, such as Digital identities and Digital access. ## Manage multiple CAs and tenants It is possible to operate multiple logical Certification Authorities (CAs) on the same instance of Certificate Manager and each CA can operate with its own set of policies. These CAs can be organized in one or more sub-ordinate hierarchies and if required also with cross-certification between CAs. Certificate Manager is multitenant, which means that several different client organizations can use the same software instance to implement several parallel, private eID solutions to a reduced cost. Logically isolated administration domains enable organizations to use their own separate domains of users, CAs and policies with a separate thread of the audit trail. ## Migrate CAs for consolidation To manage all certificate issuing in one system, external CAs can be migrated into Certificate Manager, including user certificates, certificate revocation lists (CRLs), and archived keys from legacy CA products. Existing HSMs can be moved and connected to Certificate Manager. ## Protect CA keys with HSM Certificate Manager creates, uses, and deletes CA keys. For highest security is Hardware Security Modules recommended to use for creating and protecting the CA keys for production use. Certificate Manager handles all necessary operations automatically under the control of the CA administrators and enables several HSM's to be used in parallel by different tenants and purposes. For training and testing purposes can Certificate Manager be used without a Hardware Security Module to manage the CA keys. ## Enforce CA policies A CA operates within a framework of legal and social responsibilities, which must be addressed through a CA policy. A CA policy is established to provide guidelines for operating the PKI and govern the issuing of certificates. A CA policy normally includes a Certification Practice Statement (CPS), a Certificate Policy, and Liability and legal conditions. Certificate Manager implements, supports and enforces CA policies. For definition of the operational policies in CM, a dedicated administrative client is used, the [Administrator's Workbench](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-clients.md) client. ## Rely on proven security [Certificate Manager is Common Criteria EAL4+ certified](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/common-criteria-certification-for-certificate-manager.md) according to the international standard Common Criteria EAL4+ for Information Technology Security Evaluation (CC). Nexus' organization complies with ISO 27001 and TISAX (Trusted Information Security Assessment Exchange). Certificate Manager itself is protected with PKI, using dedicated roles to log in, manage and operate the system. CM follows the four-eye principle, which means that all policy changes must be signed by two security officers. The signature of policy configuration allows a trustful auditing of configuration updates and integrity protection to avoid unauthorized manipulation of settings. ## Specification * Support for multiple interfaces and certificate enrollment protocols, including SCEP, ACME, CMP, CMC, EST, EST-coaps, Rest API. * Nexus Timestamp Server and Nexus OCSP Responder are available as stand-alone components or parts of a solution * REST API available for customized integrations with third-party applications * The CM WEB UI provides common registration authority functions: certificate request and revocation, statistics dashboard, IoT device registrations, search and filters for list of various certificate properties. * Compliance with EU regulation eIDAS and PSD2 * Support for vehicle-to-everything (V2X) communication by support for IEEE 1609.2, ETSI * Common Criteria EAL4+ certified and complying with ISO 27001 and TISAX * Support for various HSMs, LTE backhaul networks and smart card products from major vendors For more information on the supported interfaces, standards and specifications, see [Certificate Manager requirements - and interoperability](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-requirements-and-interoperability.md). Last updated: August 10, 2026 --- version: "8.15" language: "en" --- # Certificate Manager release notes * [Release notes Certificate Manager 8.15.0](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/release-notes-certificate-manager-8-15-0.md) * [CM container release notes 8.15.0](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cm-container-release-notes-8-15-0.md) [Earlier release notes - Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/earlier-release-notes-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager - requirements and interoperability * [CM 8.15.x - Requirements and interoperability](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cm-8-15-x-requirements-and-interoperability.md) [CM requirements and interoperability - earlier versions](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/cm-requirements-and-interoperability-earlier-versions.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager server components The server components in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) are listed below. ## Certificate Factory (CF) The Certificate Factory server component is responsible for control mechanisms and preparation of data in the issuance process. Certificate Factory performs authentication of clients connecting to the server, and manages the Certificate Manager Database (CMDB), the preparation of certificates and content of the Certificate Revocation List (CRL), and the connection to the Certificate Issuing System (CIS) for signing certificates and CRLs. The operation is controlled with static workflows, configurable in format files and procedures in the [Administrator's Workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-clients.md). ## Distribution Agent (DA) The Distribution Agent (DA) is responsible for distributing certificates, CRLs, and Certificate Issuance Lists (CILs) to different services. An LDAP client manages distribution of certificates and CRLs to X.500 directories, and an HTTP client manages distribution of CRLs to Nexus OCSP Responder and to web servers. The Distribution Agent also handles removal of certificates from LDAP directory. To manage the Distribution Agent, there are distribution rules in the Administrator's Workbench that contain URL and credentials to access the destination servers and defines what dynamic and static data to be published where. ## Certificate Issuing System (CIS) The Certificate Issuing System (CIS) performs the signing of certificates and certificate revocation lists. CIS creates, uses, and deletes CA keys on demand from the Certificate Factory (CF). CIS connects to one or several HSMs simultaneously for managing and using the protected CA keys. A higher level of security is provided when isolating the CIS on a separate computer, only accessible through the private interface on the Certificate Factory. Maintenance functions are requested by authorized officers from the Administrator's Workbench. ## Support for Hardware Security Modules (HSM) An Hardware Security Module is a specialized hardware for creating cryptographic keys of good quality and for safe storage of keys. Private keys are used only within the device. CM communicates with one or several HSMs over the PKCS#11 cryptographic interface, to manage for example CA keys, TLS keys, key archiving, PIN protection, and user keys. For information on supported HSMs, see . ## SNMP Module The SNMP module is an optional choice at installation of the CM server and contains a Management Information Base (MIB) and the SNMP Agent. When SNMP is installed, the CF and CIS managed services are configured to forward notifications over the SNMP protocol. ## Certificate Manager Database (CMDB) The Certificate Manager Database (CMDB) contains, among other things: * registration, subject, and configuration data * issued certificates * revocation information and passwords * runtime information: certificate and card serial number counter * archived user keys * smart card pin codes and pin letter status * audit log ## Protocol gateway Protocol Gateway is a component that handles standard protocols and standard functionality for enrolling certificates to different kinds of devices. For more information, see [Certificate Manager interfaces](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-interfaces-and-apis.md). ## Key Generation System (KGS) The Key Generation System (KGS) is a standalone component performing the key generation and smart card pre-personalization functions. The card personalization systems supported are listed in the KGS Operator's Guide. The key generation process creates asymmetric keys during the card initialization process, either with help of HSM and stored on the smart card or by using smart card onboard key generation. The key length is set in the card profile. The high quality of the seed, the random generator, and the key generation process gives a CA complete control of the quality of the keys, which is an important security feature. ## Nexus OCSP Responder [Nexus OCSP Responder](https://doc.nexusgroup.com/pub/nexus-ocsp-responder.md) is a separate Nexus product that enables secure validation of certificate revocation status using the standardised Online Certificate Status Protocol (OCSP), as defined in [RFC 6960](https://tools.ietf.org/html/rfc6960). Nexus OCSP Responder is multitenant, and can be used together with other certificate authorities than Nexus Certificate Manager, and with multiple HSMs. Nexus OCSP Responder can fetch revocation information in the form of CRLs, over protocols such as LDAP and HTTP, or from other OCSP responders. ## Additional information Useful links * [Certificate Manager overview](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-overview.md) * [Certificate Manager clients](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-clients.md) * [Certificate Manager interfaces](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-manager-interfaces-and-apis.md) * * [Officers and roles in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/officers-and-roles-in-certificate-manager.md) * [Default ports in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/default-ports-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager system administration This section describes tasks for the system administrators in Nexus Certificate Manager and for the officers responsible for the general system management and operations of Certificate Manager. Tasks include start and stop CM servers, backup and restore and administration of system keys. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager Web UI This article describes the Certificate Manager (CM) Web UI. CM Web UI is an easy-to-use user interface where CM officers can issue, view, download, revoke and reinstate certificates. The CM WEB UI also enables registration of data used for validation and approval of devices during automatic API-based certificate enrollment. A dashboard enables viewing certificate related statistics for a selected Certificate Authority (CA) and time period. The CM Web UI offers a collection of functionality from the [++Certificate Controller (CC)++](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/certificate-controller-cc-in-certificate-manager.md) and [++Registration Authority (RA)++](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/registration-authority-ra-in-certificate-manager.md) clients in Certificate Manager. To use Certificate Manager Web UI, you must have: * Personal Desktop Client for officer smart card authentication and personalization of smart cards. * For operating systems: * 5.15 for Windows * 5.11 for RedHat and Rocky Linux * A CM Officer Token (P12 or smart card) * The PIN for the CM Officer Token * A supported web browser: * Chrome * Edge * Safari * Firefox * The latest version of CM with Web UI URL Last updated: September 02, 2026 --- version: "8.15" language: "en" --- # Certificate Manager Web UI communication flow Certificate Manager Web UI communicates with several components, for example, [Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md) and [Nexus Personal Desktop Client](https://doc.nexusgroup.com/pub/nexus-personal-desktop-client.md). ## Overview ![CM_WebUI_illustration-ppt.png](https://doc.nexusgroup.com/__attachments/a_2d70d5eb08b07db8ea327f5ea866d809c841b6de3fffe4412448879e928e9593/CM_WebUI_illustration-ppt.png?cb=ce9c80f2d81b83d0c3a7ee41db59fdb5) ## Detailed description of the communication flow ### 1 This section describes the green arrows in the illustration. The user logs in to **Certificate Manager Web UI** via a URL in a web browser. When connecting, the web UI communicates with **Protocol Gateway** and activates the **CM REST API**. * Protocol Gateway communicates with **Hermod**. Hermod initiates the signing (sign-in process) and replies with a plug-out URL to Protocol Gateway. * Protocol Gateway sends the plug-out URL to Certificate Manager Web UI. ### 2 This section describes the orange arrows in the illustration. Certificate Manager Web UI communicates with the middleware **Nexus Personal Desktop Client**(Classic). * Personal Desktop enables signing and authentication in web browsers without plugins, using the plugout technology, where Personal Desktop is triggered from the browser page. * Personal Desktop Client sends the login data to **Hermod**. * Hermod sends a callback to **Protocol Gateway**. * Protocol Gateway communicates with **Certificate Factory** (CF) to verify that the user is an officer and that the session can be authenticated. ### 3 This section describes the blue arrows in the illustration. Certificate Manager Web UI polls for the sign-in process via the Protocol Gateway REST API, and if the process is successful, the web UI will start presenting data. ## Additional information Useful links For more information, see: * [Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md) * [Nexus Personal Desktop Client](https://doc.nexusgroup.com/pub/nexus-personal-desktop-client.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Hermod](https://doc.nexusgroup.com/pub/hermod.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate Manager Web UI news * [Release note Certificate Manager Web UI 2.0.0](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/release-note-certificate-manager-web-ui-2-0-0.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Certificate request verifications in Protocol Gateway This article includes updates for Certificate Manager 8.13.0. This article describes how to use certificate context and modules to verify the content of certificate requests in [Protocol Gateway](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/protocol-gateway.md). Protocol Gateway uses a subset of the certificate format files and modifiers in Certificate Factory (CF). For more information, see the section ***Certificate Formats*** in the ***Certificate Manager Technical Description***. ## Certificate context Before sending certificate requests from Protocol Gateway to Certificate Factory (CF), the context is not only one certificate context, but a general context that contains certificate contexts. The context contains a list of certificate requests and also a common context, which in turn are the same as certificate contexts on CF. The values from the common context are copied to all certificate requests if they should be missing any information present in the common context. The following certificate request contextscan be used for verifications in Protocol Gateway. ### certrequests certrequests is a list of requests. For example, to get `commonname.value` of a certificate request, specify the nested certificate context with the following syntax, where `` specifies the certificate request number: certrequests::commonname.value ### commoncontext For example, to get the `commonname.value` of the common context, use the following syntax: commoncontext:commonname.value ## Available modules Each handler in a ***\.properties*** file may define attributes in the same way as in a format. Below are examples of how to set up modifiers, by using the `formatFields` function of a `handler` in a ***.properties*** file. Currently, the following general modules are available in the Protocol Gateway formats and they are run in the following order: ### Pkcs10Import The `Pkcs10Import` modifier is used to take a PKCS#10 request and add its content to the context. There are different `formatFields` that can be used in \.properties to specify how to treat the PKCS#10 request. #### Syntax pkcs10request.acceptunsigned = pkcs10request.skip-signature-verification = pkcs10request.Z.acceptnodigestinfo = | | | |---------------------------------|----------------------------------------------------------------------------------------------------------------| | \ | Value: true \| false Set to true to accept a PKCS#10 request without any signature. Default is false. | | \ | Value: true \| false Set to true to accept a PKCS#10 request with invalid signature. Default is false. | | \ | Value: true \| false Set to true to accept a PKCS#10 request signature without 'digestInfo'. Default is false. | #### Example This example shows how to use **Pkcs10Import** in a ***\.properties*** file: handler.x.filter = certificates/pkcs10 handler.x.tokenprocedure = Token Procedure Name handler.x.format = api/certificates-pkcs10 handler.x.formatFields.1 = pkcs10request.skip-signature-verification = true ### CertificateReader `CertificateReader` is a module unique to Protocol Gateway. Its function is to extract the client certificate used to authenticate to Protocol Gateway. It supports certificates from client TLS through Tomcat, or the signing certificate in a CMP request. It extracts information from the certificate into the context, and this information can then be used with `FieldComposer`, `FieldOperator` and `RequestVerifier` to manipulate and verify the information. #### Syntax CertificateReader.Source = CertificateReader.Attribute. = | | | |---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | \ | Value: CMP \| TLS If CMP is entered, the signing certificate of the CMP request is used. If TLS is entered, the client certificate used to authenticate to Protocol Gateway is used. | | \ | A unique identifier for an attribute to extract, starting with 0. If issuer. is prepended to the attribute, it means that it will try to get the attribute from the signing certificate's issuer's Subject. | | \ | The name to extract from the certificate, specified with FieldOperator syntax. If san. is prepended to the attribute, it means that it will try to get the attribute from the SubjectAlternativeName of the certificate. The attributes will be placed in .value of the same index after extraction from the certificate, e.g. CertificateReader.attribute.\.value. | #### Example This example shows how to use `CertificateReader` in a ***\.properties*** file: ; Read the common name from the TLS client certificate with CertificateReader handler.x.formatFields.0 = CertificateReader.Source = TLS handler.x.formatFields.1 = CertificateReader.Attribute.0 = commonname ### FieldOperator The `FieldOperator` modifier is a general utility module for simple manipulation of fields in the Certificate context. This example shows how to use `FieldOperator` in a ***\.properties*** file: ; Copy the extracted common name to the common name ; of the certificate request with FieldOperator handler.x.formatFields.2 = FieldOperator.a.copy = CertificateReader.Attribute.0.value, certrequests:0:commonname.value, overwrite ; Remove any periods in the common name with FieldOperator ; using Regular Expressions handler.x.formatFields.3 = FieldOperator.b.replace = certrequests:0:commonname.value, certrequests:0:commonname.value, \., overwrite ### FieldComposer The `FieldComposer` modifier is used to produce new or to replace existing Distinguished Name attributes from attributes present in the certificate request. This example shows how to use `FieldComposer` in a ***\.properties*** file: #### **Example: FieldComposer in \.properties file** ; Add @mycompany.my to the common name with FieldComposer handler.x.formatFields.4 = FieldComposer.certrequests:0:commonname.replace = true handler.x.formatFields.5 = FieldComposer.certrequests:0:commonname.rule = certrequests:0:commonname.value + "@mycompany.my" handler.x.formatFields.6 = RequestVerifier.Rule.0 = MustMatch handler.x.formatFields.7 = RequestVerifier.Rule.0.Attribute = commonname.value handler.x.formatFields.8 = RequestVerifier.Rule.0.Regex = .+@mycompany\.my ### RequestVerifier The `RequestVerifier` modifier is a general utility that can deny requests according to a set of rules. This example shows how to use `RequestVerifier` in a ***\.properties*** file: ; Verify that the common name looks as desired with RequestVerifier. ; Note that RequestVerifier verifies all certificate requests this way, ; if multiple were sent in to Protocol Gateway. handler..formatFields.0 = RequestVerifier.Rule.0 = MustMatch handler..formatFields.1 = RequestVerifier.Rule.0.attribute = commonname.value handler..formatFields.2 = RequestVerifier.Rule.0.regex = .+@mycompany\.my ### OcspCheckModifier The purpose of the `OcspCheckModifier` is to perform an OCSP check for the issued certificate and to verify that the certificate status is not "non-issued" before moving on to the next modifier. The modifier can be used when one wants to minimize the risk for clients to receive certificates with status "nonissued" ("Revoked" with reason "on hold") if they perform an OCSP check when receiving the certificate from CM. This modifier can be used in both PGW and CF. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Change domain view in Certificate Manager This article describes how to make a temporary change of an officer's home domain in the Domain hierarchy in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). The domains are used in [CA administration tasks](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) in Certificate Manager. This task is done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). ## Prerequisites The following prerequisites apply: * An administration officer must sign the request. * The officer must have the following role: * Use AWB ## Step-by-step instruction ### Change domain view 1. In AWB, select **View \> Change Domain View**. 2. In the **Select Domain** dialog, select the domain you want to show as the top domain in the explorer bar. 3. Click **OK**. The selected domain will now appear in the top position. To view the full Domain Hierarchy, repeat the procedure but select **Back to home domain**. The domain that is set when an officer is created determines which top level that officer is able to see. ## Related information * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [CA administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/authority-administration-tasks-in-certificate-manager.md) * [Domain tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/domain-tasks-in-certificate-manager.md) * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # Change operation mode of Certificate Manager This article describes how to change operation mode in [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) (CM). CM can be operated in two different modes: * normal mode - all functions of the system are available * maintenance mode - only certificate revocation tasks are available The maintenance mode can be useful during tests that are done after a system upgrade or a configuration change. This task is done in the [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md). ## Prerequisites The following prerequisites apply: * Two administration officers must sign the request. * Both officers must have the following roles: * Use AWB * A connection to the CM host must have been established. See [Connect to a Certificate Manager host](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/connect-to-a-certificate-manager-host.md). ## Step-by-step instruction ### Change operation mode 1. In AWB, select **Tools \> Maintenance mode...** 2. In the **Maintenance mode** dialog box, select or deselect **Enable Maintenance mode**. 3. Click **OK**. 4. The **Signature** dialog box appears. See [Sign tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/sign-tasks-in-certificate-manager.md) for more information. Signing completes the task and returns you to the AWB window. Maintenance mode closes at restart of the server component Certificate Factory (CF). ## Additional information Useful links * [Smart ID Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15.md) * [Administrator's workbench (AWB)](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administrator-s-workbench-awb.md) * [Administration tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/administration-tasks-in-certificate-manager.md) * [Connect to a Certificate Manager host](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/connect-to-a-certificate-manager-host.md) * [Sign tasks in Certificate Manager](https://doc.nexusgroup.com/nexus-certificate-manager/8.15/sign-tasks-in-certificate-manager.md) Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CM 7.16.1 - Requirements and interoperability This article is valid for Nexus Certificate Manager 7.16.1. All listed hardware and software can be used in supported configurations of the product. Listed third party hardware and software has been verified with the current or a previous version of Nexus Certificate Manager. ## Requirements ### Operating systems * Key Generation System, KGS * Windows Server 2012 R2 * Windows Server 2016 * Windows 7, 8.1, 10 * CM Clients * Windows XP SP3 * Windows Vista SP1 * Windows 7, 8.1, 10 * Windows Server 2012 R2, 2016 * Red Hat Enterprise Linux 6/7 * CentOS 6/7 * CM Server * Windows Server 2012 R2 * Windows Server 2016 * Red Hat Enterprise Linux 6/7 * CentOS 6/7 ### Database versions * Microsoft SQL Server Express and Enterprise editions: * 2008 SP2, 2008 R2, 2012 SP4, 2016. * Oracle Express and Enterprise editions: * 10g, 11g. 12c when upgraded from 11g * PostgreSQL: * 9.5 ### Java Virtual Machine * CM Server * Oracle Java SE JRE 8u151 (64 bit) or a later 1.8-release * CM Clients * Oracle JRE 8u151 (32 or 64 bit) or a later 1.8-release ### Web application server CM Web Services and Protocol Gateway servlets run on Apache Tomcat version 8. ### Nexus Personal Desktop Nexus Personal Desktop is middleware for use on CM clients, for officer smart card authentication and personalization of smart cards: * CM clients and CM SDK on Windows: Nexus Personal Desktop 4.28.2. * CM clients and CM SDK on RedHat: Nexus Personal Desktop 4.28.2. ## Interoperability ### Formats and standards #### Certificate formats * X.509/RFC 3280/RFC 5280/RFC 6818 certificates, configurable profiles * X.509/RFC 3281 attribute certificates * Common PKI (alias ISISMTT) v2.0 private extensions, private attributes and optional SigG-Profile * Card Verifiable Certificates (CVC) according to Gematik specification Electronic Health Card, Part 1, v2.0.0 (Dec. 2007). Generations G0, G1 and G2. CPI types: 3, 4, 21, 22 and 70. CV certificates must be issued over CM SDK. * Tachograph certificates * Certificate Transparency Precertificate, RFC 6962 * PKIX and ETSI Qualified Certificates * OpenPGP V4 keys and certificates * Extended Validation certificates * Swedish eID certificate profile as defined by the Swedish e-identification board #### Certificate Revocation List (CRL) formats * X.509/RFC3280/RFC5280 CRL * Full and delta CRL * Direct and indirect CRL * Partitioning according to revocation reasons * Immediate CRL issuing option: besides the regular issuing, a CRL can be generated immediately at revocation of a certificate #### Certificate Issuance List A Nexus proprietary format used by CM to inform the Nexus OCSP Responder about issued or activated certificates to enable the non-issued concept of RFC 6960 and for activation of user certificates. The CIL format is similar to CRL in structure and is signed alike by the CA. The following types of CILs are provided: * Complete CIL * Size segmented CILs * Delta CIL #### Certificate Transparency Support for precertificates according to RFC 6962, Certificate Transparency, with version 1 Signed Certificate Timestamps (SCTs) and Log servers. #### Algorithms and key types * CA signatures: RSA, RSASSA-PSS, DSA Key lengths as supported by HSM (e.g. RSA 1024 - 16384 bit). Algorithms: SHA-1, SHA-256, SHA-384, SHA-512, RipeMD-160 * CA signatures: EC, Prime field based ECDSA algorithms with named curves as supported by HSM, hash functions as above * End user keys: RSA, 1024-4096 bits (soft tokens and on smart card/token type) * End user keys: EC, Prime field based ECDSA algorithms with arbitrary curve parameters (only on smart cards). Certificates for ECDSA keys can be requested only via CM SDK #### Certificate enrollment protocols In addition to using the standard CM clients for certificate enrollment can third party devices, clients and servers enroll for certificates directly by support of any of the following protocols: * **SCEP** - Simple Certificate Enrollment Protocol, draft-nourse-scep-23 * **CMP** - Certificate Management Protocol, RFC 4210, RFC 421 * **CMC** - Certificate Management over CMS, RFC 5273 * **EST** -- Enrollment over Secure Transport, RFC 7030 * **EST-coaps** -- EST over coaps, IETF draft * **CM SDK** -- CM Software Development Kit * **SOAP** -- Web Services * **WinEP** - Windows certificate auto enrollment using Windows certificate templates #### Monitoring * Operational logs and signed audit logs * Ping-request for system health checks * SNMP v1, v2c, v3 * Syslog #### Software token formats * PKCS#12 v1.1, according to RFC 7292 * PGP, OpenPGP V4 keys and certificates ### Smart cards Smart card support as provided in middleware used by card personalization software, for example CM clients, Smart ID Identity Manager, and SmartAct. Currently available cards supported by Nexus Personal Desktop: * Atos CardOS 4.4, 5.0, 5.3 * Gemalto IDClassic 340 * Gemalto IDPrime MD 840 Nexus Profile. Gemalto product name: ENT_Nexus_IDPrime MD 840_PPR. PDM-Customer Item: C1105591 A The smart cards must be prepared with the card profiles delivered with CM, in accordance with ISO/IEC 7816-15:2004. ### Third-party software #### X.500 directories Certificate Manager supports directory servers compliant with LDAPv3 and X.500 for retrieving user data, publication of certificates and CRLs. Certificate Manager is tested and commonly used with, but not limited to, the following directory servers: * Atos DirX Directory * ApacheDS * Microsoft Active Directory * OpenLDAP #### Mobile Device Management solutions MDM software that supports SCEP can request certificates for registered devices. Nexus has explicitly verified the following software: * MobileIron * VMware AirWatch ### Third-party hardware #### Firewalls and routers Certificate enrolment for firewalls and network equipment using SCEP is based on version: draft-nourse-scep-23. The following devices are explicitly verified: * Cisco -- current SCEP compatible IOS and ASA versions * Fortinet FortiGate firewall series with up-to-date firmware #### Hardware Security Modules A PKCS#11 compliant device can be used for handling of CA key pairs, system keys, protection of archived keys, and for key generation. The following devices are explicitly verified: * AEP Systems Sureware Keyper, FIPS 140-1 level 4 * Atos Bull Trustway Proteccio NetHSM o Note: Only verified with CIS, not with CCM and KAR. * DocuSign ARX PrivateServer * Gemalto SafeNet ProtectServer Internal - Express 2 * Gemalto SafeNet ProtectServer External 2 * Gemalto SafeNet Luna CA3, FIPS 140-1 lvl 3 * Gemalto SafeNet Luna CA4, FIPS 140-2 lvl 3 * Gemalto SafeNet Luna SA 4.4, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna SA 5.0, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna G5 * IBM 4758, FIPS 140-1 level 3 and 4 * Thales nShield Connect+, FIPS 140-2 level 3 * Thales nShield Solo+, FIPS 140-2 level 3 * Thales nShield Edge * Thales WebSentry PCI, FIPS 140-1 level 4 * Thales WebSentry Ethernet, FIPS 140-1 level 4 * Utimaco CryptoServer Security Server CS 10/50 LAN/PCI, FIPS 140-2 level 3 (level 4 for physical) * Utimaco CryptoServer Security Server Se 10/50/400/1000 LAN/PCI, FIPS 140-2 level 3 PIN decryption is not allowed using a FIPS mode HSM. #### Card stackers Stackers used for smart card handling with KGS. * Fischer Electronicsysteme GmbH * Zeitcontrol MKW Professional. #### Card printers Mass production of cards with card printers is enabled in Registration Authority and Batch Explorer clients by using the Nexus Card SDK. Card SDK enables card printing and feeding of cards, while Nexus Personal handles chip personalization. * Printer models as supported by the Nexus Card SDK. The printer must be equipped with a smart card chip coupler that can be accessed over USB from the client computer. A PC/SC driver has to be installed on the client. * A license for Nexus Card SDK must be purchased separately. #### PIN letter printers Printers using a vendor provided driver is expected to work with CM Secure Printer for PIN letters. Dot matrix printers, capable of printing on 3-layer PIN envelopes, which have been explicitly tested: * Tally T2340/24 * EPSON LQ-300, 300+II Laser printers can be used for printing PIN letters equipped with a removable PIN protection label. #### Smart card readers Readers for personalization of cards and for using smart card based CM officers with the CM clients. * PC/SC compliant card readers. * PC/SC 2.01 Part 10 compliant PIN-pad readers * HID/Omnikey 6121 Mobile USB smart card reader (to be used with smart cards in SIM format). #### LTE Devices Equipment that supports SCEP or CMP can request certificates after being registered in CM. The following devices are explicitly verified: * Airspan AirHarmony 1000 ENB (CMP) * Airvana/Commscope OneCell (CMP) * Alcatel Lucent 9412 (CMP) * CISCO 7600 Series Routers with SAMI (CMP) * Ericsson RBS6000 (SCEP) * Ericsson RBS6201 (CMP) * Huawei ENB (CMP) * Huawei Femtocell BTS3202H, 3202E (CMP) * Juniper SRX (SCEP) * Nokia Networks ENB (CMP) * Nokia Networks Flexi Zone micro (CMP) ### High availability solutions Different types of high availability techniques can be used with the CM core components Certificate Factory (CF) and Certificate Issuing System (CIS): * Active/passive dual-node hardware cluster using clustering software supported by the OS: Microsoft Windows Server Failover Clustering and Red Hat Cluster High Availability. * Active/active, unlimited number of active nodes behind a load balancer. This alternative provides performance scalability in addition to HA. * High Availability functionality as provided in virtualization software solutions, for example, VMware vSphere HA. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CM 7.17 - Requirements and interoperability This article is valid for Nexus Certificate Manager 7.17.0. All listed hardware and software can be used in supported configurations of the product. Listed third party hardware and software has been verified with the current or a previous version of Nexus Certificate Manager. ## Requirements ### Operating systems * Key Generation System, KGS * Windows Server 2012 R2 * Windows Server 2016 * Windows 7, 8.1, 10 * CM Clients * Windows XP SP3 * Windows Vista SP1 * Windows 7, 8.1, 10 * Windows Server 2012 R2, 2016 * Red Hat Enterprise Linux 6/7 o SUSE Linux Enterprise Server 12 o OpenSUSE Leap 42 * CentOS 6/7 * CM Server * Windows Server 2012 R2 * Windows Server 2016 * Red Hat Enterprise Linux 6/7 o SUSE Linux Enterprise Server 12 o OpenSUSE Leap 42 * CentOS 6/7 ### Database versions * Microsoft SQL Server Express and Enterprise editions: * 2008 SP2, 2008 R2, 2012 SP4, 2016. * Oracle Express and Enterprise editions: * 10g, 11g. 12c * PostgreSQL: * 10.0 ### Java Virtual Machine * CM Server * Oracle Java SE JRE 8u161 (64 bit) or a later 1.8-release * CM Clients * Oracle JRE 8u161 (32 or 64 bit) or a later 1.8-release ### Web application server CM Web Services and Protocol Gateway servlets run on Apache Tomcat version 8.5. ### Nexus Personal Desktop Nexus Personal Desktop is middleware for use on CM clients, for officer smart card authentication and personalization of smart cards: * CM clients and CM SDK on Windows: Nexus Personal Desktop 4.28.2. * CM clients and CM SDK on RedHat: Nexus Personal Desktop 4.28.2. ## Interoperability ### Formats and standards #### Certificate formats * X.509/RFC 3280/RFC 5280/RFC 6818 certificates, configurable profiles * X.509/RFC 3281 attribute certificates * Common PKI (alias ISISMTT) v2.0 private extensions, private attributes and optional SigG-Profile * Card Verifiable Certificates (CVC). CV certificates must be issued over CM SDK. The following types are supported: * according to Gematik specification Electronic Health Card, Part 1, v2.0.0 (Dec. 2007). Generations G0, G1 and G2. CPI types: 3, 4, 21, 22 and 70. o according to the BSI Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token. CPI type: 0. * Tachograph certificates * Certificate Transparency Precertificate, RFC 6962 * PKIX and ETSI Qualified Certificates * OpenPGP V4 keys and certificates * Extended Validation certificates * Swedish eID certificate profile as defined by the Swedish e-identification board #### Certificate Revocation List (CRL) formats * X.509/RFC3280/RFC5280 CRL * Full and delta CRL * Direct and indirect CRL * Partitioning according to revocation reasons * Immediate CRL issuing option: besides the regular issuing, a CRL can be generated immediately at revocation of a certificate #### Certificate Issuance List A Nexus proprietary format used by CM to inform the Nexus OCSP Responder about issued or activated certificates to enable the non-issued concept of RFC 6960 and for activation of user certificates. The CIL format is similar to CRL in structure and is signed alike by the CA. The following types of CILs are provided: * Complete CIL * Size segmented CILs * Delta CIL #### Certificate Transparency Support for precertificates according to RFC 6962, Certificate Transparency, with version 1 Signed Certificate Timestamps (SCTs) and Log servers. Algorithms and key types * CA signatures: RSA, RSASSA-PSS, DSA Key lengths as supported by HSM (e.g. RSA 1024 - 16384 bit). Algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, RipeMD-160 * CA signatures: EC, Prime field based ECDSA algorithms with named curves as supported by HSM, hash functions as above * End user keys: RSA, 1024-4096 bits (soft tokens and on smart card/token type) * End user keys: EC, Prime field based ECDSA algorithms with arbitrary curve parameters (only on smart cards). Certificates for ECDSA keys can be requested only via CM SDK #### Certificate enrollment protocols In addition to using the standard CM clients for certificate enrollment can third party devices, clients and servers enroll for certificates directly by support of any of the following protocols: * **SCEP** - Simple Certificate Enrollment Protocol, draft-nourse-scep-23 * **CMP** - Certificate Management Protocol, RFC 4210, RFC 421 * **CMC** - Certificate Management over CMS, RFC 5273 * **EST** -- Enrollment over Secure Transport, RFC 7030 * **EST-coaps** -- EST over coaps, IETF draft * **CM SDK** -- CM Software Development Kit * **SOAP** -- Web Services * **WinEP** - Windows certificate auto enrollment using Windows certificate templates #### Monitoring * Operational logs and signed audit logs * Ping-request for system health checks * SNMP v1, v2c, v3 * Syslog #### Software token formats * PKCS#12 v1.1, according to RFC 7292 * PGP, OpenPGP V4 keys and certificates ### Smart cards Smart card support as provided in middleware used by card personalization software, for example CM clients, Smart ID Identity Manager, and SmartAct. Currently available cards supported by Nexus Personal Desktop: * Atos CardOS 4.4, 5.0, 5.3 * Gemalto IDClassic 340 * Gemalto IDPrime MD 840 Nexus Profile. Gemalto product name: ENT_Nexus_IDPrime MD 840_PPR. PDM-Customer Item: C1105591 A The smart cards must be prepared with the card profiles delivered with CM, in accordance with ISO/IEC 7816-15:2004. ### Third-party software #### X.500 directories Certificate Manager supports directory servers compliant with LDAPv3 and X.500 for retrieving user data, publication of certificates and CRLs. Certificate Manager is tested and commonly used with, but not limited to, the following directory servers: * Atos DirX Directory * ApacheDS * Microsoft Active Directory * OpenLDAP #### Mobile Device Management solutions MDM software that supports SCEP can request certificates for registered devices. Nexus has explicitly verified the following software: * MobileIron * VMware AirWatch ### Third-party hardware #### Firewalls and routers Certificate enrolment for firewalls and network equipment using SCEP is based on version: draft-nourse-scep-23. The following devices are explicitly verified: * Cisco -- current SCEP compatible IOS and ASA versions * Fortinet FortiGate firewall series with up-to-date firmware #### Hardware Security Modules A PKCS#11 compliant device can be used for handling of CA key pairs, system keys, protection of archived keys, and for key generation. The following devices are explicitly verified: * AEP Systems Sureware Keyper, FIPS 140-1 level 4 * Atos Bull Trustway Proteccio NetHSM o Note: Only verified with CIS, not with CCM and KAR. * DocuSign ARX PrivateServer * Gemalto SafeNet ProtectServer Internal - Express 2 * Gemalto SafeNet ProtectServer External 2 * Gemalto SafeNet Luna CA3, FIPS 140-1 lvl 3 * Gemalto SafeNet Luna CA4, FIPS 140-2 lvl 3 * Gemalto SafeNet Luna SA 4.4, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna SA 5.0, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna G5 * IBM 4758, FIPS 140-1 level 3 and 4 * Thales nShield Connect+, FIPS 140-2 level 3 * Thales nShield Solo+, FIPS 140-2 level 3 * Thales nShield Edge * Thales WebSentry PCI, FIPS 140-1 level 4 * Thales WebSentry Ethernet, FIPS 140-1 level 4 * Utimaco CryptoServer Security Server CS 10/50 LAN/PCI, FIPS 140-2 level 3 (level 4 for physical) * Utimaco CryptoServer Security Server Se 10/50/400/1000 LAN/PCI, FIPS 140-2 level 3 PIN decryption is not allowed using a FIPS mode HSM. #### Card stackers Stackers used for smart card handling with KGS. * Fischer Electronicsysteme GmbH * Zeitcontrol MKW Professional. #### Card printers Mass production of cards with card printers is enabled in Registration Authority and Batch Explorer clients by using the Nexus Card SDK. Card SDK enables card printing and feeding of cards, while Nexus Personal handles chip personalization. * Printer models as supported by the Nexus Card SDK. The printer must be equipped with a smart card chip coupler that can be accessed over USB from the client computer. A PC/SC driver has to be installed on the client. * A license for Nexus Card SDK must be purchased separately. #### PIN letter printers Printers using a vendor provided driver is expected to work with CM Secure Printer for PIN letters. Dot matrix printers, capable of printing on 3-layer PIN envelopes, which have been explicitly tested: * Tally T2340/24 * EPSON LQ-300, 300+II Laser printers can be used for printing PIN letters equipped with a removable PIN protection label. #### Smart card readers Readers for personalization of cards and for using smart card based CM officers with the CM clients. * PC/SC compliant card readers. * PC/SC 2.01 Part 10 compliant PIN-pad readers * HID/Omnikey 6121 Mobile USB smart card reader (to be used with smart cards in SIM format). #### LTE Devices Equipment that supports SCEP or CMP can request certificates after being registered in CM. The following devices are explicitly verified: * Airspan AirHarmony 1000 ENB (CMP) * Airvana/Commscope OneCell (CMP) * Alcatel Lucent 9412 (CMP) * CISCO 7600 Series Routers with SAMI (CMP) * Ericsson RBS6000 (SCEP) * Ericsson RBS6201 (CMP) * Huawei ENB (CMP) * Huawei Femtocell BTS3202H, 3202E (CMP) * Juniper SRX (SCEP) * Nokia Networks ENB (CMP) * Nokia Networks Flexi Zone micro (CMP) ### High availability solutions Different types of high availability techniques can be used with the CM core components Certificate Factory (CF) and Certificate Issuing System (CIS): * Active/passive dual-node hardware cluster using clustering software supported by the OS: Microsoft Windows Server Failover Clustering and Red Hat Cluster High Availability. * Active/active, unlimited number of active nodes behind a load balancer. This alternative provides performance scalability in addition to HA. * High Availability functionality as provided in virtualization software solutions, for example, VMware vSphere HA. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CM 7.18.1 - Requirements and interoperability This article is valid for Nexus Certificate Manager 7.18.0 and 7.18.1. All listed hardware and software can be used in supported configurations of the product. Listed third party hardware and software has been verified with the current or a previous version of Nexus Certificate Manager. ## Requirements ### Operating systems * Key Generation System, KGS * Windows Server 2012 R2 * Windows Server 2016 * Windows 7, 8.1, 10 * CM Clients * Windows XP SP3 * Windows Vista SP1 * Windows 7, 8.1, 10 * Windows Server 2012 R2, 2016 * CentOS 7 * Red Hat Enterprise Linux 7 o SUSE Linux Enterprise Server 12 o OpenSUSE Leap 42 * CM Server * Windows Server 2012 R2 * Windows Server 2016 * CentOS 7 * Red Hat Enterprise Linux 7 o SUSE Linux Enterprise Server 12 o OpenSUSE Leap 42 ### Database versions * Microsoft SQL Server Express and Enterprise editions: * 2008 SP2, 2008 R2, 2012 SP4, 2016, 2017 (**Note!** Version 2017 is only supported by CM 7.18.1). * Oracle Express and Enterprise editions: * 10g, 11g. 12c, 19c * PostgreSQL: * 10.0 * MySQL * 8.0 ### Java Virtual Machine * CM Server * Oracle Java SE JRE 11, OpenJDK 11. (64 bit). * CM Clients * Oracle Java SE JRE 11, OpenJDK 11. (32/64 bit) * CM SDK * Oracle Java SE JRE 11, OpenJDK 11, JRE 8. (32/64 bit.) ### Web application server CM Web Services and Protocol Gateway servlets run on Apache Tomcat version 9.0. ### Nexus Personal Desktop Nexus Personal Desktop is middleware for use on CM clients, for officer smart card authentication and personalization of smart cards: * CM clients and CM SDK on Windows: Nexus Personal Desktop 4.29.8. * CM clients and CM SDK on RedHat and SUSE: Nexus Personal Desktop 4.29.8. ## Interoperability ### Formats and standards #### Certificate formats * X.509/RFC 3280/RFC 5280/RFC 6818 certificates, configurable profiles. * X.509/RFC 3281 attribute certificates. * Common PKI (alias ISISMTT) v2.0 private extensions, private attributes and optional SigG-Profile. * Card Verifiable Certificates (CVC). CV certificates must be issued over CM SDK. The following types are supported: * according to Gematik specification Electronic Health Card, Part 1, v2.0.0 (Dec. 2007). Generations G0, G1 and G2. CPI types: 3, 4, 21, 22 and 70. o according to the BSI Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token. CPI type: 0. * Tachograph certificates. * Certificate Transparency Precertificate, RFC 6962 * IEEE 1609.2 certificates for CAs, sub CAs and end-entities in V2X PKI's. * PKIX and ETSI Qualified Certificates. * OpenPGP V4 keys and certificates, RFC 4880. * Extended Validation certificates. * Swedish eID certificate profile as defined by the Swedish e-identification board. * PSD2 Qualified Certificates, as specified in ETSI TS 119 495. #### Certificate Revocation List (CRL) formats * X.509/RFC3280/RFC5280 CRL. * Full and delta CRL. * Direct and indirect CRL. * Partitioning according to revocation reasons. * Immediate CRL issuing option: besides the regular issuing, a CRL can be generated immediately at revocation of a certificate. #### Certificate Issuance List A Nexus proprietary format used by CM to inform the Nexus OCSP Responder about issued or activated certificates to enable the non-issued concept of RFC 6960 and for activation of user certificates. The CIL format is similar to CRL in structure and is signed alike by the CA. The following types of CILs are provided: * Complete CIL * Size segmented CILs * Delta CIL #### Certificate Transparency Support for precertificates according to RFC 6962, Certificate Transparency, with version 1 Signed Certificate Timestamps (SCTs) and Log servers. Algorithms and key types * CA signatures: RSA, RSASSA-PSS, DSA Key lengths as supported by HSM (e.g. RSA 1024 - 16384 bit). Algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, RipeMD-160. * CA signatures: EC, Prime field based ECDSA algorithms with named curves as supported by HSM, hash functions as above. * End user keys: RSA, 1024-4096 bits (soft tokens and on smart card/token type). * End user keys: EC, Prime field based ECDSA algorithms with arbitrary curve parameters (only on smart cards). Certificates for ECDSA keys can be requested only via CM SDK. #### Certificate enrollment protocols In addition to using the standard CM clients for certificate enrollment can third party devices, clients and servers enroll for certificates directly by support of any of the following protocols: * **SCEP** - Simple Certificate Enrollment Protocol, draft-nourse-scep-23 * **CMP** - Certificate Management Protocol, RFC 4210, RFC 421 * **CMC** - Certificate Management over CMS, RFC 5273 * **EST** -- Enrollment over Secure Transport, RFC 7030 * **EST-coaps** -- EST over coaps, IETF draft * **CM SDK** -- CM Software Development Kit, a Java API. * **CM REST API** - CM RESTful API. * **C2X REST API** - RESTful API for V2X certificate enrolment. * **CM WS**-- SOAP Web Services * **WinEP** - Windows certificate auto enrollment using Windows certificate templates #### Monitoring * Operational logs and signed audit logs * Ping-request for system health checks * SNMP v3 * Syslog #### Software token formats * PKCS#12 v1.1, according to RFC 7292 * PGP, OpenPGP V4 keys and certificates. RFC 4880. ### Smart cards Smart card support as provided in middleware used by card personalization software, for example CM clients, Smart ID Identity Manager, and SmartAct. By default, Certificate Manager uses Nexus Personal Desktop to communicate with smart cards. The following smart cards are supported for personalization: * Atos CardOS 4.4, 5.0, 5.3 * Gemalto IDClassic 340 * Gemalto IDPrime MD 840 Nexus Profile. Gemalto product name: ENT_Nexus_IDPrime MD 840_PPR. PDM-Customer Item: C1105591 A. The smart cards must be prepared with the card profiles delivered with CM, in accordance with ISO/IEC 7816-15:2004. ### Third-party software #### X.500 directories Certificate Manager supports directory servers compliant with LDAPv3 and X.500 for retrieving user data, publication of certificates and CRLs. Certificate Manager is tested and commonly used with, but not limited to, the following directory servers: * Atos DirX Directory * ApacheDS * Microsoft Active Directory * OpenLDAP #### Mobile Device Management solutions MDM software that supports SCEP can request certificates for registered devices. Nexus has explicitly verified the following software: * MobileIron * VMware AirWatch ### Third-party hardware #### Firewalls and routers Certificate enrolment for firewalls and network equipment using SCEP is based on version: draft-nourse-scep-23. The following devices are explicitly verified: * Cisco -- current SCEP compatible IOS and ASA versions * Fortinet FortiGate firewall series with up-to-date firmware #### Hardware Security Modules A PKCS#11 compliant device can be used for handling of CA key pairs, system keys, protection of archived keys, and for key generation. The following devices are explicitly verified: * AEP Systems Sureware Keyper, FIPS 140-1 level 4 * Atos Bull Trustway Proteccio NetHSM o Note: Only verified with CIS, not with CCM and KAR. * DocuSign ARX PrivateServer * Gemalto SafeNet ProtectServer Internal - Express 2 * Gemalto SafeNet ProtectServer External 2 * Gemalto SafeNet Luna CA3, FIPS 140-1 lvl 3 * Gemalto SafeNet Luna CA4, FIPS 140-2 lvl 3 * Gemalto SafeNet Luna SA 4.4, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna SA 5.0, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna G5 * Gemalto SafeNet Luna HSM 6 * Gemalto SafeNet Luna Network HSM 7 * Gemalto SafeNet Luna PCIe HSM 7 * IBM 4758, FIPS 140-1 level 3 and 4 * Thales nShield Connect+, FIPS 140-2 level 3 * Thales nShield Solo+, FIPS 140-2 level 3 * Thales nShield Edge * Thales WebSentry PCI, FIPS 140-1 level 4 * Thales WebSentry Ethernet, FIPS 140-1 level 4 * Utimaco CryptoServer Security Server CS 10/50 LAN/PCI, FIPS 140-2 level 3 (level 4 for physical) * Utimaco CryptoServer Security Server Se 12/52/420/1200 LAN/PCI, FIPS 140-2 level 3 PIN decryption is not allowed using a FIPS mode HSM. #### Card stackers Stackers used for smart card handling with KGS. * Fischer Electronicsysteme GmbH * Zeitcontrol MKW Professional. #### Card printers Mass production of cards with card printers is enabled in Registration Authority and Batch Explorer clients by using Nexus Card SDK. Card SDK enables card printing and feeding of cards, while Nexus Personal handles chip personalization. * Printer models as supported by the Nexus Card SDK. The printer must be equipped with a smart card chip coupler that can be accessed over USB from the client computer. A PC/SC driver has to be installed on the client. * A license for Nexus Card SDK must be purchased separately. #### PIN letter printers Printers using a vendor provided driver is expected to work with CM Secure Printer for PIN letters. Dot matrix printers, capable of printing on 3-layer PIN envelopes, which have been explicitly tested: * Tally T2340/24 * EPSON LQ-300, 300+II Laser printers can be used for printing PIN letters equipped with a removable PIN protection label. #### Smart card readers Readers for personalization of cards and for using smart card based CM officers with the CM clients. * PC/SC compliant card readers. * PC/SC 2.01 Part 10 compliant PIN-pad readers * HID/Omnikey 6121 Mobile USB smart card reader (to be used with smart cards in SIM format). #### LTE Devices LTE equipment that supports SCEP or CMP can request certificates after being registered in CM. The following devices are explicitly verified: * Airspan AirHarmony 1000 ENB (CMP) * Airvana/Commscope OneCell (CMP) * Alcatel Lucent 9412 (CMP) * CISCO 7600 Series Routers with SAMI (CMP) * Ericsson RBS6000 (SCEP) * Ericsson RBS6201 (CMP) * Fortinet Fortigate Next Generation Firewall (SCEP, CMPv2) * Huawei ENB (CMP) * Huawei Femtocell BTS3202H, 3202E (CMP) * Juniper SRX (SCEP) * NEC eNB. * Nokia Networks ENB (CMP) * Nokia Networks Flexi Zone micro (CMP) ### High availability solutions Different types of high availability techniques can be used with the CM core components Certificate Factory (CF) and Certificate Issuing System (CIS): * Active/passive dual-node hardware cluster using clustering software supported by the OS: Microsoft Windows Server Failover Clustering and Red Hat Cluster High Availability. * Active/active, unlimited number of active nodes behind a load balancer. This alternative provides performance scalability in addition to HA. * High Availability functionality as provided in virtualization software solutions, for example, VMware vSphere HA. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CM 8.0 - Requirements and interoperability This article is valid for Nexus Certificate Manager 8.0 All listed hardware and software can be used in supported configurations of the product. Listed third party hardware and software has been verified with the current or a previous version of Nexus Certificate Manager. ## Requirements ### Operating systems * Key Generation System, KGS * Windows Server 2012 R2 * Windows Server 2016 * Windows 7, 8.1, 10 * CM Clients * Windows 7, 8.1, 10 * Windows Server 2012 R2, 2016 * CentOS 7 * Red Hat Enterprise Linux 7 o SUSE Linux Enterprise Server 15 o OpenSUSE Leap 15 * CM Server * Windows Server 2012 R2 * Windows Server 2016 * CentOS 7 * Red Hat Enterprise Linux 7 o SUSE Linux Enterprise Server 15 o OpenSUSE Leap 15 ### Database versions * Microsoft SQL Server Express and Enterprise editions: * 2012, 2017 * Oracle Express and Enterprise editions: * 12c, 18.3 * PostgreSQL: * 10.0, 11, 11.5 * MySQL * 8.0 ### Java Virtual Machine **CM Server** * Oracle Java SE JRE 11, OpenJDK 11. (64 bit). * On Windows platforms with Oracle Java installed, the newest Java is used by default, even if multiple Java versions are installed. * On Windows platforms with OpenJDK Java installed, the Java to be used has to be manually specified, see [Install CM server components on Windows](https://nexusdoc.atlassian.net/display/NDA/8.0+-+Install+CM+server+components+on+Windows), heading "Java version". **CM Clients** * Oracle Java SE JRE 11, OpenJDK 11. (32/64 bit) * For Linux, 64-bit Java is required in order to use Personal. * For Windows with OpenJDK Java installed, the Java to be used has to be manually specified, see [Launch CM clients](https://nexusdoc.atlassian.net/display/NDA/8.0+-+Launch+CM+clients), heading "Specify JRE". **CM SDK** * Oracle Java SE JRE 11, OpenJDK 11, JRE 8. (32/64 bit.) ### Web application server CM Web Services and Protocol Gateway servlets run on Apache Tomcat version 9.0. ### Nexus Personal Desktop Nexus Personal Desktop is middleware for use on CM clients, for officer smart card authentication and personalization of smart cards: * CM clients and CM SDK on Windows: Nexus Personal Desktop 5.1.0. * CM clients and CM SDK on RedHat and SUSE: Nexus Personal Desktop 5.1.0. ## Interoperability ### Formats and standards #### Certificate formats * X.509/RFC 3280/RFC 5280/RFC 6818 certificates, configurable profiles. * X.509/RFC 3281 attribute certificates. * Common PKI (alias ISISMTT) v2.0 private extensions, private attributes and optional SigG-Profile. * Card Verifiable Certificates (CVC). CV certificates must be issued over CM SDK. The following types are supported: * according to Gematik specification Electronic Health Card, Part 1, v2.0.0 (Dec. 2007). Generations G0, G1 and G2. CPI types: 3, 4, 21, 22 and 70. o according to the BSI Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token. CPI type: 0. * Tachograph certificates. * Certificate Transparency Precertificate, RFC 6962 * IEEE 1609.2 certificates for CAs, sub CAs and end-entities in V2X PKI's. * PKIX and ETSI Qualified Certificates. * OpenPGP V4 keys and certificates, RFC 4880. * Extended Validation certificates. * Swedish eID certificate profile as defined by the Swedish e-identification board. * PSD2 Qualified Certificates, as specified in ETSI TS 119 495. #### Certificate Revocation List (CRL) formats * X.509/RFC3280/RFC5280 CRL. * Full and delta CRL. * Direct and indirect CRL. * Partitioning according to revocation reasons. * Immediate CRL issuing option: besides the regular issuing, a CRL can be generated immediately at revocation of a certificate. #### Certificate Issuance List A Nexus proprietary format used by CM to inform the Nexus OCSP Responder about issued or activated certificates to enable the non-issued concept of RFC 6960 and for activation of user certificates. The CIL format is similar to CRL in structure and is signed alike by the CA. The following types of CILs are provided: * Complete CIL * Size segmented CILs * Delta CIL #### Certificate Transparency Support for precertificates according to RFC 6962, Certificate Transparency, with version 1 Signed Certificate Timestamps (SCTs) and Log servers. #### Algorithms and key types * CA signatures: RSA, RSASSA-PSS, DSA Key lengths as supported by HSM (e.g. RSA 1024 - 16384 bit). Algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, RipeMD-160. * CA signatures: EC, Prime field based ECDSA algorithms with named curves as supported by HSM, hash functions as above. * End user keys: RSA, 1024-4096 bits (soft tokens and on smart card/token type). * End user keys: EC, Prime field based ECDSA algorithms with arbitrary curve parameters (only on smart cards). Certificates for ECDSA keys can be requested only via CM SDK. #### Certificate enrollment protocols In addition to using the standard CM clients for certificate enrollment can third party devices, clients and servers enroll for certificates directly by support of any of the following protocols: * **SCEP** - Simple Certificate Enrollment Protocol, draft-nourse-scep-23 * **CMP** - Certificate Management Protocol, RFC 4210, RFC 421 * **CMC** - Certificate Management over CMS, RFC 5273 * **EST** -- Enrollment over Secure Transport, RFC 7030 * **EST-coaps** -- EST over coaps, IETF draft * **CM SDK** -- CM Software Development Kit, a Java API. * **CM REST API** - CM RESTful API. * **C2X REST API** - RESTful API for V2X certificate enrolment. * **CM WS**-- SOAP Web Services * **WinEP** - Windows certificate auto enrollment using Windows certificate templates #### Monitoring * Operational logs and signed audit logs * Ping-request for system health checks * SNMP v3 * Syslog #### Software token formats * PKCS#12 v1.1, according to RFC 7292 * PGP, OpenPGP V4 keys and certificates. RFC 4880. ### Smart cards Smart card support as provided in middleware used by card personalization software, for example CM clients, Smart ID Identity Manager, and SmartAct. By default, Certificate Manager uses Nexus Personal Desktop to communicate with smart cards. The following smart cards are supported for personalization: * Atos CardOS 4.4, 5.0, 5.3 * Gemalto IDClassic 340 * Gemalto IDPrime MD 840 Nexus Profile. Gemalto product name: ENT_Nexus_IDPrime MD 840_PPR. PDM-Customer Item: C1105591 A. The smart cards must be prepared with the card profiles delivered with CM, in accordance with ISO/IEC 7816-15:2004. ### Third-party software #### X.500 directories Certificate Manager supports directory servers compliant with LDAPv3 and X.500 for retrieving user data, publication of certificates and CRLs. Certificate Manager is tested and commonly used with, but not limited to, the following directory servers: * Atos DirX Directory * ApacheDS * Microsoft Active Directory * OpenLDAP #### Mobile Device Management solutions MDM software that supports SCEP can request certificates for registered devices. Nexus has explicitly verified the following software: * MobileIron * VMware AirWatch ### Third-party hardware #### Firewalls and routers Certificate enrolment for firewalls and network equipment using SCEP is based on version: draft-nourse-scep-23. The following devices are explicitly verified: * Cisco -- current SCEP compatible IOS and ASA versions * Fortinet FortiGate firewall series with up-to-date firmware #### Hardware Security Modules A PKCS#11 compliant device can be used for handling of CA key pairs, system keys, protection of archived keys, and for key generation. The following devices are explicitly verified: * AEP Systems Sureware Keyper, FIPS 140-1 level 4 * Atos Bull Trustway Proteccio NetHSM o Note: Only verified with CIS, not with CF and KAR. * DocuSign ARX PrivateServer * Gemalto SafeNet ProtectServer Internal - Express 2 * Gemalto SafeNet ProtectServer External 2 * Gemalto SafeNet Luna CA3, FIPS 140-1 lvl 3 * Gemalto SafeNet Luna CA4, FIPS 140-2 lvl 3 * Gemalto SafeNet Luna SA 4.4, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna SA 5.0, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna G5 * Gemalto SafeNet Luna HSM 6 * Gemalto SafeNet Luna Network HSM 7 * Gemalto SafeNet Luna PCIe HSM 7 * IBM 4758, FIPS 140-1 level 3 and 4 * Thales nShield Connect+, FIPS 140-2 level 3 * Thales nShield Solo+, FIPS 140-2 level 3 * Thales nShield Edge * Thales WebSentry PCI, FIPS 140-1 level 4 * Thales WebSentry Ethernet, FIPS 140-1 level 4 * Utimaco CryptoServer Security Server CS 10/50 LAN/PCI, FIPS 140-2 level 3 (level 4 for physical) * Utimaco CryptoServer Security Server Se 12/52/420/1200 LAN/PCI, FIPS 140-2 level 3 PIN decryption is not allowed using a FIPS mode HSM. #### Card stackers Stackers used for smart card handling with KGS. * Fischer Electronicsysteme GmbH * Zeitcontrol MKW Professional. #### Card printers Mass production of cards with card printers is enabled in Registration Authority and Batch Explorer clients by using Nexus Card SDK. Card SDK enables card printing and feeding of cards, while Nexus Personal handles chip personalization. * Printer models as supported by the Nexus Card SDK. The printer must be equipped with a smart card chip coupler that can be accessed over USB from the client computer. A PC/SC driver has to be installed on the client. * A license for Nexus Card SDK must be purchased separately. #### PIN letter printers Printers using a vendor provided driver is expected to work with CM Secure Printer for PIN letters. Dot matrix printers, capable of printing on 3-layer PIN envelopes, which have been explicitly tested: * Tally T2340/24 * EPSON LQ-300, 300+II Laser printers can be used for printing PIN letters equipped with a removable PIN protection label. #### Smart card readers Readers for personalization of cards and for using smart card based CM officers with the CM clients. * PC/SC compliant card readers. * PC/SC 2.01 Part 10 compliant PIN-pad readers * HID/Omnikey 6121 Mobile USB smart card reader (to be used with smart cards in SIM format). #### LTE Devices LTE equipment that supports SCEP or CMP can request certificates after being registered in CM. The following devices are explicitly verified: * Airspan AirHarmony 1000 ENB (CMP) * Airvana/Commscope OneCell (CMP) * Alcatel Lucent 9412 (CMP) * CISCO 7600 Series Routers with SAMI (CMP) * Ericsson RBS6000 (SCEP) * Ericsson RBS6201 (CMP) * Fortinet Fortigate Next Generation Firewall (SCEP, CMPv2) * Huawei ENB (CMP) * Huawei Femtocell BTS3202H, 3202E (CMP) * Juniper SRX (SCEP) * NEC eNB. * Nokia Networks ENB (CMP) * Nokia Networks Flexi Zone micro (CMP) ### High availability solutions Different types of high availability techniques can be used with the CM core components Certificate Factory (CF) and Certificate Issuing System (CIS): * Active/passive dual-node hardware cluster using clustering software supported by the OS: Microsoft Windows Server Failover Clustering and Red Hat Cluster High Availability. * Active/active, unlimited number of active nodes behind a load balancer. This alternative provides performance scalability in addition to HA. * High Availability functionality as provided in virtualization software solutions, for example, VMware vSphere HA. Last updated: April 28, 2026 --- version: "8.15" language: "en" --- # CM 8.1 - Requirements and interoperability This article is valid for Certificate Manager 8.1 and later. All listed hardware and software can be used in supported configurations of the product. Listed third party hardware and software has been verified with the current or a previous version of Certificate Manager. ## Requirements ### Operating systems * Key Generation System, KGS * Windows Server 2012 R2, 2016, 2019 * Windows 7, 8.1, 10 * CM Clients * Windows 7, 8.1, 10 * Windows Server 2016, 2019 * CentOS 7, 8 * Red Hat Enterprise Linux 7, 8 o SUSE Linux Enterprise Desktop 15.1 * OpenSUSE Leap 15 * CM Server * Windows Server 2016, 2019 * CentOS 7, 8 * Red Hat Enterprise Linux 7, 8 o SUSE Linux Enterprise Server 15.1 o OpenSUSE Leap 15 ### Database versions * Microsoft SQL Server Express and Enterprise editions: * 2012, 2017, 2019 * Oracle Express and Enterprise editions: * 18.3, 19 * PostgreSQL: * 11, 11.5, 12 * MySQL * 8.0 * SQLite * 3.31 ### Java Virtual Machine **CM Server** * Oracle Java SE JRE 11, OpenJDK 11. (64 bit). * On Windows platforms with Oracle Java installed, the newest Java is used by default, even if multiple Java versions are installed. * On Windows platforms with OpenJDK Java installed, the Java to be used has to be manually specified, see [8.1 - Install Certificate Manager server components on Windows](https://nexusdoc.atlassian.net/display/NDA/8.1+-+Install+Certificate+Manager+server+components+on+Windows), heading "Java version". **CM Clients** * Oracle Java SE JRE 11, OpenJDK 11. (32/64 bit) * For Linux, 64-bit Java is required in order to use Personal. * For Windows with OpenJDK Java installed, the Java to be used has to be manually specified, see [8.1 - Launch Certificate Manager clients](https://nexusdoc.atlassian.net/display/NDA/8.1+-+Launch+Certificate+Manager+clients), heading "Specify JRE". **CM SDK** * Oracle Java SE JRE 11, OpenJDK 11, JRE 8. (32/64 bit.) ### Web application server CM Web Services and Protocol Gateway servlets run on Apache Tomcat version 9.0. ### Nexus Personal Desktop Nexus Personal Desktop is middleware for use on CM clients, for officer smart card authentication and personalization of smart cards: * CM clients and CM SDK on Windows: Nexus Personal Desktop 5.2.1. * CM clients and CM SDK on RedHat and SUSE: Nexus Personal Desktop 5.2.1. ## Interoperability ### Formats and standards #### Certificate formats * X.509/RFC 3280/RFC 5280/RFC 6818 certificates, configurable profiles. * X.509/RFC 3281 attribute certificates. * Common PKI (alias ISISMTT) v2.0 private extensions, private attributes and optional SigG-Profile. * Card Verifiable Certificates (CVC). CV certificates must be issued over CM SDK. The following types are supported: * according to Gematik specification Electronic Health Card, Part 1, v2.0.0 (Dec. 2007). Generations G0, G1 and G2. CPI types: 3, 4, 21, 22 and 70. o according to the BSI Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token. CPI type: 0. * Smart Tachograph certificates. Generation 1 and Generation 2. * Certificate Transparency Precertificate, RFC 6962 * IEEE 1609.2 certificates for CAs, sub CAs and end-entities in V2X PKI's. * PKIX and ETSI Qualified Certificates. * OpenPGP V4 keys and certificates, RFC 4880. * Extended Validation certificates. * Swedish eID certificate profile as defined by the Swedish e-identification board. * PSD2 Qualified Certificates, as specified in ETSI TS 119 495. #### Certificate Revocation List (CRL) formats * X.509/RFC3280/RFC5280 CRL. * Full and delta CRL. * Direct and indirect CRL. * Partitioning according to revocation reasons. * Immediate CRL issuing option: besides the regular issuing, a CRL can be generated immediately at revocation of a certificate. #### Certificate Issuance List A Nexus proprietary format used by CM to inform the Nexus OCSP Responder about issued or activated certificates to enable the non-issued concept of RFC 6960 and for activation of user certificates. The CIL format is similar to CRL in structure and is signed alike by the CA. The following types of CILs are provided: * Complete CIL * Size segmented CILs * Delta CIL #### Certificate Transparency Support for precertificates according to RFC 6962, Certificate Transparency, with version 1 Signed Certificate Timestamps (SCTs) and Log servers. #### Algorithms and key types * CA signatures: RSA, RSASSA-PSS, DSA Key lengths as supported by HSM (e.g. RSA 1024 - 16384 bit). Algorithms: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, RipeMD-160. * CA signatures: EC, Prime field based ECDSA algorithms with named curves as supported by HSM, hash functions as above. * End user keys: RSA, 1024-4096 bits (soft tokens and on smart card/token type). * End user keys: EC, Prime field based ECDSA algorithms with arbitrary curve parameters (only on smart cards). Certificates for ECDSA keys can be requested only via CM SDK. #### Certificate enrollment protocols Third party devices, clients, servers, and software components with built-in support for standards-based certificate enrollment protocols can benefit from the corresponding server-side support in Certificate Manager. These are the supported standard-based protocols: * **ACME**- Automatic Certificate Management Environment, RFC 8555 * **CMP**- Certificate Management Protocol, RFC 4210, RFC 4211 * **CMC**- Certificate Management over CMS, RFC 5273 * **EST**-- Enrollment over Secure Transport, RFC 7030 * **EST-coaps**-- EST over secure CoAP, IETF draft (draft-ietf-ace-coap-est) * **SCEP**- Simple Certificate Enrollment Protocol, draft-nourse-scep-23 * **WinEP**- Windows certificate auto enrollment using Windows certificate templates In addition to the standards-based protocols, listed above, CM provides protocols that offers additional features for customized clients, web front-ends, etc: * **CM SDK**-- CM Software Development Kit, a Java API. * **CM REST API**- CM RESTful API. * **C2X REST API**- RESTful API for V2X certificate enrolment. * **CM WS**-- SOAP Web Services #### Monitoring * Operational logs and signed audit logs * Ping-request for system health checks * SNMP v3 * Syslog * Metrics #### Software token formats * PKCS#12 v1.1, according to RFC 7292 * PGP, OpenPGP V4 keys and certificates. RFC 4880. ### Smart cards Smart card support as provided in middleware used by card personalization software, for example CM clients, Smart ID Identity Manager, and SmartAct. By default, Certificate Manager uses Nexus Personal Desktop to communicate with smart cards. The following smart cards are supported for personalization: * Atos CardOS 4.4, 5.0, 5.3 * Gemalto IDClassic 340 * Gemalto IDPrime MD 840 Nexus Profile. Gemalto product name: ENT_Nexus_IDPrime MD 840_PPR. PDM-Customer Item: C1105591 A. The smart cards must be prepared with the card profiles delivered with CM, in accordance with ISO/IEC 7816-15:2004. ### Third-party software #### X.500 directories Certificate Manager supports directory servers compliant with LDAPv3 and X.500 for retrieving user data, publication of certificates and CRLs. Certificate Manager is tested and commonly used with, but not limited to, the following directory servers: * Atos DirX Directory * ApacheDS * Microsoft Active Directory * OpenLDAP #### Mobile Device Management solutions MDM software that supports SCEP can request certificates for registered devices. Nexus has explicitly verified the following software: * MobileIron * VMware AirWatch ### Third-party hardware #### Firewalls and routers Certificate enrolment for firewalls and network equipment using SCEP is based on version: draft-nourse-scep-23. The following devices are explicitly verified: * Cisco -- current SCEP compatible IOS and ASA versions * Fortinet FortiGate firewall series with up-to-date firmware #### Hardware Security Modules A PKCS#11 compliant device can be used for handling of CA key pairs, system keys, protection of archived keys, and for key generation. For functional specifications, known issues and limitations related to current PKCS#11 drivers, see each HSM vendor's web site. The following devices are explicitly verified: * AEP Systems Sureware Keyper, FIPS 140-1 level 4 * Atos Bull Trustway Proteccio NetHSM o Note: Only verified with CIS, not with CCM and KAR. * DocuSign ARX PrivateServer * Gemalto SafeNet ProtectServer Internal - Express 2 * Gemalto SafeNet ProtectServer External 2 * Gemalto SafeNet Luna CA3, FIPS 140-1 lvl 3 * Gemalto SafeNet Luna CA4, FIPS 140-2 lvl 3 * Gemalto SafeNet Luna SA 4.4, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna SA 5.0, FIPS 140-2 lvl 3 * Note: Since SafeNet Luna disallow key export when in FIPS mode, enable non-FIPS mode for use with CM KAR, Key Archiving and Recovery. * Gemalto SafeNet Luna G5 * Gemalto SafeNet Luna HSM 6 * Gemalto SafeNet Luna Network HSM 7 * Gemalto SafeNet Luna PCIe HSM 7 * IBM 4758, FIPS 140-1 level 3 and 4 * Nitrokey HSM 2 * Thales nShield Connect+, FIPS 140-2 level 3 * Thales nShield Solo+, FIPS 140-2 level 3 * Thales nShield Edge * Thales WebSentry PCI, FIPS 140-1 level 4 * Thales WebSentry Ethernet, FIPS 140-1 level 4 * Utimaco CryptoServer Security Server CS 10/50 LAN/PCI, FIPS 140-2 level 3 (level 4 for physical) * Utimaco CryptoServer Security Server Se 12/52/420/1200 LAN/PCI, FIPS 140-2 level 3 * Yubico YubiHSM 2 PIN decryption is not allowed using a FIPS mode HSM. #### Card stackers Stackers used for smart card handling with KGS. * Fischer Electronicsysteme GmbH * Zeitcontrol MKW Professional. #### Card printers Mass production of cards with card printers is enabled in Registration Authority and Batch Explorer clients by using Nexus Card SDK. Card SDK enables card printing and feeding of cards, while Nexus Personal handles chip personalization. * Printer models as supported by the Nexus Card SDK. The printer must be equipped with a smart card chip coupler that can be accessed over USB from the client computer. A PC/SC driver has to be installed on the client. * A license for Nexus Card SDK must be purchased separately. #### PIN letter printers Printers using a vendor provided driver is expected to work with CM Secure Printer for PIN letters. Dot matrix printers, capable of printing on 3-layer PIN envelopes, which have been explicitly tested: * Tally T2340/24 * EPSON LQ-300, 300+II Laser printers can be used for printing PIN letters equipped with a removable PIN protection label. #### Smart card readers Readers for personalization of cards and for using smart card based CM officers with the CM clients. * PC/SC compliant card readers. * PC/SC 2.01 Part 10 compliant PIN-pad readers * HID/Omnikey 6121 Mobile USB smart card reader (to be used with smart cards in SIM format). #### LTE Devices LTE equipment that supports SCEP or CMP can request certificates after being registered in CM. The following devices are explicitly verified: * Airspan AirHarmony 1000 ENB (CMP) * Airvana/Commscope OneCell (CMP) * Alcatel Lucent 9412 (CMP) * CISCO 7600 Series Routers with SAMI (CMP) * Ericsson RBS6000 (SCEP) * Ericsson RBS6201 (CMP) * Fortinet Fortigate Next Generation Firewall (SCEP, CMPv2) * Huawei ENB (CMP) * Huawei Femtocell BTS3202H, 3202E (CMP) * Juniper SRX (SCEP) * NEC eNB. * Nokia Networks ENB (CMP) * Nokia Networks Flexi Zone micro (CMP) ### High availability solutions Different types of high availability techniques can be used with the CM core components Certificate Factory (CF) and Certificate Issuing System (CIS): * Active/passive dual-node hardware cluster using clustering software supported by the OS: Microsoft Windows Server Failover Clustering and Red Hat Cluster High Availability. * Active/active, unlimited number of active nodes behind a load balancer. This alternative provides performance scalability in addition to HA. * High Availability functionality as provided in virtualization software solutions, for example, VMware vSphere HA. Last updated: April 28, 2026 [Next Page](https://doc.nexusgroup.com/llms-full.txt/1)