- EJBCA Introduction
- EJBCA Installation
-
EJBCA Operations
-
EJBCA CA Concept Guide
- Certificate Authority Overview
- Crypto Tokens Overview
- End Entities Overview
- Publishers Overview
- Validators Overview
- Certificate Profiles Overview
- Approval Profiles
- Services
- Peer Systems
- Internal Key Bindings Overview
- Roles and Access Rules
- Protocols
- Logging
- Character Limitations
- User Data Sources
- EJBCA RA Concept Guide
-
EJBCA Operations Guide
-
CA Operations Guide
- Approving Actions
- CA Web Overview
- Configure EJBCA for Public Access
- CRL Generation
- EJBCA Configuration Checker
- EJBCA Maintenance
- End Entities
- End Entity Profile Operations
- Exporting and Importing Profiles
- Importing Certificates
- Key Recovery
- Managing CAs
- Managing Certificate Profiles
- Managing Crypto Tokens
- Managing Internal Keybindings
- Modular Protocol Configuration
- OCSP Management
- Peer Systems Operations
- Roles and Access Rules Operations
- RA Operations Guide
- Command Line Interfaces
- EJBCA Batch Enrollment GUI
- ConfigDump Tool
-
CA Operations Guide
-
EJBCA CA Concept Guide
-
EJBCA Integration
-
Integrating with Third-Party Applications
- Access EJBCA using USB Tokens and Smart Cards
- Native Certificate Autoenrollment for Windows
- Microsoft Intune Device Certificate Enrollment
- Script based Autoenrollment for Windows clients with EJBCA
- Integrating EJBCA with GreyLog
- Versasec Card Management System Integration
- Ciphermail Email Gateway and EJBCA Integration
- Microsoft Smart Card Logon
- EJBCA and Cisco IOS
- OpenSSH and X509 Authentication
- Configure EJBCA with OpenSSO
- Setting up an Apache Web Server as a Proxy
- Setting up an Apache Web Server with mod_jk
- Setting up a HA Proxy in front of EJBCA
- EJBCA with GemSAFE Toolbox
- SensorNet PKI
- Issuing Certificates to Kubernetes Services using cert-manager
- Hardware Security Modules (HSM)
-
Integrating with Third-Party Applications
- Troubleshooting Guide
-
Tutorials and Guides
- Quick Install Guide
- Migrating from other CAs to EJBCA
- Modifying EJBCA
- Enabling Debug Logging
- Creating a custom RA application using EJBCA Web Services and Java
- Using EJBCA as a Certificate Management System (CMS)
- Batch Creating Certificates
- Making an ASN.1 Dump of a Certificate
- Using the Demo Servlet
-
EJBCA Release Information
-
EJBCA Release Notes
- EJBCA 7.3.1.1 Release Notes
- EJBCA 7.3.1 Release Notes
- EJBCA 7.3 Release Notes
- EJBCA 7.2.1.1 Release Notes
- EJBCA 7.2.1 Release Notes
- EJBCA 7.2 Release Notes
- EJBCA 7.1 Release Notes
- EJBCA 7.0.1 Release Notes
- EJBCA 7.0.0 Release Notes
- EJBCA 6.15.2.5 Release Notes
- EJBCA 6.15.2 Release Notes
- EJBCA 6.15.1 Release Notes
- EJBCA 6.15 Release Notes
- EJBCA 6.14.1 Release Notes
- EJBCA 6.14 Release Notes
- EJBCA 6.13 Release Notes
- EJBCA 6.12 Release Notes
- EJBCA 6.11 Release Notes
- EJBCA 6.10 Release Notes
- EJBCA 6.9 Release Notes
- EJBCA 6.8 Release Notes
- EJBCA 6.7 Release Notes
- EJBCA 6.6 Release Notes
- EJBCA 6.5 Release Notes
- EJBCA 6.4 Release Notes
- EJBCA 6.3 Release Notes
- EJBCA 6.2 Release Notes
- EJBCA 6.1 Release Notes
- EJBCA 6.0 Release Notes
- EJBCA Release Notes Summary
- EJBCA Change Log Summary
-
EJBCA Upgrade Notes
- EJBCA 7.3.1.1 Upgrade Notes
- EJBCA 7.3.1 Upgrade Notes
- EJBCA 7.3 Upgrade Notes
- EJBCA 7.2.1 Upgrade Notes
- EJBCA 7.2 Upgrade Notes
- EJBCA 7.1 Upgrade Notes
- EJBCA 7.0.1 Upgrade Notes
- EJBCA 7.0 Upgrade Notes
- EJBCA 6.15.2.5 Upgrade Notes
- EJBCA 6.15 Upgrade Notes
- EJBCA 6.14 Upgrade Notes
- EJBCA 6.13 Upgrade Notes
- EJBCA 6.12 Upgrade Notes
- EJBCA 6.11 Upgrade Notes
- EJBCA 6.10 Upgrade Notes
- EJBCA 6.9 Upgrade Notes
- EJBCA 6.8 Upgrade Notes
- EJBCA 6.7 Upgrade Notes
- EJBCA 6.6 Upgrade Notes
- EJBCA 6.5 Upgrade Notes
- EJBCA 6.4 Upgrade Notes
- EJBCA 6.3 Upgrade Notes
- EJBCA 6.2 Upgrade Notes
- EJBCA 6.1 Upgrade Notes
- EJBCA 6.0 Upgrade Notes
- EJBCA Upgrade Notes Summary
-
EJBCA Release Notes
Self Registration
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:
- The approval process verifies end entity account creation.
- 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.