The following provides information on creating a Card Verifiable Certificate (CVC) CA.
When creating a CVC CA there are three CA Reference fields in the standard. In EJBCA, these are mapped to a DN structure to have common handling in EJBCA. The mapping is:
Mnemonic = CN (ISO 8859-1 1-9 letter string)
Sequence = certificate serial number (ISO 8859-1 5 letter alphanumeric string)
Country = C (ISO 3166-1 2 letter country code)
The sequence should be a pure numeric sequences of 5 characters (00001, 00002, etc), or country code + numeric (SE001, SE002, etc), or country code + alphanumeric (hex) (SEA01, SEB01, SEB0F, etc).
Creating the CA
To create the CA in the EJBCA CA UI, do the following:
In the CA UI, click Certification Authorities under CA Functions to open the Manage Certificate Authorities page.
In the Add CA field, enter the name of the CA and click Create.
On the Create CA page, select CVC as CA Type and choose the Crypto Token and Signing Algorithm.
To set the Subject DN, follow the Examples above to set it according to the ISO standard.
As a BAC/EAC CA is a root CA, set Signed by to Self Signed and Certificate Profile to ROOTCA or a profile that extends it. Also, make sure to set the correct validity.
Note that EJBCA only validates that country codes consist of two characters with value A-Z to facilitate testing with mock countries.
To create a Document Verifier (DV), select Signed by=Name of CVCCA and Certificate Profile=SUBCA. For more information, see Document Verifiers (DV).
You can import a CVCA certificate from another country as an External CA using Edit Certificate Authorities > Import CA certificate. When a CA has been imported, this CA certificate can authenticate CVC requests from foreign DVs.
Using the WebService API
The EJBCA Web Service (WS) API has several methods to manage DVs and ISs.
The method cvcRequest is used for enrolling and renewing DVs (on a CVCA) and ISs (on a DV).
The following process applies when a CVC request is received through the WS API call:
Look up if there exists a user with the specified username.
If the user exists:
If the user's status is revoked, the request is denied (AuthorizationDeniedException).
See if the user has old certificates.
If there are old certificates and the request is an authenticated request (with outer signature):
If the request uses the same public key as the old certificate the request is denied (AuthorizationDeniedException).
If the old certificate can verify the request but the certificate is not valid we throw a CertificateExpiredException.
If the request can be verified using one of the old valid certificates the request is automatically granted, and the user status is set to new and the password set to the given password.
If the request cannot be verified at all, the request is denied (AuthorizationDeniedException).
If there are no old certificates we try to process the request as a non-authenticated request.
If the user does not exist we try to process the request as a non-authenticated request.
Processing the request as a non-authenticated request means that we try to authenticate using the password given and that only works if the user status is new.
The Web Service APIs caRenewCertRequest and caCertResponse are useful when used from a SPoC in order to renew DVs for example. For more information, see Managing CVC CAs - Creating a DV and Managing the DV Lifecycle using WS.