The following provides information for troubleshooting enrollment issues. To view general troubleshooting tips and search for troubleshooting topics, see EJBCA Troubleshooting.
Error issuing certificates regarding users having the same Subject DN
If you receive the error that a user cannot have the same Subject DN as another user, when you are issuing certificates, this is caused by the Enforce unique DN check.
By default, different end entities cannot have the same subject DN issued from one CA. The check enforces Subject DN uniqueness and is performed when new certificates are issued.
This may be inconvenient in some cases as one user can appear as multiple end entities.
To disable the enforcement of subject DN uniqueness, do the following:
- In the CA GUI, click Certification Authorities under CA Functions.
- Click Edit CA and in the CA configuration, and clear the option Enforce unique DN.
For more information on the Enforce unique DN option, see CA Fields.
Exception with an SQL error when adding a new user
When adding a new user, an exception with an SQL error like the following is thrown: "Value too large for column USERDATA.SUBJECTALTNAME" or "Value too large for column USERDATA.SUBJECTDN".
This can happen if you have specified one or more fields of the Subject Alternative Name with a total length exceeding 2000 characters (400 characters for subject DN).
Extend the size of the column SUBJECTALTNAME and SUBJECTDN of the table USERDATA and SUBJECTDN of CERTIFICATEDATA.
The following displays an example for extending the subjectDN and altName columns in MySQL (version > 5.0.3):
mysql> alter table CertificateData modify subjectDN varchar(2048); mysql> alter table UserData modify subjectDN varchar(2048); mysql> alter table UserData modify subjectAltName varchar(2048);
The new column sizes can cause issues when applying indexes in some database versions, giving errors like for example: "Specified key was too long; max key length is 767 bytes"
To circumvent this issue, create the index over a subset of the column by running the following:
mysql> create index certificatedata_idx4 ON CertificateData (subjectDN(250));
For more information on Subject Alternative Names and Subject DN Fields, see End Entity Profiles Fields.
Error when issuing new certificate
When issuing a new certificate, I get the exception/error: Got request with status GENERATED (40), NEW, FAILED or INPROCESS required: foo; nested exception is: javax.ejb.EJBException:null
When using the AuthenticationSession (default) all users have a STATUS. The status lifecycle begins with NEW and ends with REVOKED. Only when the status is NEW, FAILED or INPROCESS is it possible to issue a certificate to a user. After a certificate has been issued, the status is set to GENERATED. This works like a one-time-password scheme.
To issue a new certificate to the user, his/her status must be reset to NEW, FAILED, or INPROCESS.
To reset the status, run the following:
bin/ejbca.sh ra setendentitystatus username status Status '10' is NEW
To view a list of all status codes, run:
bin/ejbca.sh ra setendentitystatus
I have enrolled manually for a server - why are my PKCS10 DN fields Ignored?
PKCS#10 is a standard format for sending the public key (self signed to provide proof-of-possession) to a CA. EJBCA does not trust the DN parts the user enters when he creates the PKCS10 request. The only way to match the certificate with what you enter in the pkcs10 is to enter the same thing in the end entity in EJBCA. If you really trust your RAs that send certificate requests, there is an option to allow DN override in the Certificate Profile, see Certificate Profile Fields.
Does EJBCA still support Browser Enrollment?
No. The old functionality allowing you to go to a web page and have the browser generate a key pair, sending a certificate signing request (CSR) to the CA, does no longer exist in web browsers. Firefox removed support for the Keygen tag in version 69 and the Internet Explorer version that supported the certificate enrollment (CertEnroll) control has not been supported by Microsoft for a long time.