EJBCA SECURITY

Security is CRITICAL for a CA. Protection of the CA's private key is essential, since compromise of the CA's private key will let anyone issue false certificates, which can then 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 need to be opened 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 a 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 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 Admin GUI at 8443.

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 user's status and preferably set a new password.

If you are exposing your public web pages to a wider audience there are a few functions you can use in order to counter perceived threats such as brute-force attacks.

• Enable password expiry using the User Password Expire Service. If a user forgets to use his/her one-time password it will be automatically disabled.
• Use password expiry with the Maximum number of failed login attempts setting when registering users.
• Increase the number of BCrypt rounds, making password hashing slower. See the setting of ejbca.passwordlogrounds in conf/ejbca.properties.sample.

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 built on a weaker one.

Passwords defined when configuring EJBCA.

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

It is very important to restrict the access to the server to only a very few trusted individuals.

If you anyway want to do something about these passwords the subsections of this section describes what should be done:

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 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.

SSL connections in MySQL

http://dev.mysql.com/doc/refman/5.0/en/secure-using-ssl.html http://dev.mysql.com/doc/refman/5.1/en/secure-using-ssl.html

Other precautions

Denial of Service