EJBCA - Open Source PKI Certificate Authority
Search ejbca.org for:

EJBCA SECURITY

Security is CRITICAL for a CA. Protection of the CAs private key is essential, since compromise of the CAs private key will let anyone issue false certificates, which can be used to gain access to systems relying on the CA for authentication and other security services.

After realizing this, please read on and take a pragmatic approach to security suitable for your policy, application and environment.

Firewall ports

To have a functional EJBCA installation there are only two ports that need to be open to the outside:

  • 8080 - the public HTTP port of you application server, used for clients to access the public web for enrollment.
  • 8443 - the SSL protected HTTPS port used to access the admin GUI of EJBCA. This port requires client certificate for access.
Additional ports that you may need to open are SSH, outgoing SMTP, outgoing LDAP etc. Which additional ports that needs to be open depends on your specific setup and which services you use. You do not need outgoing SMTP if you don't use email notification for example.

Locally on the host a number of ports are used in order for your application server to function.

Securing JBoss

JBoss has description how to secure a default installation of JBoss. You should read this document before putting your application in production.

Check out: SecureJBoss

You should at least disable the public admin console by removing jmx-console.war, management/console-mgr.sar and jbossweb-tomcat55.sar/ROOT.war from deploy.

Alternatively protect it with a password set in jboss/server/default/deploy/management/console-mgr.sar/web-console.war/WEB-INF/classes/web-console-users.properties

You should also make sure all sensitive files can only be read by the JBoss user. These files are for example the server.xml file where the password for the SSL keystores are stored.

Setting up SSL

To set upp SSL communication for all HTTP traffic to the server follow the instructions for installing EJBCA, this will set up HTTPS for the admin-GUI automatically.

This will set up an SSL port open for the public at 8442 and an SSL port which require client certificate to access the administration GUI at 8443.

Java truststore

Acceptable CA certificates for clients are stored (by java) in $JAVA_HOME/jre/lib/security/cacerts. There are however many others present as shipped by Java, which means that anyone with a certificate issued by one of those CAs normally can access port 8443 on you JBoss server. They can not access the admin-GUI however, since EJBCA checks authorization. When EJBCA deploys, it generates a custom truststore that is used by JBoss. So the certificates available in $JAVA_HOME/jre/lib/security/cacerts are NOT trusted. If using another application server than JBoss, check the trust keystore contents of you application server so you don't trust too many issuers.

You can create a new Java trust store with the command:

ant javatruststore

The trust store will be stored as p12/truststore.jks

Manual steps to creating a java trust store:

keytool -import -alias AdminCA1 -trustcacerts -file root.der -keystore /home/jboss/java/cacerts

Where root.der is the root certificate from EJBCA that you saved, for instance with the command:

bin/ejbca.sh ca getrootcert AdminCA1 root.der -der

AdminCA1 is the name of your CA that you are using for server and administrator certificates in EJBCA.

Configuring for security

The easiest way to keep the installation secure is to block all default JBOSS ports (1099, 1476, 4444, 8082, 8083) from the outside and only allow traffic to Tomcat ports (8442 and 8443). This is because the public end-user actions can be performed through the public servlets, while administration tasks are performed directly on the beans.

See 'ejbcafirewall.sh' for an example how to configure an Iptables firewall in Linux for protecting EJBCA running on JBoss.

See JBoss documentation for a list of ports used in JBoss, for information about security in JBOSS/EJB and for how to set up SSL with JBOSS. See this JavaWorld article for more examples about setting up role-permissions.

File permission

The application server should be run as a special user. Files should be protected so the ONLY the user running the application server can access them.

By default JBoss is probably unpacked with read access to all, you should issue:

umask 077
chmod -R go-rwx *

In the JBOSS_HOME directory, to make the files readable only by the jboss user, and make this the default permission for files copied here.

If PKCS12 files are generated for users, the subdirectory ('p12') where they are stored and the generated files should be protected in the same way.

User authentication

Default user authentication for enrollment in EJBCA is done with a one-time password scheme. When a user has enrolled for a certificate his status is set to GENERATED and the password can not be used again to enroll for a new certificate. An administrator must re-set the users status and preferably set a new password.

If implementing other user authentication scenarios you should remember that certificate authentication is stronger than password based authentication (for example LDAP). If EJBCA users authenticate with some other (not one-time) password instead of usual one-time password, a strong authentication mechanism will be build on a weaker one.

Passwords defined when configuring EJBCA.

The configuration files (in $EJBCA_HOME/conf) contains some passwords. It is not considered to be a security risk to declare all these passwords in clear text. Anyone that could log on to the server with EJBCA could apart from reading these files also do anything he wants with the CLI of EJBCA. If an unauthorized person could use the CLI this is severe security risk. But reading the passwords is not much of a problem since the passwords in any case can not be used to anything outside the server.

It is very important to restrict the access to the server only to a very few trust-able persons.

If you anyway want to do something about these passwords the subsections of these section is describing what could be done:

Passwords used by EJBCA taken from property files

Some of the passwords are used directly by EJBCA code. All these passwords may be configured encrypted in the same way as PINs used for auto activation could be encrypted.

List of these passwords in ejbca.properites :
ca.tokenpassword
ca.keystorepass
ca.ocspkeystorepass
ca.xkmskeystorepass
ca.cmskeystorepass

List of these passwords in protectedlog.properties :
protectionTokenKeyStorePassword

Passwords used by the application server

Some of the passwords is not used by EJBCA but by the application server. If this passwords should be encrypted it must be in a way so that they could be decrypted by the application server. You have to consult the documentation of the application server to find out how to encrypt them (example: datasource password in jboss).

This are these passwords:
mail.password in mail.properties
database.password in database.properties

Passwords prompted for by 'ant install'

If you don't define superadmin.password in web.properties then 'ant install' will prompt for it. Since this password does not has to be known by EJBCA after the super admin token has been created it will not exist in any file after the installation.

The passwords java.trustpassword and httpsserver.password also in web.properties are used to generate keystore files at 'ant install'. These passwords must later on be specified in the application server configuration. If these passwords are not specified and the property 'web.promptForPassword' is set to 'true' then these passwords are also prompted for.

But if you let 'ant install' prompt for these passwords you must set them (maybe encrypted if possible) in the application server configuration. The file for the application server is copied to the application server at 'ant deploy' (in jboss 4.2.3 the file is called $JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml) You must then manually substitute the strings 'changeThisToThePassword' in the configuration file with clear text or possible encrypted (application server specific) passwords.

Datasource passwords

If you do not like to have your DataSource password available in clear text in EjbcaDS.xml, there is an article in the JBoss Wiki about encrypting them:
http://community.jboss.org/wiki/encryptingdatasourcepasswords

Database privileges

During the installation process of EJBCA, JBoss creates all the required database tables. To do this the EJBCA-database user has to have CREATE TABLE privileges. During upgrades EJCBA needs CREATE and ALTER TABLE privileges. (SELECT, UPDATE, INSERT and DELETE privileges are also required.)

After the installation during normal operations only regular SELECT, UPDATE, INSERT and DELETE commands are needed. The table LogEntryData and ProtectedLogData will only be used with SELECT and INSERT.

Instead of changing the privileges of the EJBCA-user, it's recommended to have two different users "ejbca" and "ejbca-admin". For regular operations "ejbca" is used, but for the installation and upgrades, EJBCA is re-deployed with "ejbca-admin" configured in conf/database.properties.

There is a script, doc/howto/mysql-privileges.sh that creates an SQL script that can be run to limit privileges on a MySQL database. The script will set restricted privileges for every table in the EJBCA database. See the script for in-line documentation.

Other precautions

Switching to production mode

Switching to production mode by setting ejbca.productionmode in conf/ejbca.properties will prevent ant from starting JUnit tests and deploying the CA build on an OCSP responder and vice versa.

System accounting in Linux

See your distribution for details about their package, below are general links.
http://www.nic.com/~dave/SecurityAdminGuide/SecurityAdminGuide-5.html

Denial of Service

Due too large data packages

There is no way to limit the datapackages reaching JBoss through a HTTP request from within JBoss. This is due to the way the TCP protocol works. The best way to avoid this kind of DOS attacks is to use a firewall or proxy that can limit the size of request and configure it properly.