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:
- CMP Registration and Enroll Procedure
- See Example: CMP configuration in Protocol Gateway - SCEP Registration and Enroll Procedure
- See Example: SCEP configuration in Protocol Gateway - EST Registration and Enroll Procedure
- See Example: EST configuration in Protocol Gateway
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