Security

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.

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.

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://wiki.jboss.org/wiki/Wiki.jsp?page=EncryptingDataSourcePasswords

SSL connections in MySQL

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

Other precautions

Database transaction logs in MySQL:
http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

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