Document toolboxDocument toolbox

Device preregistration for automated enrollment

This article describes preregistration of devices in Smart ID Certificate Manager for automated certificate enrollment.  

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. 

How to register devices

There are four ways to handle registration:

  • Single registration 
    Register devices one-by-one using an appropriate unique identifier, in the Registration Authority (RA). 


  • Bulk registration 
    Import registration records from a batch csv-formatted file to register multiple records, in the Registration Authority (RA), by clicking the Import button in the Order tab. The Import button is displayed depending on the selected input view (GPIV) in the token procedure. See Create token procedure in Certificate Manager.


  • API registration 
    Integrate registration in third party products through the CM SDK. See the CM SDK Javadoc documentation, which is included in the CM distribution.


  • REST API registration 
    Create registrations using the CM REST API. See Certificate Manager (CM) REST API.

For more information, see Allowed domain names for preregistration in Certificate Manager.

Single registration in Registration Authority (RA)

In the RA client, go to the Order tab and select either of the following processes, as described in the respective links:

An empty value for the IP address or serial number of the device in the registration will match any value in the enrollment request.

The configuration of the input view will not affect the available columns in the Recent list, where the value of the FQDN is found in the Common Name column. 

Device registration grouping

Each device registration in CM belongs to the domain of the token procedure used when creating the registration. Registrations from different token procedures can therefore belong to the same domain. When receiving an enrollment request CM finds all registrations with a matching FQDN that is created with a token procedure that is in the same domain as the token procedure used for enrollment. This means that the token procedure used when creating the registration and the token procedure used during enrollment does not need to be the same and that there can be multiple token procedures used for creating registrations, as long as they are in the same domain.

The above means that all the FQDNs of all registrations within a domain must be unique. Creating registrations with identical FQDNs using different token procedures in the same domain is not allowed. If there is a need to create multiple registrations with identical FQDNs (but with differing passwords for example), the token procedures used to create the registrations must be configured into different domains.

Wildcards in registration

Several devices can be registered in one step using wildcard characters when filling in the FQDN field in an order form.

Wildcard examples

If a wildcard (*) is set in the least significant position of the FQDN, then all requests for a certificate with a FQDN matching the wildcard will be accepted (if all other criteria are met).

Example: A registration with FQDN set to *.dept.example.com will match a request with FQDN: router5.dept.example.com.

A wildcard (*) can also be set inside the FQDN in a registration.

Example: A registration with serial-*.example.com will match a request with FQDN: serial-1234.example.com





Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions