Self registration in the Public Web as described here is deprecated. Self registration can be configured in a better way in the RA Web using a role with a public access token.

It is possible to allow users of the public web to create approval requests for new end-entities (under 'Request Registration'). The users' choice of end-entity type and DN fields are confined, for instance, it could be limited to end-user certificates with only the name and e-mail fields being available. The DN fields can then be verified by an administrator.

Note the following properties of the basic solution:

  1. The approval process verifies end entity account creation.
  2. The approval process does not verify CSR public key binding to a specific end entity.

Possible usages of self registration include an almost unlimited set of use cases. The default solution is suitable and configurable for a large set of these use cases and can function as a platform to customize other more specialized use cases. Customization of self registration workflows is a pretty straight forward process.

Configuration

Setting up self registration consists of three steps: creating end-entity and certificate profiles that should be available, configuring email notifications, and configuring self registration in web.properties. First, at least one end-entity profile should be created as follows:

  • The SubjectDN and SubjectAltName fields that should be available must be added. Fields that are marked as modifiable can be modified freely, otherwise, only pre-defined values can be selected by the user. See EJBCA Operations Guide for further information.
  • The user's e-mail can be verified by sending an auto-generated password to it (but this is not the only way to verify the user). The email domain field must be enabled with the Use checkbox, and auto-generated passwords must be enabled. Optionally the domain field may be constrained to particular choices, see the user guide section on end-entity profiles.
  • E-mail validation works by sending the password in a notification message. For this reason, Send Notification must be enabled (check Use and Default), and the other notification fields below it should be filled in. See the section on email notifications.

  • By default, the user will be prompted to fill in the username, but the username can also be generated from a field in the end-entity profile such as CN (common name), see below. 

    Note that sending of a password in an email is not the only way to do things. You can, for example, use multiple notifications where an enrollment link is sent to the user, but the password is sent to an administrator, or an out-of-band delivery service (through local email), or printed on paper. The solutions are highly configurable and adaptable. 

E-mail sending must be configured so that EJBCA can send email through the application server. You may also want to enable notifications to the administrators when there are new approval requests, under System Functions / System Configuration. 

To make the end-entity profiles available in the user interface, certificate types must be added in web.properties using the web.selfreg.certtypes.<identifier>.* properties (the identifier can be chosen arbitrarily). Each certificate type defines an end-entity profile and a certificate profile, and what name should be displayed in the user interface. If the username should be generated from a field, then this can be configured using the usernamemapping sub-property. Finally, to enable self registration, the property web.selfreg.enabled must be set to true.

Note that the approval requests will be shown in the administration GUI as coming from a Command Line Tool. This is normal since all actions that aren't initiated by an administrator are shown as coming from the command line.