EJBCA support, development and maintenance by

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 (or three) 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 information, should not be used for enrollment since it's not encrypted.
• 8442 - the public HTTPS port (server side only SSL) 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.

You can choose to have both 8080 and 8442, or only one of them open whichever suits your needs.

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

<subsystem xmlns="urn:jboss:domain:jmx:1.3">
  <expose-resolved-model/>
  <expose-expression-model/>
  <remoting-connector/>
</subsystem>

<virtual-server name="default-host" enable-welcome-root="false"

<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <rewrite pattern=".*" substitution="-" flags="F">
            <condition test="%{REQUEST_METHOD}" pattern="^(PUT|DELETE|TRACE|OPTIONS)$" flags="NC" />
    </rewrite>
    </virtual-server>
</subsystem>

<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'"
</IfModule>

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.

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:

Database Integrity Protection

Database integrity protection consists of an additional column in all protected tables, "rowProtection".

In order to be flexible, versions and keyid are embedded in the rowProtection line. Versions allow the tables themselves to be modified safely because the entity class can create "version 2" of the protect string with new fields, but still verify "version 1" and other legacy versions rows without the additional field. ProtectData can update the algorithm used, etc. by iterating the version number. The protection key can be changed because the user defines the keyid of the crypto token and always verifies using a specific keyid. The keyids are specified in configuration and multiple keyids can be active at any moment.

conf/databaseprotection.properties

conf/cesecore.properties
conf/databaseprotection.properties

Datasource Passwords

Before venturing into this chapter, be aware that it increases complexity of management of your system. You should consider if this really increase the security of your system and if it is required from policy.

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

There is another explanation for JBoss 7 at Stackoverflow.

Summary:

• Run the following script to generate an encrypted encoded password (PLACEHOLDER is your password):

# java -cp /opt/jboss/modules/system/layers/base/org/picketbox/main/picketbox-4.1.1.Final-redhat-1.jar:/opt/jboss/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.1.4.GA-redhat-2.jar:$CLASSPATH org.picketbox.datasource.security.SecureIdentityLoginModule PLACEHOLDER

• Copy the encoded password. Paste it into the standalone.xml configuration file.

$ vim /opt/jboss/standalone/configuration/standalone.xml

Paste the following segment into the security-domains segment (where PLACEHOLDER_ENC is the encoded password you got from the above command):

<security-domain name="EjbcaDsEncryptedPassword">
         <authentication>
                  <login-module code="SecureIdentity" flag="required">
                        <module-option name="username" value="ejbca"/>
                        <module-option name="password" value="PLACEHOLDER_ENC"/>
                  </login-module>
         </authentication>
</security-domain>

Look for the EjbcaDS datasource segment and replace the security segment (where PLACEHOLDER is your old clear text database password):

<security>
        <user-name>ejbca</user-name>
        <password>PLACEHOLDER</password>
</security>

with the following value:

<security>
         <security-domain>EjbcaDsEncryptedPassword</security-domain>
</security>

You can also look into using the vault.sh script, which you can find on the Internet.

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 MariaDB

MariaDB have a guide regarding usage of SSL connection for the database connection.

Other precautions

Denial of Service