Prerequisites

Note: EJBCA makes use of strong crypto and keystore passwords longer than 7 characters. For this to work you must install the 'Unlimited Strength Jurisdiction Policy Files' for JDK. The policy files can be found at the same place as the JDK download at java.sun.com. Further information on this can be found in the Sun documentation on the JCE.

Needed to build and run are:

• JDK 1.4.x or 1.5.x
• JBOSS >3.2.6 or 4.0.x (latest tested verison is JBoss 4.0.2)
• Ant 1.6.x to build (http://jakarta.apache.org/ant/)

Set the environment variable JBOSS_HOME to the directory where JBoss's root is (/jboss-version). This is done so the deploy script will know where files are to be copied, they are copied to the directory $JBOSS_HOME/server/default/deploy.

Windows/Unix: When we describe command line commands below we use unix notation, e.g. 'ejbca.sh' for the executable command files. The same command files are available for windows as cmd-files, e.g. 'ejbca.cmd.'

Configure

If you are only testing EJBCA at this stage and is not setting up a production environment, you can skip this step.

Now when everything is prepared, there are a few things to configure before starting JBOSS and running everything in a production environment.

In a production environment you should use something like the following structure:

1. Go through the install process creating an AdminCA. Use a simple DN. This CA is only used to issue the initial superadmin certificate. Not published in LDAP.
2. Once installed, create all your REAL CAs using the admin-GUI. Now you can use the certificate profiles etc that you like. These certificates can be published in LDAP. See HOWTO-multiplecas.txt for a detailed configuration guide.

In a production environment you should use something else than the default Hypersonic database that comes with JBoss for the reasons:

1. Hypersonic database is in-memory, which means that over time it will consume more memory. If a large numer of certificates is issued, it will become an issue after a while.
2. Hypersonic does not support full SQL, in particular ALTER statements. When a new version of EJBCA is released we can not create scripts that updates the database if some tables changed. This will make upgrades much much harder.

Install

Note that the installation must be done with a user with privileges to write to JBOSS_HOME and subdirs.

1) Set the environment variable JBOSS_HOME to where your JBoss is installed, example /opt/jboss-4.0.2.

2) Copy ejbca.properties.sample to ejbca.properties and customize if needed. The default values works fine for a test installaton.

• Customize the CA properties if you need to do so. For production use you need to do this, don't forget to edit passwords to be secure and secret. Keep ejbca.properties as secret as possible. DO NOT forget the passwords, if you need to re-install the software sometime.
• Customize the database if needed but easiest thing is to keep the default as it is, it will use the JBoss embedded HSQLDB and everything will be easier for you. For production use you should use a real database instead of the embedded one.

3) Open a console (terminal) and start JBoss. You can start JBoss with 'ant j2ee:run' from EJBCA_HOME or the normal command 'run.sh/cmd' from JBOSS_HOME/bin.

4) Open a console and type 'ant bootstrap' it will compile, jar, war, ear everything and deploy it to JBoss. You should see JBoss picking up all the changes and deploying the ear without errors.

5) Type 'ant install' it will generate all certificates, keys, etc needed to run with an initial CA. You will find admin keys in ${ejbca.home}/p12. (do not delete those files!)

• tomcat.jks is for the servlet container (don't bother with it)
• superadmin.p12 should be imported in your browser, that's your administration certificate.

You will need administrative privileges (e.g. root) for the CA-certificate to be installed in Javas trust-keystore ($JAVA_HOME/jre/lib/security/cacerts, default pwd 'changeit'). If you don't have root permission now, you can do it manually later after step 9. It's important so don't forget!

6) Stop JBoss (ctrl+c or whatever)

7) type 'ant deploy', this will deploy everything again and configure the servlet container with the keystore file (this is why we needed to stop the container). If you alternative want to use jbossspecific service for automatic creation of the CRL:s you should use 'ant deploywithjbossservices' instead.

8) Import the certificate from EJBCA_HOME/p12/superadmin.p12 in your web browser. This is the super administrators certificate used to access the admin GUI. Other administrators with specific privileges can be created later on.

9) Start JBoss again and go to https://localhost:8443/ejbca/ to access the admin-GUI, or http://localhost:8080/ejbca for the public pages.

If you did not have root permission and get an error during installation step 5, you can install the root certificate afterwards with the following commands, WITH the right permissions:

bin/ejbca.sh ca getrootcert AdminCA1 ca.crt -der
keytool -import -trustcacerts -alias AdminCA1 -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file ca.crt

where AdminCA1 is the CA name as configured in ejbca.properties (default is AdminCA1). You must stop and start JBoss after doing this.

Running optional tests

If you want to run a thorough test of your new CA, run the automated tests with 'ant test:run'. To run the tests you must copy the file lib/ext/junti-1.5.8 to ANT_HOME/lib.

NOTE: After running tests with 'ant test:run', you might consider deleting the database since some leftovers are left in the database. The tests will create and revoke some test certificates, so afterwards your CRLs will be populated with a few entries. 'ant test:run' should not be run on a production system, only to test the installation.

NOTE! Don't forget to configure JBoss for security! See security. Security is CRITICAL for a CA.

Administrating EJBCA

You can administrate EJBCA using a web browser and the admin-GUI, this is the easiest way.

You can also use the command line interface (cli) which is called by 'bin/ejbca.sh'. If you call ejbca.sh you get a list of available commands, and you can get help for all commands by calling them without arguments, i.e:

bin/ejbca.sh ca
bin/ejbca.sh ra adduser
etc etc

Creating more CAs

After installation, that creates a default admin CA you can create more CAs using the admin GUI.

Your CAs can be either root CAs, subordinate CAs to another CA in EJBCA or subordinate CAs to an external CA. The initial admin CA is a RootCA.

You can also use the command line interface (cli) 'bin/ejbca.sh ca init' to create new CAs, although a better idea is to do it from the Admin GUI. Ex: 'bin/ejbca.sh ca init TestRoot "C=SE,O=PrimeKey,CN=EJBCA" 2048 365 2.5.29.32.0' will create a root CA with the DN 'C=SE,O=PrimeKey,CN=EJBCA'. The keylength is 2048 bit (RSA) and the validity of the root certificate is 365 days. Quote the DN so it is treated as one argument.

PKIX requires that a CRL always is available even if it is empty. When creating a new CA the CA certificate is stored and published (if any Publishers are configured), and the initial CRL is created and stored/published.

Subordinate CAs are created using the admin GUI, you can not use the cli for that.

Converting an OpenSSL CA

You can convert a PEM-style Root CA key to a PKCS12 file that can be imported in EJBCA.

openssl pkcs12 -export -out server1.p12 -inkey cakey.pem -in ca.pem -name privateKey

You can import the CA with the cli command 'bin/ejbca.sh ca importca'.

Creating Users

Users are added in the admin-GUI, 'Add End Entity' or with the cli 'bin/ejbca.sh ra adduser'. The users DN is normally entered in the cli as "C=SE,O=MyOrg,OU=MyOrgUnit,CN=MyName". If a ',' is needed in the DN the comma must be escaped using '\,'.

Create User certificates

To enroll for certificates using browsers, open http://127.0.0.1:8080/ejbca/publicweb/apply/index.html (assuming the servlet container listens to port 8080) and use the links for your browser.

To enroll for certificates using manual methods (for server certificates for example) open http://127.0.0.1:8080/ejbca/publicweb/apply/apply_man.jsp and fill in the form.

Note that application for certificates only work when the status of a user is NEW, FAILED or INPROCESS (one time password thing). The status is set to GENERATED after a certificate has been issued. To issue a new certificate, the status must be reset to NEW, which can be done through the admin-GUI or the cli.

During batch generation of certificates, users with status NEW or FAILED are generated. This is due to the possibility that a batch generation for some reason failed. If it fails status is set to FAILED and you can try again after fixing the error.

Create server certificates

The best way to create server certificates is to generate a PKCS12, JKS or PEM file for the server, depending on what server it is. To do this:

1. Create a user with the admin_GUI or 'bin/ejbca.sh ra'. The DN for a server should have the domain name in CommonName (CN). Example DN for webserver: "C=SE,O=AnaTom,CN= www.anatom.se", or for mailserver "C=SE,O=AnaTom,OU=Engineering,CN=mail.anatom.se". Set the token type to match the kind of token that should be generated for your server.
2. To be able to batch-generate certificates, the batch generation program must have access to the users (servers) password in order to request a certificate on behalf of the user. Normally the password is stored in hashed form, so the password must be stored in clear text form by running 'bin/ejbca.sh ra setclearpwd username password'
3. Generate private keys and certificates by running 'bin/ejbca.sh batch'

Many servers (ex Apache, Tomcat) wants keys and certificates in PEM-format or SUN JKS. To generate PEM-files use token type PEM. The PEM-files will be stored in a separate subdirectory, 'pem'. The generated PEM-files can be used with Apache etc, and are NOT protected by any password. To generate JKS-files use token type JKS. The JKS-files will be stored in the subdirectory, 'p12' instead of PKCS12-files. The generated JKS- files can be used with Tomcat etc, and are protected (both private key password and keystore password) by the users password.

It is also possible to use openssl to transform a PKCS12 file to PEM- format.

openssl pkcs12 -in pkcs12-file -nodes

copy and paste the private key to key file, the first certificate to server cert file and last certificate to CA cert file (If your CA is a subordinate CA to another Root CA, the CA cert file may need to contain the whole cert chain). Exactly how your server wants the files is server dependent.

JBossservice

The first way to have CRLs generated automatically is to build and deploy the JBOSS CRL Service. This is done with the command 'ant deploywithjbossservices' (inside ejbca.ear) alternatively 'ant deployjbossservices' (outside ejbca.ear) If you only want to build the jar (without deploying) you can do so with the command 'ant jbossservices'. After installation with deployjbossservices, JBoss must be restarted.

This service will by default check if CRL generation is needed every minute. If this default behaviour can be changed by editing the attribute 'Polltime' in src/appserver/jboss/crlcreate-service.xml. A new CRL is created if the old one expires within the polltime + 10 minutes, so a CRL is always created at least 10 minutes before the old one expires. In this way we will in the worst case get the overlap time (10 min) as the time when applications can fetch the new CRL before the old one expires. The attribute can have the following values:

DAILY   =  Every midnight
HOURLY  =  At XX:00 every hour.
30MIN   =  At XX:30 and XX:00 every hour
15MIN   =  At XX:15, XX:30, XX:45,XX:00, every hour 
1MIN    =  Every minute

Cron job

The second way is to have a cron job or equivalent call 'bin/ejbca.sh ca createcrl'. The 'createcrl' command will then check all active CAs if there is a need to update their CRLs, otherwise nothing is done.

If you want to force CRL generation for a CA, use 'bin/ejbca.sh ca createcrl caname'

Example crontab entry:

PATH=$PATH:/usr/java/jdk1.4.2_01/bin
@daily cd /home/ejbca;/home/ejbca/ca.sh createcrl;

where '/usr/java/jdk1.4.2_01/bin' is the path to where 'java' can be found. '/home/ejbca' is where ejbca is installed and 'ca.sh' located.

Sample crontab to be installed with 'crontab -e':

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
CLASSPATH=$CLASSPATH:/root/ejbca:/root/ejbca/admin.jar
JBOSS_HOME=/usr/local/jboss
# m h dom mon dow command
00 0    * * *   cd /root/ejbca;./ca.sh createcrl

Level of SCEP support

EJBCA does succesfully receive SCEP 'PKCSReq' requests and send back the certifificate/CRL immediately in a proper SCEP reply message. EJBCA does not support the 'polling' model, EJBCA uses the direct method, where a request is granted or denied immediately. EJBCA will not send back proper SCEP error messages in all cases of failure. The error messages are not completely implemented.

The CN part of the DN in the PKCS#10 request, which is part of the Scep request, will be used as the 'username' when authenticating the request in EJBCA. Create the Scep request with a CN mathing the username registered in EJBCA. The challengePassword in the PKCS#10 request, which is part of the Scep request, will be used as the 'password' when authenticating the request in EJBCA. Create the Scep request with a challengePassword mathing the password registered in EJBCA.

The most common errors should be wrong username/password or wrong status (not NEW) on the user in EJBCA.

Tested devices

./scep -k test.key -r test.pemreq -c ejbca-ca.pem -q foo123 -u http://localhost:8080/ejbca/publicweb/apply/scep
rem ./scep -d -k test.key -r test.pemreq -2 -e test.req -c ejbca-ca.pem -q foo123 -u http://localhost:8080/ejbca/publicweb/apply/scep

openssl genrsa -out test.key

openssl req -key test.key -new -days 30 -out test.req -outform DER -config ../openssl/openscep.cnf

openssl req -key test.key -new -days 30 -out test.pemreq -outform PEM -config ../openssl/openscep.cnf

ca identity pixca ca-ip:/ejbca/publicweb/apply/scep/pkiclient.exe
ca configure pixca ca 1 0 crloptional
ca authenticate pixca
--wait--
show ca certificate
ca save all
wr mem
ca crl request pixca
--wait--
show ca crl
ca enroll pixca foo123
--wait--

CRYPTO_CA: error = 293: failed to verify

CRYPTO_CA: error = 266: failed to verify 

nCipher NFast

Follow these steps to create a CA that is using a NFast card:

You may use the java keytool. It is advisable to define an alias for using the tool for keystores on the NFast:

alias keyToolHSM='java -cp /opt/nfast/java/classes/rsaprivenc.jar:/opt/nfast/java/classes/nfjava.jar
:/opt/nfast/java/classes/kmjava.jar:/opt/nfast/java/classes/kmcsp.jar
:/opt/nfast/java/classes/jutils.jar sun.security.tools.KeyTool -provider com.ncipher.provider.km.nCipherKM 
-storetype nCipher.sworld'

Then the keyToolHSM alias could be used to manage keys on the NFast card in exactly the same way as soft keys are managed by keytool. All keys for one CA should be in the same keystore. Different CAs may share the same keystore but may also have different keystores.

The file are copied from the dist directory. The destination is the deploy directory of the application server (server/default/deploy in jboss). The files to be copied are:

jutil.jar kmcsp.jar kmjava.jar nfjava.jar rsaprivenc.jar

You could also make links if you prefer that.

Restart the application server.

Choose NFastCAToken as "CA Token Type".

Define the keystore on the nFast card that should be used. The keystore is defined by the hexadecimal hash string from the keystore file (open the .jks with a text editor ) generated in step 1. Define which keys in the keystore that should be used and the purpose of these keys.

Use one row for each definition. Begin the row with a key word. It is one row for the keystore and one for each key definition. Key word and value is separated by one or more spaces. A row with the keyword keyStore must always be present. The keywords for keys that can be used are:

• certSignKey - the key to be used when signing certificates
• crlSignKey - the key to be used when signing CLSs
• keyEncryptKey - the key to be used for key encryption and decryption.
• defaultKey - the key to be used when no other key is defined for a purpose. If this is the only definition then this key will be used for all purposes.

Example:

keyStore 578fc1f0b19d5bc6f61e3a3f1e28318715385a20
certSignKey rootCertSign
defaultKey rootCRLSign

LDAP Naming

A good book to understand LDAP naming is "Understanding and Deploying LDAP Directory Services". The recommended method of choosing a naming suffix is the one described in RFC2247 that maps a DNS domain to a DN. If my DNS domain is bigcorp.com it will map to the DN "dc=bigcorp,dc=com". The top node in my LDAP directory will then be "dc=bigcorp,dc=com".

The dc component support is mandated by all of the X.509 RFCs now. For example, if I have this directory:

dc=bigcorp,dc=com
    |
    +-dc=fi
    |
    |
    +-dc=se
        |
        +-cn=Mike Jackson

The most understandable method is taking the subject name in forward order, like: cn=Mike Jackson,dc=se,dc=bigcorp,dc=com

If the DN is ordered like this it should be published to the correct object in the tree.

If the DN is ordered reverse, like: dc=bigcorp,dc=com,dc=se,cn=Mike Jackson EJBCA will reorder it incorrectly to forward order, so the publishing will be wrong.

Therefore... Use forward order like this: 'cn=Mike Jackson,dc=se,dc=bigcorp,dc=com' if using the dc model or
'cn=Mike Jackson,o=bigcorp,c=se' if using the o,c model.

An example image of an LDAP structure can be seen below in HOWTO-LDAP-tree.png.

Making unique LDAP DNs is the next challenge. If you are in a small organization having the CN will probably work fine, but in a larger organization there are probably several people with the same name. Somehow the names must be made unique, and one way is to introduce numbers, initials etc in the CN. Another way that we recommend is to use uid in the LDAP DN instead. LDAP DNs will then looks like "uid=tomas,dc=bigcorp,dc=com". Uid is the users username, normally used for login etc, and you probably already have some proceedure to create unique usernames already.

LDAP Basics

LDAP has an unusual structure, if you are not used to X.500 style naming. Things are either branches, or leaf nodes. You can't just drop an object anywhere you like; You need to create the framework to support it. Sort of like if you wanted to put entries in /etc/hosts, if the directory /etc did not exist.

First you mkdir /etc, Then you create the file. Then you start putting things in the file. The difference with LDAP and x.500 is that instead of paths separate by slashes, you have paths separated by commas and '=' signs.

For example, if you want to make an object "cn=ldaphost,ou=hosts,dc=yourdom,dc=com", you first have to make sure "dc=yourdom,dc=com" exists.
Then make sure
"ou=hosts,dc=yourdom,dc=com" exists.
THEN you can try
"cn=ldaphost,ou=hosts,dc=yourdom,dc=com"

EJBCA does not create branches in LDAP. You have to put them there with other means, before you start publishing.

Configure LDAP publishers

A Publisher is a session bean that implements the IPublishSession interface and is used to store certificates and CRLs for entities. EJBCA have support for endless number of publishers simply by defining publishers in the admin-GUI. The user of EJBCA can implement own publishers, but EJBCA already comes with a publisher for LDAP.

EJBCA uses a notion of base DN to publish to different LDAP structures. The DN used in the certificate can be different from the LDAP structure.

Using LDAP

In Mozilla you can for example enter a URL like:
ldap://ip-address-of-ldap-server:389/cn=Tomas Gustavsson,dc=se,dc=bigcorp,dc=com
and it will fetch an adress book entry with the information about the user, including the certificate.

The LDAP url format is described in RFC2255.

Examples of using LDAP with Netscape/Mozilla can be found in the howto-section of this web page.

To use LDAP top fetch user certificates and use them for encrypting email there seems to be a requirement to use SSL connection to the LDAP server (Account Options->Compositions & Addressing->Edit directories->Edit->Use Secure Connection), see also below how to configure OpenLDAP for SSL.

Note: When fetching certificates from LDAP with Mozilla for example with URL:
ldap://ldap-server-host/dc=bigcorp,dc=com??sub?(cn=MyName)?(objectclass=*)
To get a checkbox at the fetched certificate, the CA certificate must be installed in the Windows truststore, not only in Mozillas.

To use SSL against an LDAP server with MS Outlook you must make sure the CN in the LDAP servers certificate is the same as the hostname. An example of adding a user for the LDAP server with the CLI interface is:

bin/ejbca.sh ra adduser ldap password "C=SE,O=Foo,CN=ldap.foo.se" null MyCA null 1 PEM

where ldap.foo.se is the hostname of the LDAP server that Outlook should use.

The CA certificate must also be imported into Windows properly.

Configure OpenLDAP

The objectclass 'inetOrgPerson' is used by default to store certificates.

Example:

dn: cn=Mike Jackson,ou=people,dc=company,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Mike Jackson
sn: Jackson
userCertificate;binary::

CAs are published in the form:

dn: cn=ejbca,dc=jackson,dc=net
objectClass: top
objectClass: applicationProcess
objectClass: certificationAuthority
cn: ejbca
cACertificate;binary:
certificateRevocationList;binary:
authorityRevocationList;binary:

To configure OpenLDAP (version 2.2.5) to include the 'inetOrgPerson' you must add the following lines to slapd.conf:

include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema

Don't forget to add the top object by creating an LDIF file (org.ldif):

dn: o=AnaTom,c=SE
objectclass: dcObject
objectclass: organization
o: AnaTom
dc: AnaTom

dn: cn=Admin,o=AnaTom,c=SE
objectclass: organizationalRole
cn: Admin

And using the command:

ldapadd -x -D "cn=Admin,o=AnaTom,c=SE" -W -f org.ldif

Check what you have in the LDAP by:

/usr/local/bin/ldapsearch -x -b 'o=AnaTom,c=SE' '(objectclass=*)'

Extra device schema

To store certificates for devices (e.g. routers, toasters etc) in LDAP there is no really suitable standard object class. inetOrgPerson requires surnames etc, and the device objectclass does not include a certifictae attribute.

Mike Jackson has kindly contributed additional objects that extend the standard device class with a certificate attribute. The ejbcaDevice uses object ids from PrimeKey Solutions AB.

Adding a new language to the admin GUI

Java uses unicode internally, so the things that needs to be taken care of are:

1. Make sure your system locale is set correctly, so Java will recognize input of your nations language. If Java does not automatically recognize your locale you might need to specify it as options to java during startup (i.e. in JBoss and cmd line commands such as ca.sh and ra.sh). java -Duser.language=2-char-language-code -Duser.region=2-char-country-code example for Swedish: java -Duser.language=sv -Duser.region=SE
2. Your database must also recognize the locale so it does not strip down to plain ascii. This is database and JDBC-driver dependent.

The admin GUI is meant to support multiple languages through language files in src/adminweb/languages. In order to add a language you should do the following:

1. Rename the languagefile you have created to language.languagecode.properties. In case of chinese it should be 'ch', and place it in the src/adminweb/languages directory.
2. Edit ejbca.properties (create with ejbca.properties.sample as template if you don't have one). Change 'web.availablelanguages' and add your language code to the value. i.e: <env-entry-value>EN,FR,IT</env-entry-value>
3. You may have to change the default page encoding in 'web.contentencoding' to for example UTF-8 instead of the default ISO-8859-1.
4. Clean and re-deploy ejbca with 'ant clean' followed by 'ant deploy'. Restart JBoss and your browser after this.

Now it should be possible to select EN, FR and IT in the system configuration as default language and in the administrator preferences page. The language will be changed next time the administrator logs in.

Administrating CA

The CA has a command line interface 'bin/ejbca.sh ca. Options are:

• info - prints information about a CA.
• init - creates a new Root CA.
• listcas - lists all CAs in the system. Stores CA certificates and publishes first CRL. Quote the DN (") so it is treated as one argument.
• getrootcert - exports the CA certificates to file.
• createcrl - issues a CRL.
• getcrl - retrieves the latest CRL.
• listexpired - List certificates that will expire within a given number of days.
• exportprofiles - exports entity and certificate profiles to xml-files.
• importprofiles - imports entity and certificate profiles from xml-files. When you export a profile that should be imported in another CA, make sure the 'Available CAs' is set to 'Any CA' for the profiles you export. Otherwise you can get into trouble with authorization if you don't have the same CAs with the same caids (DNs) where you import the profiles.
• importca - creates a new CA by importing keys from en existing PKCS12 file. A PKCS12 file can be generates from PEM files with openssl.
• importcert - creates a user and imports a certificate for him/her.
• republish - republishes certificates for a CA and all users. Can be used to add a publisher to a CA after some time, and then publish all certs.

Administrating RA

The RA has a command line interface 'bin/ejbca.sh ra'. Options are:

• adduser - adds a user to the database, after addition a user may apply for a certificate. If email address is set to 'null', no email is put in certificates. Quote the DN (") so it is treated as one argument. Altnames is a string simlar to the DN string but using alternative names from RFC3280, i.e. "rfc822Name=email, dNSName=hostname, uri=http://whatever, iPAddress=10.56.32.245" The full list is: otherName, rfc822Name, dNSName, x400Address, directoryName, ediPartyName, uniformResourceIdentifier, iPAddress, registeredID Only rfc822Name, dNSName, iPAddress and uniformResourceIdentifier (uri) is supported at the moment. Also the MS UPN and GUID are supported.
• deluser - removes a user from the database, any issued certificates remain active and present in the database.
• setpwd - set a new password for a user. The password is stored as a hash in the database.
• setclearpwd - set a clear text password for a user, needed to generate certificates batch-wise.
• setuserstatus - sets status of a user, users can only apply for certificates when their status is NEW. finduser - find a user in the database and lists details.
• listnewusers - lists all users with status NEW.
• listusers - lists users with specified status (give command to see list of status codes).
• revokeuser - revokes a user and all certificates issued to the user.
• keyrecover - recovers keys related to a specific certificate.
• keyrecovernewest - recovers the latest keys for a user.

Other Configuration

If you want to change the baseurl of the admin-web after installation use the command:

bin/ejbca.sh setup setbaseurl computername applicationpath
Ex: bin/ejbca.sh setup setbaseurl localhost ejbca

To change ports (default public http=8080, public https=8442, private https=8443) you must edit ejbca.properties. Change the properties httpserver.pubhttp, httpserver.pubhttps and httpserver.privhttps. After changing, run 'ant deploy' and re-start the application server.

Configuring Publishers (LDAP)

LDAP setup is explained in HOWTO-LDAP.txt

Batch creation of certificates

Certificates can be created batch-wise with EJBCA. The class se.anatom.ejbca.batch.BatchMakeP12 creates keystore files for all users designated as NEW or FAILED in the local RA database. To be able to batch generate certificates, the users must be registered with clear text passwords. To set a clear text password for a user use

bin/ejbca.sh.sh ra setclearpwd username password

To generate keystore files for all users with status NEW or FAILED, run

bin/ejbca.sh batch 

This will generate files for users if their clear text passwords are NOT null.

Without arguments 'batch' generates keystore files for all NEW or FAILED users. To generate a keystore file for a specific user, enter command

bin/ejbca.sh batch username

Generated keystore files are stored in a subdirectory (to the current directory) called 'p12'. If the directory does not exist, it will be created. Make sure this directory is WELL protected, since the information contained in keystore files are secret (private keys). The format of keystores generated, PKCS12, JKS or PEM, is defined when adding the user in the database (using 'bin/ejbca.sh ra adduser' or the admin-GUI).

Fetching certificates and CRLs

Certificates and CRLs can be fetched through the web-interface as defined in 'webdist/index.html'. They can also be fetched directly from the 'CertificateStoreSession' session bean or using the command 'bin/ejbca.sh ca getcrl'

Other deployment scenarios

EJBCA can be run with servlets and EJBs or only with EJBs. The servlets are only a publicly available front-end to the beans. If the CA is deployed integrated in another J2EE application, this front-end may not be needed.

Certificate- and EndEntity Profiles

CertificateProfiles define different types of certificates, with regards to DN-contents, extensions etc. We also have EndEntityProfiles, where users are grouped, and you can determine which parts of their DN that is already pre-set, and which can be altered etc.

An EndEntityProfile can be connected to specific CertificateProfiles so users belonging to a specific EndEntityProfile can only get certificates from the specified CertificateProfile.