9   More    Next Blog» Create Blog   Sign In

Installing EJBCA on JBoss and CentOS 6

A thorough, detailed, and impartial guide to installing the EJBCA Certificate Authority on CentOS 6 using Jboss /
Wildfly. Included is a review of elliptic curve encryption and openssl certificate generation.

S u n d a y,   A p r i l   2 7 ,   2 0 1 4

How to Install EJBCA 6.1.1 on JBoss 7.1.1 and

CentOS 6
Introduction
Hello, and welcome to this blog.

I've needed a CA in my lab for quite some time, and I decided to try ejbca for the following reasons:

1. It's linux‐based.
2. It has a native web interface.
3. It's written on a reasonably mature middleware platform.
4. It seems fairly full‐featured.

I'm writing this because installing ejbca is harder than it should be.

I have never been impressed by "documentation" that destroys time rather than saving it.
I believe that software is only as good as a user's ability to use it.

So I am documenting each step of my installation for use as a "cookbook" by others.

But before I begin: it's a little‐known fact that all material published on Blogger is automatically copyrighted. Not a GPL copyleft,
but a full‐blown Unites States of America copyright. This blog and its content are copyrighted in 2014 by VES Group Incorporated
and all rights are reserved.

After (too) much thought, I've decided that the best license to provide this document under is: "Creative Commons Attribution‐
NonCommercial‐ShareAlike International 4.0". The license details are included at the end of the document.

Wrapping up the subject of copyright: I hereby acknowledge that EJBCA® is a registered trademark of PrimeKey Solutions AB.

Preparation

I have tried to write this how‐to in the form of a teaching document. Ideally, even a novice linux user should be able to follow
these instructions and have a functional, stable, and secure ejbca installation at the end. And, honestly, even the most
knowledgeable sysadmin has days where they feel like a complete beginner. So hopefully both ends of the experience spectrum
will get something out of reading this.

Installation requires a significant amount of planning. Here are a few things I'd like to point out.

The product can be built on distributed platforms for HA and load‐spreading purposes. This guide assumes a single
server for test purposes only.
Storage and memory: assume that the CA will take 512MB of RAM, as a rule of thumb. The code itself is ~200MB or so,
so give yourself at least a few gigs of space for logs, etc.
Software versions: there are several pieces of software that ejbca depends on. Each has its own version dependencies.
This can be challenging.
How you will configure your CAs, what encryption packages to use, etc, will be detailed later in this guide. None of
those specifics really matter until you have the product fully installed.

The reader should have a working knowledge of directory services and their formats. At a minimum, you should thoroughly
understand:

The difference between a DNS hostname and a FQDN.

The basics of PKI, at least to the point of knowing how root chain validation works.
A minimum of X.500 notation:
CN = Common Name, usually is the FQDN of your CA
DN = Distinguished Name, which is the CN followed by information about the organization that owns the CA
O = Organization, usually is your company name, and can include spaces
C = Country, in ISO 3166‐1 alpha‐2 format (US, CA, SE, MX, etc)

You are not required to have an expert understanding of java and JBoss, but some knowledge is helpful. At the least, you should
understand:

What a .jar file is

What an .ear file is
The rudiments of XML (about 10 minutes of study is enough)
The notion of "deploying" an application to a platform like JBoss

Passwords

You will need to create a fairly large (10+) number of unique passwords just to install ejbca. So get the PasswordSafe utility.
Originally co‐written by Bruce Schneier, it is the only password repository I trust. I'll keep a running tally of the passwords we
create, and have included a list of them at the end of this document.

I cannot emphasize the importance of using strong passwords enough.

All of our other security steps are meaningless without strong passwords.

Use passwords of at least 24 characters.

Use upper and lower cases, numbers, and punctuation.
I suggest using a pseudorandom password generator (such as the one in PasswordSafe) to create them.

Ejbca's Terminology

The terminology ejbca uses is very confusing, even to someone experienced. Describing each term fully is more than I can do in
this document, but hopefully a brief description of the basics will be helpful:

Authentication Code ‐ Each Crypto Token has an associated Authentication Code that is used to encrypt the contents of
that particular Crypto Token.
Certificate ‐ A data structure (usually) in X.509 format that typically contains:
A Public Key
Information about the owner of the key (in X.500 format)
"Certificate Extensions" defining how the certificate is meant to be used
The CA certificates that validate the certificate we are examining
Certificate Extension ‐ Data field in a Certificate that "suggests" how the Certificate is meant to be used.
Certificate Signing Request (CSR) ‐ A file containing a Public Key, as well as optional Certificate Extension information
that a CA *may* use when generating a Certificate.
Crypto Token ‐ The logical unit that stores all the public/private Keypairs owned by a particular CA. By default, they
are held in ejbca's database.
Enrollment Code ‐ The password (or other "Token") used to validate a certificate request.
HSM ‐ Hardware Security Module. A physical device used to generate and/or store Keys.
JKS ‐ Java Key Store. An unencrypted, file‐based method of storing encryptions keys.
Key/Keypair ‐ What ejbca refers to as a "Key" is actually a "Keypair": a Public Key and its matching Private Key.
Key Algorithm ‐ The asymmetric cryptographic algorithm used to perform public key encryption. Usually RSA or Elliptic
Curve. One must be specified in every certificate.
Key Alias ‐ A "friendly" name for a Key(pair) that is used for a particular purpose. Ejbca uses the following Key Aliases
to refer to the Keys every ejbca CA must have for basic functionality:
defaultKey: The key used by default (Required).
 certSignKey: The key used for certificate signing. It must comply with the Signature Algorithm defined for
the CA using the key.
crlSignKey: The key used for CRL signing. The use of this key is deprecated ‐ the certSignKey will always be
used for this purpose.
keyEncryptKey: The key used for key recovery when reversible encryption is enabled. It must use the RSA
algorithm.
testKey: The key used by the healthcheck process to verify that a Crypto Token is usable. A 1024‐bit RSA key
is recommended to reduce computation time.
Key Specification ‐The length of the modulus used by the Key Algorithm. For RSA, it is usually 2048 or 4096 bits long.
For Elliptic Curve, it is usually 192, 256, 384, or 512 bits long.
Keystore ‐ A file used to store certificate information outside of the database. Normally only holds the certificates for
ejbca's web interface. See: JKS
Private Key ‐ Half of a Keypair generated for use with asymmetric encryption. This is the half that is kept private, and
not shared.
Public Key ‐ The other half of a Keypair, which is shared with anyone/anything you wish to establish secure
communications with.
Signature Algorithm ‐The cryptographic hash algorithm used by a CA to guarantee a certificate's validity.
Soft Token ‐ A Token (Crypto, or otherwise) held in the database, rather than in a different format like a JKS or HSM.
Token ‐ A generic term for a secret key. This could be anything from an 8‐character ASCII password to an 8192‐bit RSA
modulus. In the context of an "end entity", ejbca specifically uses this word to refer to the key used to encrypt a
certificate issued to that "end entity".

Final Advice

A final word of advice before we begin: You are building a device that will be the source of all trust in your environment. Details
matter. Accuracy matters ‐ even more than usual. And if it isn't right, it's wrong. Go fix it.

CentOS Installation
I use CentOS in my lab, generally speaking. This is because the vast majority of actual enterprise linux installations run on Red
Hat/Fedora. Debian/Ubuntu is prolific in software development environments, but that's really the only place I find it.

I'm performing this installation using 64‐bit CentOS 6.5 on a vm. There is a single root partition for storage, a two‐core CPU, 2 GB
of RAM (which is more than it needs), and a single ethernet network interface.

Please note that if your vm is underpowered, your installation will not work (see comments, below).
Required Software

I am using ejbca version 6.1.1, community edition. It is written in java, and runs on the JBoss platform. It uses ant for JBoss
management, and requires a database (I use mysql) for storage.

Java: DO NOT waste time trying to get java 1.7 to work with this OS and app version.

It can be done, but the payoff compared to the work involved makes it undesirable.
Running 1.6 has ramifications for Elliptic Curve support, but the way that ejbca uses java makes them largely
irrelevant.
Just use the openjdk version of java 1.6 that is distributed by the standard CentOS online repos.
It is possible to use newer versions of java with newer CentOS and JBoss/Wildfly releases. I detail this process on my
companion blog: ejbcawildfly.blogspot.com .

If you install openjdk java 1.7, then the "java" command will invoke 1.7 by virtue of alternatives. Theoretically,
alternatives should take care of redirecting all java‐related executable paths to the correct executables. However, what I
found is that the the 1.7 implementation from openjdk is incomplete, and ejbca will end up needing to use portions of version 1.6.
This inevitably ends up with a non‐working ejbca install.

If you truly must use 1.7, you'll need to manually compile and install updated versions of gcc, gcj, and Oracle Java. This may be
resolved in the current version of 1.7 in CentOS' distribution stream, but I have not tested this.

JBoss: I'm using 7.1.1 Final. It actually is the least painful thing to deal with in this setup. Previous versions of JBoss are built with
the idea of multiple application deployments on a single platform ‐ the current 7.1.1 download installs with a single standalone
deployment.

Ant: You'll need to download and install a current version of ant ‐ the one from CentOS is too old. I'm using ant­1.9.3­
2.fc21.noarch.rpm. I suggest searching rpm.pbone.net for an RPM from a recent Fedora distro.
Mysql: I'm using the standard mysql version 5.1.73‐3.el6_5 from the CentOS repos. The version really doesn't matter, other than
the various inevitable security problems you have with mysql.

Java Mysql Connector: I'm using the mysql‐connector‐java.noarch from Oracle, version 5.1.30. There is a configuration tweak in
JBoss that is necessary in order to use this version. Older versions do not have this problem (but may have others).

You do not need: tomcat/httpd, phpmyadmin, or any of the CentOS distro PKI apps.

A final note on code versions: I strongly suggest that you build your intitial deployment with the versions I suggest here, then
upgrade as needed. Or, move to a more‐recent version of ejbca and Wildfly.
Application Logical Layout

Adding more detail to the internals of ejbca itself, the application essentially has seven distinct components:

A Database
Java and its database connector
JBoss
The ejbca Certificate Authority
The ejbca Registration Authority
The ejbca Validation Authority
Ejbca's OCSP code

No Internet "howto" is complete without at least one goofy ASCII diagram, so here it is.
We will install and configure ejbca in essentially left‐to‐right order:

mysql ­­> java­sql­connector ­­> jboss ­­> ejbca CA ­­> ejbca VA ­­> OCSP 
                   ^               ^ 
                   |               |
                   ­­­­­­ java ­­­­­

We will ignore the "Registration Authority" for now, and treat it as part of the "Certificate Authority".

This build will be on a single server, so all of these functions will be performed on one box. But you can build ejbca as a set of
distributed servers if you wish. There are some sensible reasons for this:

CAs aren't very loaded when only issuing certs. But when answering CRL/OCSP queries, their load can become
significant.
You may not issue many certs, and want to take the core CA offline for security reasons. Distributed "validation" and
"registration" authorities can handle the validation work and registration work while the core services are offline.

But the usefulness of distributing out every little portion of an app can get a little ... hazy. My opinion is that most "distributed"
applications are written by insecure devs to show how awesome they are, and needlessly complicate things. As evidence of this:
WhatsApp runs over two million connections per server, and it earned those guys $19 Billion.

This how‐to only covers a standalone installation. But I'll try to point out the distributed stuff as we go along.

Beginning the Installation

To begin:
I suggest using a "Minimal Desktop" CentOS installation in order to have gnome and a web browser. This becomes
important later, as there are administrative sites and tools in JBoss and ejbca that are only reachable from
localhost. If I were building a production server, I would use the "Basic Server" CentOS installation.
No need to set up user accounts for now ‐ just use root.
Set the timezone, etc.
Set your hostname in /etc/hosts ‐ it should look something like:

127.0.0.1     localhost localhost.localdomain localhost4 localhost4.localdomain4 
::1           localhost localhost.localdomain localhost6 localhost6.localdomain6 
192.168.12.34 rootca rootca.yourcompany.com
In this how‐to, I will always use the FQDN of "rootca.yourcompany.com" to represent the server. This seems like a simple
decision, but there are several things to keep in mind when choosing your hostname:
In a production environment, you could potentially have multiple ejbca instances configured on a single JBoss
installation. This would have ramifications for hostname resolution, and this level of complexity is beyond the scope of
this how‐to. 
When running ejbca in a lab environment, it is tempting to disregard the full FQDN and only use the hostname when
identifying your CAs. You would be able to get away with this by virtue of your lab's isolation from public DNS
resolution. Trust me ‐ Don't do this. Define a full FQDN for your server that would be compatible with public DNS, and
continue with your build as if this were true.

A Word on CA Naming and Certificates

For someone who is not familiar with Certificate Authorities, it can be very confusing to keep track of the various certificates used
by a CA for different functions. Here are the basics as they relate to ejbca:

First, you must understand that it is possible to host multiple production CA instances on a single ejbca installation. In this
example, we will configure only a single "Production CA" in order to try to keep it simple.

However, ejbca uses a "Management CA" instance to generate certificates used both internally by the application, as well as to
issue certificates used to secure initial access to ejbca's web administration pages.

The "Management CA" is automatically created during installation, and cannot be removed. This implies that there will always be
at least two CA instances on an ejbca server:

The Management CA used to generate certificates for the administration of ejbca

The Production CA that will be used to issue certificates for external users and devices

Each CA will have unique X.500 CN field information, and will be configured separately.

The Management CA is purely an internal CA that will never be resolved via DNS, so I will set the CN of the management
CA to be "mgmtca".
The Production CA will use the actual FQDN of your server for its CN.

All this being said, there is an additional "very important thing" to understand about how the naming of the server relates to the
certificates created by the Management CA for web administration purposes.

When accessing the web interface of your ejbca server, a TLS certificate is used to encrypt the HTTPS connections to the web
service hosting the interface. The initial version of this certificate will be a "self‐signed" one issued by the Management CA and
created during installation.

However, toward the end of this how‐to, we will replace this certificate with one issued by a "Production" CA.
We do this to ensure that the server itself participates in the PKI that we establish with our "Production" CA.
Also, the Management CA cert does not use an FQDN for the CN, which breaks all kinds of browser functionality.

Replacing this initial certificate with one issued by the Production CA creates a situation that can be quite confusing to a beginner.
The "Root Certificate" used by the Production CA to identify itself and sign new certificates will use the FQDN of the
server (rootca.yourcompany.net) for its CN.
The Production CA will issue a "Server Certificate" that will replace the one issued by the Management CA. This
replacement certificate will permanently secure connections to the web administration pages (at
https://rootca.yourcompany.net), and will also use "rootca.yourcompany.net" for the CN.

Despite having the same CN, these are two separate certificates used for two distinct purposes. To try and keep this clear, I will
always use the phrases "Root CA Certificate" and "Server Certificate" to denote these certs.

To have a healthy and sane experience when building an ejbca server, it is important to understand that by the end of our install:
There will be two certificates
They are used for separate purposes (Root Certificate vs. Web Administration TLS)
They are both issued by the same Production CA
They use the same CN

Continuing the Installation...

 Set up resolv.conf and make sure an A record for rootca.yourcompany.net exists on the configured  DNS servers.
PTR records are also a good idea.
Set up NTP and make sure it works (ntpdate, etc)‐ correct time is mandatory.
Set up ssh/vnc access as you see fit.
Run yum update

Firewall Configuration

Ejbca uses 8080, 8442, and 8443 for CA services. Everything else is internal (3306 for mysql, 9990 for JBoss admin web interface,
etc). The application doesn't run as root, so you can't set the ports to anything <1024 ‐ don't bother trying to change them in the
application itself.

If you want to use the standard web ports, then set up iptables to do port forwarding. You can do this from the gnome firewall
management app:

Add port forward 80 ‐‐> local 8080, protocol tcp

Add port forward 442 ‐‐> local 8442, protocol tcp
Add port forward 443 ‐‐> local 8443, protocol tcp

Once finished, it's a good idea to verify your /etc/sysconfig/iptables file:

vi /etc/sysconfig/iptables 

### Start iptables ###

# Firewall configuration written by system­config­firewall 
# Manual customization of this file is not recommended. 
*mangle 
:PREROUTING ACCEPT [0:0] 
:INPUT ACCEPT [0:0] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
:POSTROUTING ACCEPT [0:0] 
­A PREROUTING ­i eth0 ­p tcp ­­dport 80 ­j MARK ­­set­mark 0x64 
­A PREROUTING ­i eth0 ­p tcp ­­dport 442 ­j MARK ­­set­mark 0x65 
­A PREROUTING ­i eth0 ­p tcp ­­dport 443 ­j MARK ­­set­mark 0x66 
COMMIT 
*nat 
:PREROUTING ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
:POSTROUTING ACCEPT [0:0] 
­A PREROUTING ­i eth0 ­p tcp ­­dport 80 ­m mark ­­mark 0x64 ­j DNAT ­­to­destination :8080 
­A PREROUTING ­i eth0 ­p tcp ­­dport 442 ­m mark ­­mark 0x65 ­j DNAT ­­to­destination :8442 
­A PREROUTING ­i eth0 ­p tcp ­­dport 443 ­m mark ­­mark 0x66 ­j DNAT ­­to­destination :8443 
COMMIT 
*filter 
:INPUT ACCEPT [0:0] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
­A INPUT ­m state ­­state ESTABLISHED,RELATED ­j ACCEPT 
­A INPUT ­p icmp ­j ACCEPT 
­A INPUT ­i lo ­j ACCEPT 
­A INPUT ­i eth0 ­m state ­­state NEW ­m tcp ­p tcp ­­dport 8080 ­m mark ­­mark 0x64 ­j ACCEPT 
­A INPUT ­i eth0 ­m state ­­state NEW ­m tcp ­p tcp ­­dport 8442 ­m mark ­­mark 0x65 ­j ACCEPT 
­A INPUT ­i eth0 ­m state ­­state NEW ­m tcp ­p tcp ­­dport 8443 ­m mark ­­mark 0x66 ­j ACCEPT 
­A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 443 ­j ACCEPT 
­A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 22 ­j ACCEPT 
­A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 80 ­j ACCEPT 
­A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 442 ­j ACCEPT
­A INPUT ­j REJECT ­­reject­with icmp­host­prohibited 
­A FORWARD ­j REJECT ­­reject­with icmp­host­prohibited 
COMMIT

### End iptables ###
If you are only working in the cli, I'd manually edit /etc/sysconfig/iptables , then reload the firewall:

service iptables reload

Regardless of how you do it, it's a good idea to back up the firewall config:

cp /etc/sysconfig/iptables /etc/sysconfig iptables.initial

Disabling IPv6

There really is no point in having IPv6, so I remove it:

In /boot/grub/grub.conf , edit the boot kernel line to include:

     ipv6.disable=1

It will look something like:

kernel /vmlinuz­2.6.32­431.11.2.el6.x86_64 ro root=/dev/mapper/vg_rootca­lv_root rd_NO_LUKS
rd_LVM_LV=vg_rootca/lv_root rd_NO_MD SYSFONT=latarcyrheb­sun16 rd_LVM_LV=vg_rootca/lv_swap KEYBOARDTYPE=pc
KEYTABLE=us rd_NO_DM LANG=en_US.UTF­8 rhgb quiet crashkernel=auto ipv6.disable=1

In /etc/sysctl.conf , change/create these entries:

     net.ipv6.conf.all.disable_ipv6 = 1 
     net.ipv6.conf.default.disable_ipv6 = 1

In /etc/sysconfig/network , change/create these entries:

     NETWORKING_IPV6=no 
     IPV6INIT=no

In /etc/modprobe.d/blacklist.conf , change/create these entries:

     blacklist net­pf­10 
     blacklist ipv6

Disable iptables for IPv6:

     service ip6tables stop 
     chkconfig ip6tables off

To be extra awesome, make sure that IPv6 driver loads will always silently fail:
     echo "install ipv6 /bin/true" > /etc/modprobe.d/ipv6_disabled.conf

To be extra EXTRA awesome, follow the "extra notes" on disabling IPv6 located at:
     http://wiki.centos.org/FAQ/CentOS6

Installing Software Packages

Now we install our CentOS software packages. When reviewing your installation, you may have noticed that there's a version 1.5
gjc installed ‐ It's used for compilation of the java packages. It can't be removed without causing problems, and alternatives
prevents it from affecting anything. Just ignore it.

yum install java­1.6.0­openjdk
yum install /path/to/your/ant­noarch.rpm 
yum install mysql­server 
yum install mysql­connector­java

It's a pretty good idea to verify our java version with java ­version , both with the implicit path and the full path you will
define as JAVA_HOME in standalone.conf : /usr/lib/jvm/java/bin/java ­version . Once this is done, you can be sure
that java works, and executes the expected version regardless of path:

/usr/lib/jvm/java/bin/java ­version
java version "1.6.0_30" 
OpenJDK Runtime Environment (IcedTea6 1.13.3) (rhel­5.1.13.3.el6_5­x86_64) 
OpenJDK 64­Bit Server VM (build 23.25­b01, mixed mode)

Configuring Mysql

This is a basic mysql setup that isn't particularly tuned for security, but is secure enough for lab purposes. Be sure to create the
mysql directories and update /etc/my.cnf before starting the service for the first time, as you can't easily change the binary log
location once it has been created.
This config also forces utf‐8 encoding, which is a requirement of ejbca.

The utf‐8 client config can throw errors on startup (depending on your version of mysql), so it is commented out.

I enable binary logging in order to make database recovery as bulletproof as I can. But there's no substitute for a
regular mysqldump.
Ejbca includes a sample backup script for this purpose.
It's important to remember that the binary logs will contain your certificate data, and so must be set with restrictive
permissions. 
Also note that if you are using MariaDB, it may refuse to start because of InnoDB being unable to process the binary
logs. Add binlog_format=row to the configuration below to resolve the problem.

mkdir ­p /var/log/mysql/bin 
chown ­R mysql:mysql /var/log/mysql
chmod ­R 750 /var/log/mysql/bin 

vi /etc/my.cnf 

### Start my.cnf ###

[mysqld] 
datadir=/var/lib/mysql 
socket=/var/lib/mysql/mysql.sock 
user=mysql
# Disabling symbolic­links is recommended to prevent assorted security risks 
symbolic­links=0 

#UTF­8 
character­set­server=utf8 
collation­server=utf8_unicode_ci 
init­connect='SET NAMES utf8' 
#character­set­client = utf8 

# Logging Config 

# Binary logging 
log­bin 
server­id              = 1 
log_bin                = /var/log/mysql/bin/mysql­bin.log 
expire_logs_days       = 10 
max_binlog_size        = 100M 

#log 
#log­error
#log­slow­queries 

[mysqld_safe] 
log­error=/var/log/mysql/mysqld.log 
pid­file=/var/run/mysqld/mysqld.pid 

# Custom config 
#[client] 
#default­character­set=utf8
### End my.cnf ###

To make a point about the mysql user continuing to own everything mysql‐related:

chown mysql:mysql /etc/my.cnf

Now, run the "secure installation" script (take the default actions), log in to mysql, and create the database and user account for
ejbca:

service mysqld start 
mysql_secure_installation 
mysql ­u root ­p 
create database ejbcadb; 
grant all privileges on ejbcadb.* to 'ejbcadbuser'@'localhost' identified by 'password'; 
flush privileges; 
exit

Verify that you can log in to mysql as ejbcadbuser and test your access:

mysql ­u ejbcadbuser ­p 
use ejbcadb;
show grants for ejbcadbuser@localhost;
exit 

Later, we will change the permissions on the ejbcadb database to make ejbcadbuser@localhost's access a little more limited.

Finalize the mysql installation by performing a service mysqld restart and checking the log at
/var/log/mysql/mysqld.log.

Creating the Directory Structure

Now we're going to set up the directory structure for the app itself. I prefer to put my apps in /opt. By default, all the ejbca
documentation assumes that you install it in the service user's homedir.

I like to use links to generic paths so that upgrading code is easier. This method also works well with Atlassian products.

The /opt/default directory is used to hold vanilla versions of code so you can easily wipe things out and start over.

mkdir /opt/default 
cd /opt/default 
wget http://download.jboss.org/jbossas/7.1/jboss­as­7.1.1.Final/jboss­as­7.1.1.Final.zip 
wget http://downloads.sourceforge.net/project/ejbca/ejbca6/ejbca_6_1_1/ejbca_ce_6_1_1.zip 
unzip *.zip 
cd .. 
ln ­s /opt/ejbca_ca_6_1_1 ejbca 
ln ­s /opt/jboss­as­7.1.1.Final jboss 
cp ­rp default/jboss­as­7.1.1.Final . 
cp ­rp default/ejbca_ce_6_1_1 .

Creating the OS User Accounts

Now we set up our service accounts. I made two ‐ a system account named jboss, and an ejbca account for administrative use
after the server is built.

It is important that jboss has /bin/bash for a shell and a /opt/jboss as a homedir.

useradd ­s /bin/bash ­r ­d /opt/jboss ­M ­U jboss 
useradd ­m ­U ­G jboss,wheel ejbca
Creating the Console Log Directory

Now that our service user has been created, we can create the directory that will hold our JBoss console logs:

mkdir ­p /var/log/ejbca 
chown jboss:jboss /var/log/ejbca

At this point, the server is built, mysql is running, and we're ready to start with installing JBoss. It's a good time to take
a vm snapshot.

Installing JBoss
It's time to install JBoss. We will not configure every detail (no mail, default logging), but we will do enough to get the platform
running and tweaked the way ejbca needs for installation.

Configuring the Standalone JBoss Instance

We begin by configuring the JBoss instance that ejbca will use. It's named "standalone", and exists by default in version 7.1.1.

The /opt/jboss/bin directory contains a script named standalone.sh that is the primary start point for JBoss. This script
references a configuration file in the same directory named standalone.conf. We will not need to modify the startup script,
but we will need to modify the configuration file.

First, we make a backup of the default config:

cd /opt/jboss/bin
cp standalone.conf standalone.conf.orig

The config file also contains a set of jvm options that I tweak a little bit. This is not a mandatory change, but it does allocate more
memory to the jvm. I always seem to be increasing this variable for my jvms, so I'm simply doing this ahead of when I actually
need to.

Important: The bits below are only the parts I modified ‐ don't delete the rest of the files!
I've added some commented entries that you might need to use if you're troubleshooting, but really the only things that
matter are JAVA_HOME and JAVA_OPTS.
Just add the comments to the top of the file and replace the default JAVA_HOME and JAVA_OPTS.

### Start standalone.conf Delta ###

#ejbca config 
# 
#javaHome=/usr/lib/jvm/java 
#jbossHome=/opt/jboss 
#jbossClasspath=/usr/share/java/mysql.jar 
JAVA_HOME="/usr/lib/jvm/java" 
JAVA_OPTS="­Xms128m ­Xmx512m ­XX:PermSize=128m ­XX:MaxPermSize=256m ­Djava.net.preferIPv4Stack=true ­
Dorg.jboss.resolver.warning=true ­Dsun.rmi.dgc.client.gcInterval=3600000 ­Dsun.rmi.dgc.server.gcInterval=3600000"

### End standalone.conf Delta ###

Creating the JBoss Init Service

The /opt/jboss/bin/standalone.sh script can always be used to start and stop JBoss manually. However, we need to
configure a service instance named "ejbca" to handle the startup and shutdown of JBoss (and subsequently, ejbca). Thankfully,
the JBoss folks give us an example script to use.

I know it is confusing to name the JBoss service "ejbca", but I am assuming that this JBoss instance will only run the
ejbca application and not be used for any other purpose.
The init script itself contains a very important variable: the path of the JBoss home directory.
First, we copy the examples to their proper locations:

cp /opt/jboss/bin/init.d/jboss­as­standalone.sh /etc/init.d/ejbca 
mkdir /etc/ejbca 
cp /opt/jboss/bin/init.d/jboss­as.conf /etc/ejbca/ejbca­init.conf

Then, we modify both files to be appropriate for our installation. Below are my examples.

Again, these are only the changes that must be made to the default file content.

vi /etc/init.d/ejbca

### Start ejbca init.d Delta ###

### BEGIN INIT INFO 
# chkconfig ­ 345 97 17 
# Provides:          ejbca 
# Required­Start:    $remote_fs $syslog $network mysqld 
# Required­Stop:     $remote_fs $syslog $network 
# Short­Description: ejbca jboss instance 
# Description:       ejbca jboss instance
# Default­Start:     3 4 5 
# Default­Stop:      0 1 2 6 
### END INIT INFO
# 
# processname: ejbca 
# pidfile: /var/run/jboss­standalone.pid 
# config: /etc/ejbca/ejbca­init.conf 
JBOSS_CONF="/etc/ejbca/ejbca­init.conf" 
JBOSS_HOME=/opt/jboss 
prog='ejbca jboss instance'

### End ejbca init.d Delta ###

The ejbca­init.conf file has two very important variables in it: the JBoss process username, and the logfile name.

vi /etc/ejbca/ejbca­init.conf

### Start ejbca­init.conf ###

# General configuration for the init.d scripts, 
# not necessarily for JBoss AS itself. 

# The username who should own the process. 
# 
JBOSS_USER=jboss 

# The amount of time to wait for startup 
# 
# STARTUP_WAIT=10 

# The amount of time to wait for shutdown 
# 
# SHUTDOWN_WAIT=10 

# Location to keep the console log 
# 
JBOSS_CONSOLE_LOG=/var/log/ejbca/console.log

### End ejbca­init.conf ###

Lastly, we use chkconfig to add our services to the rc hierarchy and set the runlevels:
chkconfig ­­add ejbca
chkconfig ­­level 345 mysqld on
chkconfig ­­level 345 ejbca on 

The init files should remain owned by root:root, with the default permissions.

Setting the Service Order

Although we have added the ejbca service with chkconfig, and have set a start order value in the chkconfig portion of the
init script header, we still need to review the service order during startup and shutdown.

In my case, I have the ejbca service set with a start integer of 97, and a kill integer of 17. This puts it before the local service,
but after everything else. The mysqld is set with a start of 64, and a kill of 36.

By default, the mysqld service is configured to wait for the the network service to initialize before starting, and the example
init script for ejbca will wait for mysqld to start. However, you still must read the contents of each runlevel init directory
(rc3.d, rc4.d, rc5.d) and create/modify the needed links to manage mysqld and ejbca .

Theoretically, chkconfig and yum are supposed to build these links for us automatically. But sometimes, well, things
just don't work out that way. 

In the example below, I noted that while ejbca was added correctly, there was a missing start entry for mysqld.

cd /etc/rc.d/rc3.d

ls ­al|grep ejbca
lrwxrwxrwx. 1 root root 15 May 1 13:30 K17ejbca ­> ../init.d/ejbca 
lrwxrwxrwx. 1 root root 15 Apr 25 22:24 S97ejbca ­> ../init.d/ejbca

ls ­al|grep mysqld
lrwxrwxrwx. 1 root root 16 Apr 25 22:24 K36mysqld ­> ../init.d/mysqld

ln ­s ../init.d/mysqld S64mysqld 

ls ­al|grep mysqld
lrwxrwxrwx. 1 root root 16 Apr 25 22:24 K36mysqld ­> ../init.d/mysqld 
lrwxrwxrwx. 1 root root 16 May 1 13:32 S64mysqld ­> ../init.d/mysqld

Adding JBoss Class Exports

We are now ready to begin tweaking the JBoss configuration in earnest. We'll start by enabling certain security functions that
ejbca requires.

cd /opt/jboss/modules/sun/jdk/main
vi module.xml

Add the following entries to the to system export paths:

Do not include the hashed start and end comments.

### Start module.xml Delta ###

            <path name="sun/security/x509"/>
            <path name="sun/security/pkcs11"/>
            <path name="sun/security/pkcs11/wrapper"/>
            <path name="sun/security/action"/>

### End module.xml Delta ###

Installing the Mysql Connector

Adding the java mysql connector to JBoss is a little convoluted. As mentioned, I am using the latest Oracle version, which is
version 5.1.30. This version breaks JBoss, as it requires an additional config variable that JBoss doesn't expect. You can assume all
versions of the connector from 5.1.30 onward will have this problem (at least until JBoss fixes their side of the code).

Instead of attacking this problem immediately, we will proceed with the CentOS‐distributed version of the connector, ensure that
we have a working JBoss installation, and then deal with updating it.

First, install the CentOS‐distributed version:

yum install mysql­connector­java

Now, create the directory that will hold JBoss' link to mysql­connector­java.jar , and the link itself:

mkdir ­p /opt/jboss/modules/com/mysql/main/
cd /opt/jboss/modules/com/mysql/main
ln ­s /usr/share/java/mysql­connector­java.jar mysql­connector­java.jar

Now, build the module.xml file that describes the connector.

Again, do not include the triple‐hashed lines in this file, as XML does not recognize "#" as denoting a comment.

vi module.xml

### Start module.xml ###

<?xml version="1.0" encoding="UTF­8"?>
    <module xmlns="urn:jboss:module:1.0" name="com.mysql">
        <resources>
            <resource­root path="mysql­connector­java.jar"/>
        </resources>
        <dependencies>
            <module name="javax.api"/>
            <module name="javax.transaction.api"/>
        </dependencies>
    </module>

### End module.xml ###

Starting JBoss

Our next set of tweaks must be made after JBoss has been started.

Because our actions until now have been performed as root, we must first make the jboss user the owner of the JBoss directory
tree.

Don't run "chown ­R root:root /opt/jboss" ‐ we want root to remain the owner of the symbolic link.

chown ­R jboss:jboss /opt/jboss­as­7.1.1.Final

Now, we test how well our init scripting works:

service ejbca start

Now that we've (hopefully!) started the service, we can check the console log (as it has just been created).
It's a good idea to keep a running console session open from now on.

tail ­f /var/log/ejbca/console.log

You should see something like this at the end of the file:

22:51:40,482 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1­2) Starting Coyote HTTP/1.1 on
http­­127.0.0.1­8080 
22:51:40,688 INFO  [org.jboss.as.remoting] (MSC service thread 1­3) JBAS017100: Listening on /127.0.0.1:4447 
22:51:40,690 INFO  [org.jboss.as.remoting] (MSC service thread 1­2) JBAS017100: Listening on /127.0.0.1:9999 
22:51:40,699 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1­3) JBAS015012: Started
FileSystemDeploymentService for directory /opt/jboss/standalone/deployments 
22:51:40,773 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on
http://127.0.0.1:9990 
22:51:40,774 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in
1528ms ­ Started 130 of 204 services (74 services are passive or on­demand)

This tells you several important things:

The JBoss admin webpage is only available to localhost by default, so you should install Firefox in your gnome
session if you don't already have it.
The default URL for the admin webpage is something like: http://localhost:9990/console/App.html#server­
overview
When you see this in the log, JBoss has finished loading:

"7.1.1.Final "Brontes" started in xxxx ms"

Enabling the Mysql Connector

Now that the JBoss service is running, we can enable our mysql connector. We will do this using the JBoss command line interface,
which will update the configuration of the standalone instance. But before we make the change, we will first back up the
configuration:

cd /opt/jboss/standalone/configuration
cp standalone.xml standalone.xml.initial

Now, we run a registration command from the JBoss CLI (the small text is a single line):

    cd /opt/jboss/bin
    sh jboss­cli.sh
    connect
    /subsystem=datasources/jdbc­driver=com.mysql.jdbc.Driver:add(driver­name=com.mysql.jdbc.Driver,driver­module­
name=com.mysql,driver­xa­datasource­class­name=com.mysql.jdbc.jdbc.jdbc2.optional.MysqlXADataSource)
    :reload
    exit

This cli action defines our mysql driver in /opt/jboss/standalone/configuration/standalone.xml, then reloads JBoss.

The actual definition is:

### Start standalone.xml Snip ###

<driver name="com.mysql.jdbc.Driver" module="com.mysql"> 
   <xa­datasource­class>com.mysql.jdbc.jdbc.jdbc2.optional.MysqlXADataSource</xa­datasource­class> 
</driver>

### End standalone.xml Snip ###

The standalone.xml file is the primary configuration file in JBoss, and we will be working with it several times
during installation. However, it does not normally need to be changed once our installation is complete.

If we have been successful with our changes, we should see the following message appear in the console log when restarting JBoss:

22:46:29,580 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool ­­ 27) JBAS010404:
Deploying non­JDBC­compliant driver class com.mysql.jdbc.Driver (version 5.1)

Removing the Default h2 Datasource and Driver

By default, the standalone instance is defined with an h2/hsqldb database connector, and an example database. If left
unchanged, ejbca is preconfigured to use it for example purposes. We will not use it, so we modify standalone.xml to disable
it.
 Note that this h2 db instance is an ephemeral "in‐memory" database which does not store data on disk, does not provide
external TCP/IP connectivity, and can pretty much be ignored.

vi standalone.xml

### Start standalone.xml Delta ###

Remove the following:

              <datasource jndi­name="java:jboss/datasources/ExampleDS" pool­name="ExampleDS" enabled="true" use­
java­context="true">
                    <connection­url>jdbc:h2:mem:test;DB_CLOSE_DELAY=­1</connection­url>
                    <driver>h2</driver>
                    <security>
                        <user­name>sa</user­name>
                        <password>sa</password>
                    </security>
                </datasource>

Also remove:

                <driver name="h2" module="com.h2database.h2"> 
                    <xa­datasource­class>org.h2.jdbcx.JdbcDataSource</xa­datasource­class>
                </driver>

### End standalone.xml Delta ###

Now, if you watch the console log when restarting JBoss, you should no longer see:

22:46:29,570 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool ­­ 27) JBAS010403:
Deploying JDBC­compliant driver class org.h2.Driver (version 1.3)

But you should continue to see:

22:46:29,580 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool ­­ 27) JBAS010404:
Deploying non­JDBC­compliant driver class com.mysql.jdbc.Driver (version 5.1)

Updating the Mysql Connector

Now that we have a functioning mysql connector, let's break it!

First, download the latest platform‐independent version of the connector from Oracle (I assume this will be version 5.1.30).

Oracle, of course, has to do things its own way, and refers to the connector as "Connector/J".  

Now expand the .tar or .zip file that you downloaded, and copy the mysql­connector­java­5.1.30­bin.jar file to
/usr/share/java:

cp /your/download/location/mysql­connector­java­5.1.30­bin.jar /usr/share/java

Verify its permissions:

ls ­al /usr/share/java/mysql­connector­java­5.1.30­bin.jar

­rw­r­­r­­.   1 root root   954041 May  1 01:22 mysql­connector­java­5.1.30­bin.jar

Next, delete and recreate the link "mysql­connector­java.jar" such that it points to the new file:

cd /usr/share/java
rm mysql­connector­java.jar
ln ­s mysql­connector­java­5.1.30­bin.jar mysql­connector­java.jar
Once this is done, JBoss will fail to load the connector at startup, as shown in the console log:

01:16:31,500 ERROR [org.jboss.as.controller.management­operation] (management­handler­thread ­ 17) JBAS014612:
Operation ("add") failed ­ address: ([ 
    ("subsystem" => "datasources"), 
    ("jdbc­driver" => "com.mysql.jdbc.Driver") 
]): org.jboss.msc.service.DuplicateServiceException: Service jboss.jdbc­driver.com_mysql_jdbc_Driver is already
registered

The fix for this is quite simple: add a single line to standalone.xml to update the driver stanza:

### Start standalone.xml Delta ###

            <datasources> 
                <drivers> 
                   <driver name="com.mysql.jdbc.Driver" module="com.mysql"> 
                        <driver­class>com.mysql.jdbc.Driver</driver­class> 
                        <xa­datasource­class>com.mysql.jdbc.jdbc.jdbc2.optional.MysqlXADataSource</xa­datasource­
class> 
                   </driver> 
                </drivers> 
            </datasources>

### End standalone.xml Delta ###

Restart the service, and the updated connector now loads properly.

Configuring the JBoss Web Admin User

Our last JBoss installation step is to create the account used to access the JBoss admin webpage. We use a specific script for this:

sh /opt/jboss/bin/add­user.sh  

What type of user do you wish to add?  
 a) Management User (mgmt­users.properties)  
 b) Application User (application­users.properties) 
(a): a 

Enter the details of the new user to add. 
Realm (ManagementRealm) :  
Username : jadmin 
Password :  
Re­enter Password :  
About to add user 'jadmin' for realm 'ManagementRealm' 
Is this correct yes/no? yes 
Added user 'jadmin' to file '/opt/jboss­as­7.1.1.Final/standalone/configuration/mgmt­users.properties' 
Added user 'jadmin' to file '/opt/jboss­as­7.1.1.Final/domain/configuration/mgmt­users.properties'

You should now be able to reach the JBoss web console interface and view/change various config items. At this time, you do not
need to change anything.
This is a JBoss‐specific user account not used anywhere else in our build. 
This is a good time to take a vm snapshot.

Installing Ejbca
Before we proceed, you should know that ejbca's initial configuration can be divided into a few specific parts:

The .properties files in the /opt/ejbca/conf directory

The initial keystore files in /opt/ejbca/p12
The JBoss config in standalone.xml
You should also know these general rules for working with ejbca's configuration:

First, assume that nothing in the configuration will be changed during deployment, and that only the ejbca.ear file is
touched by this action.
The mysql database will be auto‐populated when we first deploy ejbca, but will not otherwise be touched by any of the
ant scripts.
The database does not store any configuration data, but it can be affected by every configuration change you make.
The ant install command tries to create the keystore files each time it is run, even if the files exist.
Portions of standalone.xml can be changed by both ant build and ant install, but only in response to changes
made to our .properties files.
Once our initial installation is complete, ant will not change standalone.xml unless we have changed a
.properties file.

Ejbca Properties Files

Ejbca uses flat text ".properties" files for its primary configuration. These files are referenced when compiling ejbca.ear
with ant, and generally are not referenced by the running application.
The install.properties file is only referenced when running ant install, and is not referenced by ant
deploy.
Some files actually contain parameters to allow runtime parsing of variables in the properties files, but this
functionality is disabled by default.

Initially, ejbca has sample versions of all properties files in the /opt/ejbca/conf directory. The ones that are required by our
build are:

certstore.properties    ‐  Defines the certificate store variables

cesecore.properties     ‐  Defines the core security engine variables
crlstore.properties     ‐  Defines the CRL store variables
database.properties     ‐  Defines how ejbca will access the db
ejbca.properties        ‐  Defines the basic variables for ejbca itself
install.properties      ‐  Used by "ant install" during installation
mail.properties         ‐  Defines how the ejbca SMTP connector will function
ocsp.properties         ‐  Defines how OCSP itself will function
va.properties           ‐  Defines how the validation authority will function
va­publisher.properties ‐  Defines how the validation authority will access the db
web.properties          ‐  Defines variables for ejbca's web interface

There are multiple jndi.* files, and a file called extendedkeyusage.properties in the conf directory as well. They are
required, but will not be configured further, and can be ignored. There are also two directories, logdevices and plugins, that
can also be ignored.

First, we create a new directory called: /opt/ejbca/conf/sample, and move all .sample files to it for clarity and backup
purposes:

cd /opt/ejbca/conf
mkdir sample
mv *.sample sample

Now we copy a specific subset of files back to the main directory:

cp sample/certstore.properties.sample certstore.properties
cp sample/cesecore.properties.sample cesecore.properties
cp sample/crlstore.properties.sample crlstore.properties
cp sample/database.properties.sample database.properties
cp sample/ejbca.properties.sample ejbca.properties
cp sample/install.properties.sample install.properties
cp sample/mail.properties.sample mail.properties
cp sample/web.properties.sample web.properties
We will configure these files, then test our installation before proceeding. With only these files defined, ejbca will be operate
without validation functionality.

There are a great number of variables to set, and I will not go into detail on each one. However, here are simplified configurations
that I am using for each file.

Each file is a complete working config.

I have stripped out most of the default comments and added some of my own.
It's a very good idea to take the configs I give here and use them as a reference for your own configuration rather than
cutting and pasting. It's the best way to learn all of the variables.
You must enter your own email addresses, passwords, FQDNs, and X.500 CN / DN values.
The Start and End comments are not needed in each config.
Note that your browser may render long configuration lines into two sequential lines, which can cause problems with
commenting. Double‐check the syntax in each file before applying!

certstore.properties

### Start certstore.properties ###

# ­­­­­­­­­­­­ RFC 4387 Certificate store configuration ­­­­­­­­­­­­­­­­­­­­­
certstore.enabled=true 

# This is the web directory that the web interface for the cert store will use. 
# It is not the full path!
certstore.contextroot=/certificates

# This is an unused alternate location
#certstore.contextroot=/ejbca/publicweb/certificates

### End certstore.properties ###

cesecore.properties

### Start cesecore.properties ###

#allow.external­dynamic.configuration=false

# You do not need to configure this password!
#ca.keystorepass=!secret!

#ca.rngalgorithm=SHA1PRNG
#ca.serialnumberoctetsize=8

ca.toolateexpiredate=80000000
#ca.toolateexpiredate=2038­01­19 03:14:08+00:00

#ca.doPermitExtractablePrivateKeys=true

#forbidden.characters = \n\r;!\u0000%`?$~
#intresources.preferredlanguage=EN
#intresources.secondarylanguage=SE

#These variables will enable explicit logging. You can turn them off later
securityeventsaudit.implementation.X=org.cesecore.audit.impl.log4j.Log4jDevice
securityeventsaudit.implementation.X=org.cesecore.audit.impl.integrityprotected.IntegrityProtectedDevice

#securityeventsaudit.implementation.0=null
#securityeventsaudit.implementation.1=null

#securityeventsaudit.exporter.X=org.cesecore.audit.impl.AuditExporterDummy (default)
#securityeventsaudit.exporter.X=org.cesecore.audit.impl.AuditExportCsv
#securityeventsaudit.exporter.X=org.cesecore.audit.impl.AuditExporterXml
#securityeventsaudit.deviceproperty.X.key.subkey=value

# More log config below 
securityeventsaudit.implementation.0=org.cesecore.audit.impl.log4j.Log4jDevice
securityeventsaudit.implementation.1=org.cesecore.audit.impl.integrityprotected.IntegrityProtectedDevice
securityeventsaudit.exporter.1=org.cesecore.audit.impl.AuditExporterXml

#securityeventsaudit.deviceproperty.1.export.dir=/tmp/
#securityeventsaudit.deviceproperty.1.export.fetchsize=1000
#securityeventsaudit.deviceproperty.1.validate.fetchsize=1000

#ecdsa.implicitlyca.q=883423532389192164791648750360308885314476597252960362792450860609699839
#ecdsa.implicitlyca.a=7fffffffffffffffffffffff7fffffffffff8000000000007ffffffffffc
#ecdsa.implicitlyca.b=6b016c3bdcf18941d0d654921475ca71a9db2fb27d1d37796185c2942c0a
#ecdsa.implicitlyca.g=020ffa963cdca8816ccc33b8642bedf905c3d358573d3f27fbbd3b3cb9aaaf
#ecdsa.implicitlyca.n=883423532389192164791648750360308884807550341691627752275345424702807307

### End cesecore.properties ###

crlstore.properties

### Start crlstore.properties ###

# This is all very similar to certstore.properties
# ­­­­­­­­­­­­ RFC 4387 CRL store configuration ­­­­­­­­­­­­­­­­­­­­­
crlstore.enabled=true
crlstore.contextroot=/crls
#crlstore.contextroot=/ejbca/publicweb/crls

### End crlstore.properties ###

database.properties

### Start database.properties ###

# ­­­­­­­­­­­­­ Database configuration ­­­­­­­­­­­­­­­­­­­­­­­­

#This variable is used in our standalone.xml <datasource> stanza
datasource.jndi­name=EjbcaDS

# This is the TYPE of db, not the NAME OF the db
database.name=mysql

# Be sure to use utf­8
database.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF­8  
database.driver=com.mysql.jdbc.Driver

database.username=ejbcadbuser

# Change this to your mysql user password: 
database.password=pumpkin

### End database.properties ###

ejbca.properties

### Start ejbca.properties ###

# The next two variables are very important...
appserver.home=/opt/jboss
appserver.type=jboss

# Initially, we will set this to false. Once the install is complete, we change
# this to true.
# But DO NOT set it to "ca"!
#ejbca.productionmode=true
ejbca.productionmode=false

#allow.external­dynamic.configuration=false

# Don't set these!
#ca.xkmskeystorepass=
#ca.cmskeystorepass=

approval.defaultrequestvalidity=28800
approval.defaultapprovalvalidity=28800
#approval.excludedClasses=org.ejbca.extra.caservice.ExtRACAServiceWorker
#approval.excludedClasses=org.ejbca.core.protocol.cmp.CmpMessageDispatcherSessionBean
#approval.excludedClasses=org.ejbca.core.protocol.cmp.RevocationMessageHandler
#approval.excludedClasses=

healthcheck.amountfreemem=32
healthcheck.dbquery=Select 1 From CertificateData where fingerprint='XX'
healthcheck.authorizedips=127.0.0.1
healthcheck.catokensigntest=true
healthcheck.publisherconnections=true
#healthcheck.maintenancefile=~/maintenance.properties
#healthcheck.maintenancepropertyname=DOWN_FOR_MAINTENANCE
healthcheck.okmessage=ALLOK
healthcheck.sendservererror=true
#healthcheck.customerrormessage=EJBCANOTOK

# It's important to change this to 8:
ejbca.passwordlogrounds=8

### End ejbca.properties ###

install.properties

### This file is essentially an "answer file" used when running the "ant install" command.
### The variables listed here are *not* used by ejbca while it is running.

### Start install.properties ###

# In every case that "CA" is mentioned in this file, it refers to the "management" CA ONLY.

# This will be the initial name of the management CA instance
# ejbca will use this for administration purpose, not your production CAs
# Note that the CN given here is NOT the FQDN of your CA!
# Why does this matter? This certificate will be temporarily installed 
# on your browser as a trusted root CA, but will not be communicated 
# with.
ca.name=mgmtca
ca.dn=CN=mgmtca,O=Your Company,C=US
ca.tokentype=soft
ca.tokenpassword=null

# This is the path to a "catoken.properties" file that will be created when 'ant
# install' is run. It will contain encryption parameters used by the mgmt CA.
# It is only used with hard encryption tokens, and can be ignored if your certs
# will be stored in the ejbca database (which is were we will be putting them.)

#ca.tokenproperties=/opt/ejbca/conf/catoken.properties

# THIS IS IMPORTANT
# You can assume that ejbca cannot use EC algorithms for the management CA.
# This does not mean that ejbca cannot issue certificates that use EC.
# It just means that the management CA will use RSA for internal purposes.
# The reason for this limitation is that the various EC algorithms are
# not equally supported by the various java flavors that could be used.
# More importantly, ejbca does not include any sort of logic to identify
# the version of java you are using to limit or correct your options.
# Choosing an unsupported algorithm here leads to a corrupt installation.
# This can waste a great amount of time, so just avoid EC. 
# You can use EC later with the actual production CAs you define.

# Keyspec for RSA keys is size of RSA keys (1024, 2048, 4096, 8192).
ca.keyspec=4096

# The keytype for the administrative CA, can be RSA, ECDSA or DSA
ca.keytype=RSA

# Even though SHA1 is still largely in use as a certificate hashing
# algorithm, I *strongly* suggest that you go with SHA256WithRSA.
# Also, please note that the "with/With" in the hash names is indeed case­sensitive. 
# Stay classy, Oracle.

# SHA1WithRSA, SHA1withECDSA, SHA256WithRSA, SHA256withECDSA.
ca.signaturealgorithm=SHA256WithRSA

# I set a CA validity of 10 years (including the leap years, rain man)
ca.validity=3652
ca.policy=null
ca.certificateprofile=ROOTCA

### End install.properties ###

mail.properties

### Start mail.properties ###

# This config is for the ejbca application mailer, not the jboss mailer. We will
# set that up later. For now, we just point to the local mail server in order to
# prevent errors in the console log.

mail.jndi­name=java:/EjbcaMail
mail.user=ejbca
mail.password=honeybunny
mail.smtp.host=localhost
mail.smtp.port=25
#mail.smtp.auth=false
#mail.smtp.starttls.enable=false 
mail.from=ejbca@yourcompany.net
#mail.debug=false
mail.contentencoding=UTF­8

### End mail.properties ###

web.properties

### Start web.properties ###

# The key to this portion of the config is understanding that this file affects
# the certificate used by the ejbca admin webpage. In install.properties, we
# defined variables for the management CA root certificate. But that certificate
# is not used for session TLS. The management CA issues a separate "server
# certificate" for that purpose that is defined here.

# ­­­­­­­­­­­­ Web GUI configuration ­­­­­­­­­­­­­­­­­­­­­
# Can not be set to false, commented away means that web will be configured.
#web.noconfigure=true

# Can not be set to false, commented away means that web will be configured.
# web.nosslconfigure=true

# You do not need to set this password!
#java.trustpassword=changeit
superadmin.cn=superadmin
superadmin.dn=CN=${superadmin.cn},O=Your Company,C=US

# You do not need to set this password!
#superadmin.password=ejbca

superadmin.batch=true

# You do not need to set this password!
#httpsserver.password=serverpwd

httpsserver.hostname=rootca.yourdomain.net

httpsserver.dn=CN=${httpsserver.hostname},O=Your Company,C=US

# This is the port that will host the unencrypted Ejbca Public Web page.
# Note that this will be used the CRL and OSCP URLs, although it will be NATted to port 80 by our firewall rules.

httpserver.pubhttp=8080

# This is the port that will host the encrypted Ejbca Public Web page, *without* client certificate authentication.
httpserver.pubhttps=8442

# This is the port that will host the encrypted Ejbca Public Web page,
# as well as the Administration page. Accessing content hosted on
# this port requires client certificate authentication.

# Note that the Ejbca Public Web page link to the administration
# page will try to include this port in the URL, regardless of any
# port redirection you may be using. This will fixed at the end of
# the how­to.

httpserver.privhttps=8443

# Trying to use port 443 will not work here, as it is a "privileged" port.
#httpserver.external.privhttps=443

#Don't set these up unless you use an apache proxy for port translation

#httpserver.external.fqdn=
#httpserver.external.fqdn=${httpsserver.hostname}

#httpsserver.bindaddress.pubhttp=0.0.0.0
#httpsserver.bindaddress.pubhttps=0.0.0.0
#httpsserver.bindaddress.privhttps=0.0.0.0

# Who let the Swedes in here?
#web.availablelanguages=EN,DE,ES,FR,IT,JA,PT,SE,UA,ZH,BS

web.availablelanguages=EN,DE,ES,FR,IT,JA,PT,UA,ZH,BS
web.contentencoding=UTF­8

# Well, this doesn't sound like a good idea. 
#hardtoken.diplaysensitiveinfo=true

#web.docbaseuri=disabled
#web.docbaseuri=internal
#web.docbaseuri=http://www.ejbca.org

#web.reqcertindb=true

web.selfreg.enabled=false
web.selfreg.defaultcerttype=1
web.selfreg.certtypes.1.description=User certificate
web.selfreg.certtypes.1.eeprofile=SOMEPROFILE
web.selfreg.certtypes.1.certprofile=ENDUSER
#web.selfreg.certtypes.1.usernamemapping=CN
web.renewalenabled=false
#web.manualclasspathsenabled=true

#web.errorpage.notification=An exception has occurred.
web.errorpage.notification=ZOMG PWND!!111!!!1!!!1

# This setting is good for a lab environment. Don't use this in production.
web.errorpage.stacktrace=true

#web.enableproxiedauth=true
web.log.adminremoteip=true
#web.log.adminforwardedip=true

### End web.properties ###

Initial Deployment

Now that we have a basic set of properties files, we can do our initial deployment of ejbca to JBoss.

Open a terminal session to solely monitor the jboss console file:

tail ­f /var/log/ejbca/console.log 

The jboss user must be the owner of both the jboss directory tree and the ejbca directory tree. Before running our initial
deployment, it's a requirement to ensure that this is the true.

service ejbca stop
chown ­R jboss:jboss /opt/jboss­as­7.1.1.Final
chown ­R jboss:jboss /opt/ejbca_ce_6_1_1
service ejbca start
cd /opt/ejbca
sudo ­u jboss ant deploy

Always execute ant as the jboss user. Otherwise, the files it creates will be owned by root, and you'll have 99
problems.
 I really mean that. An extremely effective way to have your ant actions fail miserably is to forget to execute them as
jboss.
Also, you must always execute ant from the /opt/ejbca directory, as that is where build.xml is located. You could
use a path variable when executing ant , but I find that just changing directory to /opt/ejbca is easier.
Lastly, JBoss must be running when you run ant.

The deployment process itself pulls information from our config data, uses that information to compile an ejbca.ear file, then
prompts jboss to deploy it. Because this is our first deployment, ant also does the following:

Adds our ejbca mail configuration to standalone.xml

Adds our ejbca datasource information to standalone.xml
Populates the database with the initial schema

While all this is happening, you'll see new messages quickly arrive in the console log, but you can usually spot a nice summary
section that is given before the actual compilation of ejbca.ear begins:

display­properties: 
     [echo]  
     [echo] ­­­­­­­­­­ EJBCA 6.1.1 (working copy) CONFIGURATION PROPERTIES ­­­­­­­­­­ 
     [echo] appserver.type           = jboss 
     [echo] appserver.subtype        = jboss7 
     [echo] appserver.home           = /opt/jboss 
     [echo] java.version             = 1.6.0_30 
     [echo] ocsp.defaultresponder    = CN=rootca.yourcompany.net,O=Your Company,C=US 
     [echo] ocsp.signaturealgorithm  = SHA1WithRSA;SHA1WithECDSA;SHA1WithDSA 
     [echo] datasource.jndi­name     = EjbcaDS 
     [echo] datasource.jndi­name­prefix = java:/ 
     [echo] database.name            = mysql 
     [echo] database.url             = jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF­8 
     [echo] database.driver          = com.mysql.jdbc.Driver 
     [echo] database.username        = ejbcadbuser 
     [echo] database.password        = *** 
     [echo] database.useSeparateCertificateTable = false 
     [echo] database.valid.connection.sql = select 1 
     [echo] mail.jndi­name           = java:/EjbcaMail 
     [echo] mail.from                = ejbca@yourcompany.net 
     [echo] mail.user                = ejbca 
     [echo] mail.password            = *** 
     [echo] mail.smtp.host           = localhost 
     [echo] mail.smtp.port           = 25 
     [echo] mail.smtp.auth           = false 
     [echo] mail.debug               = false 
     [echo] httpserver.pubhttp         = 8080 
     [echo] httpserver.pubhttps         = 8442 
     [echo] httpserver.privhttps     = 8443 
     [echo] httpserver.external.privhttps = 8443 
     [echo] httpsserver.hostname     = rootca.yourcompany.net 
     [echo] httpsserver.password     = *** 
     [echo] httpserver.external.fqdn =  
     [echo] web.contentencoding      = UTF­8 
     [echo] web.renewalenabled       = false 
     [echo] ejbcaws.enabled          = true 
     [echo] cmp.tcp.enabled                 = false 
     [echo] cmp.tcp.portno                  = 829 
     [echo] cmp.tcp.logdir                  = ./log 
     [echo] cmp.tcp.conffile                =  
     [echo] xkms.enabled                    = false 
     [echo] xkms.serviceport                = 8080

Deployment Error Messages

You'll also see various log messages showing errors on compilation. The following errors can be ignored ‐ they're bugs in jboss:

06:05:16,848 ERROR [org.jboss.as.controller.management­operation] (management­handler­thread ­ 1) JBAS014612:
Operation ("composite") failed ­ address: ([]): java.lang.IllegalArgumentException

06:05:39,477 ERROR [org.hibernate.internal.util.xml.ErrorLogger] (MSC service thread 1­4) HHH000196: Error parsing
XML (21) : cvc­complex­type.3.1: Value '1.0' of attribute 'version' of element 'entity­mappings' is not valid with
respect to the corresponding attribute use. Attribute 'version' has a fixed value of '2.0'.

15:29:58,915 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (MSC service thread 1­2) JSF1051:
Service entry 'org.jboss.as.web.deployment.jsf.JsfInjectionProvider' does not extend DiscoverableInjectionProvider. 
Entry will be ignored. 

This message refers to the fact that the community version of ejbca does not support database integrity protection:

06:06:13,175 INFO  [org.cesecore.dbprotection.ProtectedData] (MSC service thread 1­4) No database integrity
protection available in this version of EJBCA.

You'll always see these errors no matter what you do. Any other errors and failures should be dealt with before trying to proceed
to an installation. But eventually you'll see something like these messages if the deployment is successful:

01:38:38,724 INFO  [org.jboss.as] (MSC service thread 1­1) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in
7761ms ­ Started 2855 of 2968 services (111 services are passive or on­demand) 
01:38:38,769 INFO  [org.jboss.as.server] (DeploymentScanner­threads ­ 2) JBAS018559: Deployed "ejbca.ear"

Finally, note that you will see tons of the following messages returned directly by ant during every operation:

appserver.error.message: 
     [echo] jndi.properties.file: /opt/ejbca_ce_6_1_1/conf/jndi.properties.jboss7

These messages can be safely ignored.

More Detail on Ant

Why did we do an ant deploy before an ant install? There are two reasons:

To test that the ejbca.ear file is successfully compiled from what we have built so far. Running ant deploy while
reading the logs gives us a chance to fix mistakes before proceeding. Once installation is complete, it becomes much
more difficult to fix configuration mistakes.
More importantly, the ejbca.ear file must exist before the install script can execute.

It is worth taking the time to describe what the various ant command scripts do in slightly greater detail, and to learn a few new
ones. They are very useful when fixing with troublesome installations.

As you know, the ant deploy script creates temporary files used to compile ejbca.ear, compiles the ejbca.ear
file, and then prompts jboss to deploy it. It is worth mentioning that there are two distinct functions ("targets") being
called:
First, ant runs the build target that performs the preparation and compilation.
Then ant uses the jboss jee.deploy target to perform the actual transfer to jboss.

The build process can be called directly using ant build. But ant deploy always runs both targets.
The ant install script takes your configuration files, uses their information to create further configuration (such as
the keystore files), and copies these new files to their proper locations. Various changes to jboss are also made by this
script, and a full deployment must be performed manually once installation is complete.
A separate script for installation is required to segregate one‐time actions (like generating the keystores)
from the repetitive actions of deployment. You do not need to rebuild everything each time you deploy!
The ant clean command will clear temporary files created by prior deployments that may accidentally persist.
Deleting them can help resolve deployment errors that may arise.
If you continue to receive errors during deployment after trying ant clean, you may need to use a deprecated
command: ant bootstrap. Theoretically, all of its functions are now performed by ant deploy.

As you might expect, all of these commands must be executed as the jboss user. If this is not done, you'll likely see these errors
upon service start or deployment:

06:31:45,480 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (MSC service thread 1­4) JSF1051:
Service entry 'org.jboss.as.web.deployment.jsf.JsfInjectionProvider' does not extend DiscoverableInjectionProvider.
Entry will be ignored.

06:31:43,811 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report 
JBAS014777:   Services which failed to start: service jboss.web.connector.httpspub:
org.jboss.msc.service.StartException in service jboss.web.connector.httpspub:  
JBAS018007: Error starting web connector service jboss.web.connector.httpspriv: org.jboss.msc.service.StartException
in service jboss.web.connector.httpspriv:  
JBAS018007: Error starting web connector

Assuming that we are not seeing these (or any other) errors, we can proceed with our installation. It is a good idea to restart
jboss, then perform the install. This avoids out‐of‐memory errors that jboss can occasionally throw.

If you do happen to lock up jboss with an out‐of‐memory condition, just "kill ­9" the jboss process and do a service
ejbca restart. You should then be able to perform your ant command successfully.
If this does not resolve the errors, try the new ant commands given above.

Run the following:

service ejbca restart
cd /opt/ejbca
sudo ­u jboss ant install

The Initial Keystores

I've mentioned the keystore files several times, but haven't fully described what they are. The keystores hold the certificates used
by ejbca to secure its web portal, nothing more. Their prominence during installation makes them seem very important, but they
have little relevance to the actual "Certificate Authority" functions of ejbca.
They are not used to store keys and certificates generated by ejbca once the application is in production ‐ that
information is (usually) held in the database.
In a distributed installation, they have an important role in cross‐server authentication.

When the install script runs, it will perform various operations until it must prompt you for the passwords to be used for your
keystore files. Again, the keystore files are located in /opt/ejbca/p12, and are:

tomcat.jks ‐ Holds the actual certificate (and its signing chain) used by jboss to secure the ejbca web portals with
TLS.
truststore.jks ‐ Stores a copy of the root CA key that issued the TLS certificate (initially this is the management
CA).

After creation, these files are copied by the install script to /opt/jboss/standalone/configuration/keystore, and
tomcat.jks is renamed keystore.jks in the new directory.

It is critical to understand that while ant creates the keystores in /opt/ejbca/p12, jboss uses the keystores in the
/opt/jboss/standalone/configuration/keystore directory for TLS.

The superadmin.p12 file that contains the client certificate used to authenticate the default administrator account
is also located in /opt/ejbca/p12. It is not copied to the jboss directory with the other keystores.

The java tool used to manage the keystores is called keytool, and (in our installation) is called by a link in /usr/bin/. Through
alternatives, this link points to /usr/lib/jvm/jre­1.6.0­openjdk.x86_64/bin/keytool. This tool seems to be the
primary source of my problems with Elliptic Curve support ‐ the 1.6 version isn't fully‐functioned for EC algorithms, and ejbca isn't
smart enough to parse EC keystore requests and prevent unsupported ones from being passed to the tool. The easiest way to deal
with this problem is to simply use RSA encryption for our keystores, as I have done in the examples.

Note that keytool is only used to manage keystore files. The targets used by ejbca to respond to certificate requests
will be able to generate EC certificates just fine.
Also note that the ejbca configuration files for the keystores refer to EC support in various places. You are welcome to
play with your setup to try and find a working EC config, but I will not discuss this further.

As mentioned, ant install generates the initial copies of the keystores based on the configuration in install.properties
and web.properties. Depending on how thoroughly you configured these files, ant install may prompt you for a good deal
of information required to create the initial certificates. But if you have stayed close to the examples, you should only be
prompted for the three passwords that will be used to authenticate the keystores:

Please enter the password of the truststore with the CA certificate for https? [changeit]   
 
Please enter the password of the keystore with the TLS key for https [serverpwd]

(and later)

Please enter the superadmin password (default: ejbca) ? [ejbca]

To clarify what each password is for:

The "truststore with the CA certificate for https" is the truststore.jks file.
The "keystore with the TLS key for https" is the tomcat.jks file.
The "superadmin password" is the password for the superadmin.p12 file.

You can include these passwords in the .properties files, and not be prompted for them. However, my personal feeling is that
you should never have passwords stored in clear text.

Unfortunately, ejbca keeps clear copies of the keystore passwords in standalone.xml.

Ideally, ejbca would only store these passwords in hashed form, but there is nothing we can do about this at the moment, short of
rewriting the install script.
While keystore creation is taking place, ant install will return messages like these:

 [echo] Initializing CA with 'mgmtCA' 'CN=mgmtca,O=Your Company,C=US' 'soft' <ca.tokenpassword hidden> '4096' 'RSA'
'3650' 'null' 'SHA384withRSA' /home/ejbca/conf/catoken.properties  ­superadmincn 'SuperAdmin'...

After this, you will see another summary stanza describing the management CA being created:

     [echo] 
     [echo] ­­­­­­­­­­­­­­­­­­­ CA Properties ­­­­­­­­­­­­­­­­
     [echo] ca.name                : mgmtca
     [echo] ca.dn                  : CN=mgmtca,O=Your Company,C=US
     [echo] ca.tokentype           : soft
     [echo] ca.keytype             : RSA
     [echo] ca.keyspec             : 4096
     [echo] ca.signaturealgorithm  : SHA256WithRSA
     [echo] ca.validity            : 3650
     [echo] ca.policy              : null
     [echo] ca.tokenproperties     : /opt/ejbca/conf/catoken.properties
     [echo] httpsserver.hostname   : rootca.yourcompany.net
     [echo] httpsserver.dn         : CN=rootca.yourcompany.net,O=Your Company,C=US
     [echo] superadmin.cn          : superadmin
     [echo] superadmin.dn          : CN=superadmin,O=Your Company,C=US
     [echo] superadmin.batch       : true
     [echo] appserver.home         : /opt/jboss
     [echo]         

If the keystore creation fails due to an invalid encryption configuration (like trying to use EC), ant install will return a message
like:

 [java] org.ejbca.ui.cli.ErrorAdminCommandException: org.cesecore.certificates.ca.InvalidAlgorithmException:
Signature algorithm SHA384withRSA is not one of the allowed signature algorithms. Available algorithms:
{SHA1WithRSA,SHA256WithRSA,SHA384WithRSA,SHA512WithRSA,SHA256WithRSAAndMGF1,
SHA1withECDSA,SHA224withECDSA,SHA256withECDSA,SHA384withECDSA,SHA1WithDSA,
GOST3411withECGOST3410,GOST3411withDSTU4145}.

and the console log will include messages like:

06:21:15,184 ERROR [org.apache.tomcat.util.net.jsse.JSSESocketFactory] (MSC service thread 1­2) Failed to load
keystore type JKS with path /opt/jboss/standalone/configuration/keystore/keystore.jks due to
/opt/jboss/standalone/configuration/keystore/keystore.jks (No such file or directory):
java.io.FileNotFoundException: /opt/jboss/standalone/configuration/keystore/keystore.jks (No such file or directory) 

06:21:15,188 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1­2) Error initializing endpoint:
java.io.FileNotFoundException: /opt/jboss/standalone/configuration/keystore/keystore.jks (No such file or directory)

Troubleshooting keystore creation boils down to interpreting the errors in both ant output and the console log. But problems
usually stem from the keytool command syntax that ant install puts together. You can infer this syntax from the messages
given in the ant console output.

Finalizing the Installation

Aside from keystore creation, the install script also does the following:
Builds the actual management CA instance in the database
Updates standalone.xml with keystore, web session, and security information.

In the log file, you will see many new messages, primarily relating to encryption functions for the keystore files. But the best way
to get a feeling for how your installation is proceeding is to look for the following messages spread through the output:

06:20:59,482 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context:
/${app.name}/publicweb/status 
06:20:59,484 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context:
/ejbca/publicweb/apply 
06:20:59,491 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context:
/ejbca/publicweb/webdist 
06:20:59,506 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context: /ejbca/publicweb 
06:20:59,516 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context:
/ejbca/publicweb/healthcheck 
06:20:59,521 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context: /ejbca/clearcache 
06:20:59,521 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context: /ejbca/ejbcaws 
06:20:59,571 INFO  [org.jboss.web] (MSC service thread 1­4) JBAS018210: Registering web context: /ejbca 
06:20:59,727 INFO  [org.jboss.web] (MSC service thread 1­1) JBAS018210: Registering web context: /crls 
06:20:59,728 INFO  [org.jboss.web] (MSC service thread 1­2) JBAS018210: Registering web context: /certificates 
06:21:00,141 INFO  [org.jboss.web] (MSC service thread 1­3) JBAS018210: Registering web context: /ejbca/adminweb 
06:21:16,576 INFO  [org.jboss.web] (MSC service thread 1­1) JBAS018210: Registering web context: /ejbca/doc 

WSDL published to: file:/opt/jboss­as­7.1.1.Final/standalone/data/wsdl/ejbca.ear/ejbca­ws­
ejb.jar/EjbcaWSService.wsdl

If you see these contexts being successfully registered, you can feel assured that the various functions of ejbca are being
successfully built. But note that most of these contexts are dynamic in nature, and usually cannot be browsed to check their
function ‐ you must create your own CAs first. Also, some services, like the healthcheck, are only available from localhost (as
shown in the properties files).

The installation will likely end with an error message that will go away once we manually perform a deployment (although ant will
report the installation as "BUILD SUCCESSFUL"):

06:31:43,812 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with
errors) in 162ms ­ Started 135 of 218 services (2 services failed or missing dependencies, 80 services are passive
or on­demand)

Recovering from a Failed Install

Chances are that you will discover mistakes after your first installation attempt. If you did not (or could not) make a vm snapshot
immediately prior to running ant install, all hope is not lost! Perform these steps, and verify that you no longer receive
unexpected errors in your console log before proceeding. If you just can't shake weird errors in the log, you really have no other
choice than to completely start over.

service ejbca stop
mysql ­u root ­p

drop database ejbcadb;
create database ejbcadb;
exit

rm /opt/ejbca/p12/tomcat.jks
rm /opt/ejbca/p12/truststore.jks
rm /opt/ejbca/p12/superadmin.p12 
rm /opt/jboss/standalone/configuration/keystore/keystore.jks
rm /opt/jboss/standalone/configuration/keystore/truststore.jks
vi /opt/jboss/standalone/configuration/standalone.xml

### Start standalone.xml Delta ###

Remove:

 <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" redirect­port="8443"/> 
            <connector name="httpspriv" protocol="HTTP/1.1" scheme="https" socket­binding="httpspriv" secure="true"> 
                <ssl key­alias="rootca.yourcompany.net" password="blah blah blah" certificate­key­
file="/opt/jboss/standalone/configuration/keystore/keystore.jks" verify­client="true" ca­certificate­
file="/opt/jboss/standalone/configuration/keystore/truststore.jks" ca­certificate­password="blah blah blah"/> 
            </connector> 
            <connector name="httpspub" protocol="HTTP/1.1" scheme="https" socket­binding="httpspub" secure="true"> 
                <ssl key­alias="rootca.yourcompany.net" password="blah blah blah" certificate­key­
file="/opt/jboss/standalone/configuration/keystore/keystore.jks"/> 
            </connector> 
            <virtual­server name="default­host" enable­welcome­root="true"> 
                <alias name="localhost"/> 
                <alias name="example.com"/> 
            </virtual­server> 
        </subsystem>

### End standalone.xml Delta ###

service ejbca start
sudo ­u jboss ant clean 
sudo ­u jboss ant deploy
sudo ­u jboss ant install

Checking the Keystores

Regardless of whether or not we had problems with their creation, it is quite important to check the contents of the keystore files
prior to continuing with the build. This ensures not only that the contents are correct, but also that the passwords associated with
the files are the ones we expect. We will check both the ejbca and the jboss copies:

cd /opt/ejbca/p12
keytool ­list ­v ­keystore tomcat.jks
keytool ­list ­v ­keystore truststore.jks

cd /opt/jboss/standalone/configuration/keystore
keytool ­list ­v ­keystore keystore.jks
keytool ­list ­v ­keystore truststore.jks

Again, the contents of tomcat.jks/keystore.jks should initially be:

The root CA certificate used to identify your management CA.

The TLS certificate for your server, which will be issued to the FQDN of your server.
An additional copy of the management CA certificate chained to the TLS certificate as the signing authority.

A "key" thing to note regarding keytool: when running the list commands above, you may notice that the keys will be successfully
listed regardless of the password (or lack of one) that you enter. However, you will see the following stanza at the top of the list
output:

*****************  WARNING WARNING WARNING  ***************** 
* The integrity of the information stored in your keystore  * 
* has NOT been verified!  In order to verify its integrity, * 
* you must provide your keystore password.                  * 
*****************  WARNING WARNING WARNING  *****************

This functionality is by design. Ejbca, for its part, takes the passwords that are entered during installation and uses them as the
authentication codes for the keystores, storing them in the standalone.xml stanzas mentioned in the previous section.

If jboss cannot validate the keystores with the passwords stored in standalone.xml at start time, the service will eventually
start, but will fail to start ejbca.ear, and will report the following message in the console log:

20:45:43,566 ERROR [org.apache.tomcat.util.net.jsse.JSSESocketFactory] (MSC service thread 1­4) Failed to load
keystore type JKS with path /opt/jboss/standalone/configuration/keystore/keystore.jks due to Keystore was tampered
with, or password was incorrect: java.io.IOException: Keystore was tampered with, or password was incorrect

Returning to our own tests of the keystores, the output of a list operation (with the proper password) will look something like this
(some of the extensions are omitted for brevity):

### Start keystore.jks ###

Keystore type: JKS 
Keystore provider: SUN 

Your keystore contains 2 entriesAlias name: cacert 
Creation date: Apr 26, 2014 
Entry type: trustedCertEntry 

Owner: C=US, O=Your Company, CN=mgmtca 
Issuer: C=US, O=Your Company, CN=mgmtca 
Serial number: 1e1369e62435a307 
Valid from: Sat Apr 26 06:20:16 GMT­08:00 2014 until: Tue Apr 23 06:20:16 GMT­08:00 2024 
Certificate fingerprints: 
     MD5:  CB:04:B3:2A:5A:AA:AA:AA:54:BB:C1:3E:72:A2:F1:62 
     SHA1: 07:89:0F:48:97:35:FF:AA:B5:69:35:97:69:8B:B1:40:D8:2A:02:2A 
     Signature algorithm name: SHA256withRSA 
     Version: 3 

Extensions:  

#1: ObjectId: 2.5.29.15 Criticality=true 
KeyUsage [
  DigitalSignature 
  Key_CertSign 
  Crl_Sign
] 

...

] 

******************************************* 
******************************************* 

Alias name: rootca.yourcompany.net 
Creation date: Apr 26, 2014 
Entry type: PrivateKeyEntry 
Certificate chain length: 2 
Certificate[1]: 
Owner: C=US, O=Your Company, CN=rootca.yourcompany.net 
Issuer: C=US, O=Your Company, CN=mgmtca 
Serial number: 5a797a3381345da2 
Valid from: Sat Apr 26 06:10:21 GMT­08:00 2014 until: Mon Apr 25 06:10:21 GMT­08:00 2016 
Certificate fingerprints: 
     MD5:  AF:C1:26:10:24:9D:FE:08:45:F0:45:CA:57:33:BB:FE 
     SHA1: 11:5F:8F:A2:AC:E6:D2:3C:1E:CC:6A:A8:3B:9F:57:8D:4E:D6:59:3C 
     Signature algorithm name: SHA256withRSA 
     Version: 3 

Extensions:  

#1: ObjectId: 2.5.29.15 Criticality=true 
KeyUsage [
  DigitalSignature 
  Key_Encipherment 
] 

... 

] 

Certificate[2]: 
Owner: C=US, O=Your Company, CN=MgmtCA 
Issuer: C=US, O=Your Company, CN=MgmtCA 
Serial number: 1e1369ef834ea307 
Valid from: Sat Apr 26 06:20:16 GMT­08:00 2014 until: Tue Apr 23 06:20:16 GMT­08:00 2024 
Certificate fingerprints: 
     MD5:  CB:04:B3:2A:5A:7B:40:72:54:BB:C1:3E:72:A2:F1:62 
     SHA1: 07:89:0F:48:97:35:FF:AA:B5:69:35:97:69:8B:B1:40:D8:2A:02:2A 
     Signature algorithm name: SHA256withRSA 
     Version: 3 

Extensions:  

#1: ObjectId: 2.5.29.15 Criticality=true 
KeyUsage [
  DigitalSignature 
  Key_CertSign 
  Crl_Sign
] 

... 

] 

******************************************* 
*******************************************

### End keystore.jks ###

The truststore.jks file contains the keys of all authorities trusted by jboss, which initially is only the management CA:

### Start truststore.jks ###

Keystore type: JKS 
Keystore provider: SUN 

Your keystore contains 1 entry 

Alias name: mgmtca 
Creation date: Apr 26, 2014 
Entry type: trustedCertEntry 

Owner: C=US, O=Your Company, CN=mgmtca 
Issuer: C=US, O=Your Company, CN=mgmtca 
Serial number: 1e1369ef834ea307 
Valid from: Sat Apr 26 06:20:16 GMT­08:00 2014 until: Tue Apr 23 06:20:16 GMT­08:00 2024 
Certificate fingerprints: 
     MD5:  CB:04:B3:2A:5A:7B:40:72:54:BB:C1:3E:72:A2:F1:62 
     SHA1: 07:89:0F:48:97:35:FF:AA:B5:69:35:97:69:8B:B1:40:D8:2A:02:2A 
     Signature algorithm name: SHA256withRSA 
     Version: 3 

Extensions:  

#1: ObjectId: 2.5.29.15 Criticality=true 
KeyUsage [
  DigitalSignature 
  Key_CertSign 
  Crl_Sign
] 

... 

] 

******************************************* 
*******************************************

### End truststore.jks ###

If your outputs vary wildly from what is shown above, you will need to go back and revalidate your properties files, then reinstall
your server. This is where vm snapshots become very handy.

Production Deployment and Test

Now we can perform our first true deployment that should give us a functional ejbca server:

sudo ­u jboss ant deploy

It's a good idea to restart jboss a few times following this step, to make sure that ejbca restarts successfully:

service ejbca restart
service ejbca restart
service ejbca restart 

Assuming there are no errors, the ejbca web portals are now active. There are a few of them:
http://rootca.yourcompany.net ‐ This is the unencrypted default webpage for Jboss. It refers to an
"Administration Console", which is only available to localhost and uses the jadmin account we created earlier.
Otherwise, it doesn't interact with ejbca.
http://rootca.yourcompany.net/ejbca ‐ This is the public ejbca webpage. The primary functions of ejbca are
accessed from here.
https://rootca.yourcompany.net/ejbca ‐ This is the encrypted version of the page above. At present, you must
have the superadmin.p12 certificate installed in your browser to reach this page, but we will change this once ejbca
is fully functional.
http://rootca.yourcompany.net/ejbca/adminweb ‐ This is the primary administration webpage for ejbca.
Nearly all of our production configuration is performed from this page. It requires the superadmin.p12 certificate as
well.

It is a good idea to test access to each of these pages individually, using a fresh browser session each time. But we need to open
an scp session to our server and retrieve the superadmin.p12 certificate before we can access the ejbca administration
webpage.

The superadmin certificate only grants our browser the ability to log in to the administration interface of the ejbca
application‐ not the jboss web console.

In Firefox, the superadmin certificate is installed by opening:

Tools ==> Options ==> Advanced ==> Certificates ==> View Certificates

and selecting "Import" from the "Your Certificates" tab. You will need to enter the superadmin password you entered during ant
install to decrypt the file.

Once we have installed superadmin.p12, we can browse to:

https://rootca.yourcompany.net/ejbca/adminweb

and arrive at the administration webpage after being prompted for the certificate.

Adding the Validation Authority

Now that we are reasonably sure that the management CA is functional, we can add validation functions to our server. Primekey
refers to the processes that perform certificate validation (CMP, OCSP, CRL distribution) as being the "Validation Authority". It is
important to note that you can legitimately have a CA without validation ability, and skip this entire section of the how‐to. But
certificate validation is a core function of PKI, so I suggest you add it now.

Referring back to our ASCII logical layout diagram:

mysql ­­> java­sql­connector ­­> jboss ­­> ejbca CA ­­> ejbca VA ­­> OCSP
                   ^               ^ 
                   |               |
                   ­­­­­­ java ­­­­­
What this diagram does not show is that the Validation Authority has its own Jboss datasource that is discrete from the one used
by the Certificate Authority. However, in our standalone environment, this connection is to the same database (ejbcadb) that the
Certificate Authority uses.

Defining the VA's datasource is the purpose of the va­publisher.properties file.

Like the CA datasource, the VA datasource configuration will be added to standalone.xml during deployment (once
the VA‐specific .properties files are created).
It is worth noting how Primekey uses the term "publisher". It describes the notion of a particular ejbca component
"publishing" information (from a datasource) to a separate server in a distributed ejbca installation.
In our case, our standalone server is only "publishing" to its own Validation Authority service, but we still need the
"publisher" to be defined in va­publisher.properties.
The va.properties file defines general operation of the Validation Authority, such as its healthcheck function.
The ocsp.properties file defines OCSP protocol functionality.
Note that va.properties contains specific instructions on how to enable CRL/OCSP download aliases for multiple CA
instances.

The first step towards enabling the Validation Authority is to create the validation‐related properties files in the
/opt/ejbca/conf directory:

cp sample/ocsp.properties.sample ocsp.properties
cp sample/va.properties.sample va.properties
cp sample/va­publisher.properties.sample va­publisher.properties

Like the examples above, here are files I am using:

ocsp.properties

### Start ocsp.properties ###

# ­­­­­­­­­­­­ OCSP responder configuration ­­­­­­­­­­­­­­­­­­­­­

ocsp.enabled=true
#ocsp.enabled=false

# This is the path for the OCSP URL
ocsp.contextroot=/ejbca/publicweb/status
#ocsp.contextroot=/status

# This is the DN of the CA that will respond to requests for unknown certs
ocsp.defaultresponder=CN=defaultca,O=Your Company,C=US

ocsp.includecertchain=true
ocsp.includesignercert=true
ocsp.responderidtype=keyhash
ocsp.signaturealgorithm=SHA1WithRSA;SHA1WithECDSA;SHA1WithDSA
ocsp.signingCertsValidTime=300
ocsp.warningBeforeExpirationTime=10000

ocsp.nonexistingisgood=false

#ocsp.nonexistingisgood.uri.1=.*/thisEndingIsGood$
#ocsp.nonexistingisgood.uri.2=^http://good.myhost.nu:8080/.*
#ocsp.nonexistingisbad.uri.1=.*/thisEndingIsBad$
#ocsp.nonexistingisbad.uri.2=^http://bad.myhost.nu:8080/.*
ocsp.nonexistingisrevoked=false
#ocsp.nonexistingisrevoked.uri.1=.*/thisEndingIsRevoked$
#ocsp.nonexistingisrevoked.uri.2=^http://revoked.myhost.nu:8080/.*

ocsp.expiredcert.retentionperiod = 31536000
#ocsp.expiredcert.retentionperiod = ­1

ocsp.untilNextUpdate = 0
#ocsp.999.untilNextUpdate = 50
ocsp.revoked.untilNextUpdate = 0
#ocsp.999.revoked.untilNextUpdate = 50
ocsp.maxAge = 30
#ocsp.999.maxAge = 100
ocsp.revoked.maxAge = 30
#ocsp.999.revoked.maxAge = 100

#ocsp.extensionoid=
#ocsp.extensionclass=

#ocsp.uniddatsource=
#ocsp.unidtrustdir=
#ocsp.unidcacert=
#ocsp.signaturerequired=false

#ocsp.rekeying.trigging.password=
#ocsp.rekeying.wsurl = https://milton:8443/ejbca/ejbcaws/ejbcaws
#ocsp.rekeying.update.time.in.seconds=
#ocsp.rekeying.safety.margin.in.seconds=
#ocsp.rekeying.trigging.hosts=

# Default: false
ocsp.trx­log = true
ocsp.log­date = yyyy­MM­dd:HH:mm:ss:z
#ocsp.log­timezone = GMT
#ocsp.trx­log­pattern = \\$\\{(.+?)\\}
# The next line will probably line­wrap in your browser:
#ocsp.trx­log­order =
${SESSION_ID};${LOG_ID};${STATUS};${REQ_NAME}"${CLIENT_IP}";"${SIGN_ISSUER_NAME_DN}";"${SIGN_SUBJECT_NAME}";${SIGN_S
ERIAL_NO};"${LOG_TIME}";${REPLY_TIME};${PROCESS_TIME};${NUM_CERT_ID};0;0;0;0;0;0;0;"${ISSUER_NAME_DN}";${ISSUER_NAME
_HASH};${ISSUER_KEY};${DIGEST_ALGOR};${SERIAL_NOHEX};${CERT_STATUS}

ocsp.audit­log = true
#ocsp.audit­log­pattern = \\$\\{(.+?)\\}
# The next line will probably line­wrap in your browser:
#ocsp.audit­log­order = SESSION_ID:${SESSION_ID};LOG ID:${LOG_ID};"${LOG_TIME}";REPLY TIME:${REPLY_TIME};\nTIME TO
PROCESS:${PROCESS_TIME};\nOCSP REQUEST:\n"${OCSPREQUEST}";\nOCSP RESPONSE:\n"${OCSPRESPONSE}";\nSTATUS:${STATUS}
#ocsp.log­safer = true

### End ocsp.properties ###

va.properties

### Start va.properties ###

#­­­­­­­­­­­­­­­­­­­ Validation Authority (VA) Healthcheck settings ­­­­­­­­­­­­­
ocsphealthcheck.signtest=true
ocsphealthcheck.checkSigningCertificateValidity=true

# PrimeKey's instructions here are particularly terrible. Let me see if I can translate:

# In this last setting, we will define an alias 'root' for a particular RFC 4985 Section 2.1 "Search Key ID Hash" or
"sKIDHash"
# Our example sKIDHash is:'O4RdnGNf3WPioslAQsX71aR1/MI'
# sKIDHashes are unique to each CA instance that you run on your ejbca server.

# This has the effect of making the following URLs equivalent. This simplifies the entries in your certificates that
specify
# CRL/OCSP download locations, and grants the ability to have simultaneous CRL/OCSP download URLs
# Typically, you will define a unique sKIDHash alias for each of your CA instances.

# Example URL for certificate search: http://myhost.com:8080/certificates/search.cgi?
sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI
# This will be the same as http://myhost.com:8080/certificates/search.cgi?alias=root

# Example URL for CRL download: http://myhost.com:8080/crls/search.cgi?sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI
# is the same as http://myhost.com:8080/crls/search.cgi?alias=root
# Example URL for Delta CRL download: http://myhost.com:8080/crls/search.cgi?
sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI&delta=
# is the same as http://myhost.com:8080/crls/search.cgi?alias=root&delta=

# To determine the hash to use here, navigate to http://yourhost.com:8080/crls/search.cgi or
http://yourhost.com:8080/certificates/search.cgi
# (Omit the :8080 if you are browsing from somewhere other than localhost)
# This URL will give you a list of the unique validation identifiers (including the sKIDHash) for each of your
defined CAs.

# Copy the sKIDHashes for the CA instances. Remember, you will have more than one, and you can omit the Management
CA as it is solely internal to ejbca.
# Add an entry like the one below for each of your CAs, paste the sKIDHash into the entry, then redeploy ejbca.

#va.sKIDHash.alias.root=O4RdnGNf3WPioslAQsX71aR1/MI

### End va.properties ###

va‐publisher.properties

### Start va­publisher.properties ###

#­­­­­­­­­­­­­­ Validation Authority(VA) publisher db configuration­­­­­­­­­­­­­­­­­­­­­­­­­
# All the "ocsp­database.*" properties are used to configure the VA connection to the database.
#
# In "PrimeKeyese": Configure these options if you are configuring EJBCA that will publish 
# certificates to a VA.

ocsp­datasource.jndi­name=OcspDS
ocsp­database.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF­8
ocsp­database.driver=com.mysql.jdbc.Driver
ocsp­database.username=ejbcadbuser

# Set your database user password here
ocsp­database.password=pumpkin

### End va­publisher.properties ###

To enable the VA, we perform the same set of commands we ran before our initial deployment:

service ejbca stop
chown ­R jboss:jboss /opt/jboss­as­7.1.1.Final
chown ­R jboss:jboss /opt/ejbca_ce_6_1_1
service ejbca start
cd /opt/ejbca
sudo ­u jboss ant deploy

Note that in ocsp.properties, we define the "ocsp.defaultresponder". This is the DN of the CA that will answer OCSP
requests for unknown CAs. Primekey recommends that you use the management CA for this, but I think that's a poor idea. I use an
empty "default" CA solely for this purpose.

This brings the total number of certificate authorities in our initial installation to three:
mgmtca
rootca.yourcompany.net
defaultca

We will create the defaultca near the end of the how‐to. For now, just remember this entry in ocsp.properties.
Until the defaultca is created, you will repetitively see the following message in the console log:

06:06:13,379 INFO  [org.cesecore.certificates.ocsp.cache.OcspSigningCache] (MSC service thread 1­4) Default OCSP
responder with subject 'CN=defaultca' was not found. OCSP requests for certificates issued by unknown CAs will fail
with response code 2 (internal error). 

Lastly, if for whatever reason you have problems with your va­publisher.properties file, you may see the following warning:
06:31:45,632 WARN  [org.ejbca.core.protocol.certificatestore.CertificateCache] (MSC service thread 1­2)
org.bouncycastle.ocsp.OCSPException: problem creating ID: java.security.NoSuchProviderException: no such provider:
BC

"BC" is the default bouncycastle (the OCSP java module) instance name.

This is another good point to take a vm snapshot.

I really like the name "bouncycastle".

Building the Initial Production CA

Administration Overview
We are now at the point where we create our first CA. This is accomplished via the web admin interface:

Administration Homepage

Before we start configuring, here is a brief description of the interface:

CA Functions ‐ This section is to configure the Certificate Authority functions of ejbca.

RA Functions ‐ This section is to configure the Registration Authority functions of ejbca.
Supervisor Functions ‐ This section is to view ejbca logs and approve requests.
System Functions ‐ This section has some validation functions, some administration functions, and general
preferences/configuration.

Here, we revisit the idea of the "Registration Authority". In ejbca, the RA is functionality that manages requests for new
certificates. It regulates the user accounts associated with each CA and the types of certificates a user is allowed to request. It
also answers queries about certificates that have already been issued, although this function is distinct from the Validation
Authority.

In terms of our build, it was installed with the core CA functions, and is not configured separately. However, the RA can be
distributed to a separate ejbca installation used only for registration.
CA Creation Workflow

We will assume that most of the certificates to be issued by our CA will be for standard HTTPS connections using TLS, so the
example configuration will be geared towards this purpose. By the time we finish, we should have a certificate that we can install
on any standard Apache server.

It is useful to have a written workflow for creating CAs in ejbca, as you can have different CAs for different purposes, each
configured differently. Here is the flow we will follow:

1. Create a Certificate Profile ‐ Defines set of certificate values to be used as a template

2. Create an End Entity Profile ‐ Essentially the same as a user template
3. Create the Certificate Authority ‐ Creating the actual Certificate Authority

Once these steps are complete, we will create an End Entity and issue it a certificate.

We could create the Certificate Authority first, but I specifically use this order to illustrate a few concepts:

You should know the algorithms and key lengths you will use before creating your CA. Most applications of PKI only
support a limited number of possible algorithm/signature combinations.
You should know the certificate details (extensions) you will use, as well.

Defining the Certificate Profile and End Entity Profile first forces you to have these details defined before committing to CA
creation.

Deciding on an Algorithm

Choosing a public key encryption algorithm is a "touchy subject" for people lately, with opinions usually boiling down to either:
"The NSA is an essential tool of the forces of good to gather realtime intelligence on the actions of evildoers."
or:
"The NSA is an essential tool of the forces of evil to steal secrets and destroy the privacy of the good people of the
world."

Regardless of where you fall on the political spectrum, our choice of public key encryption algorithm is limited to either RSA or
Elliptic Curve DSA. With RSA, the only variable is the length of your key modulus, with current options being 2048, 4096, and 8192
bits.

With ECDSA, you have a dizzying number of variants to choose from. I summarize a few of them here, with thanks to the SECG and
Fabio Pietrosanti.

Focusing first on the SECG convention on ECDSA curve naming:

"sec" simply denotes the specification name: "Standards for Efficient Cryptography".
"p" or "t" refer to two variants of the elliptic curve algorithm. The "p" stands for "prime".
The next three numbers refer to the length (in bits) of the modulus of the curve.
"r" or "k" refers to the family of curves used by the equation ‐ "Random" or "Koblitz".
The last number refers to a "sequence number", referring to yet another mathematical variant.

The table column titles stand for:

SECG NAME ‐ SECG "nickname" of the elliptic curve variant
SIZE ‐ length in bits of the field order
RSA EQ ‐ approximate size of an RSA modulus at comparable strength.
CURVE ‐ indicates whether the curve is Koblitz or random
NIST ‐ name of the equivalent NIST standard for the curve

+­­­­­­­­­­­+­­­­­­+­­­­­­­­+­­­­­­­­­+­­­­­­­+ 
| SECG NAME | SIZE | RSA EQ |  CURVE  | NIST  | 
+­­­­­­­­­­­+­­­­­­+­­­­­­­­+­­­­­­­­­+­­­­­­­+ 
| sect163k1 | 163  |        | Koblitz | K­163 | 
| sect163r1 | 163  |        | Random  |       | 
| sect163r2 | 163  |        | Random  | B­163 | 
| sect193r1 | 193  |        | Random  |       | 
| sect193r2 | 193  |        | Random  |       | 
| sect233k1 | 233  |        | Koblitz | K­233 | 
| sect233r1 | 233  |        | Random  | B­233 | 
| sect239k1 | 239  |        | Koblitz |       | 
| sect283k1 | 283  |        | Koblitz | K­283 | 
| sect283r1 | 283  |        | Random  | B­283 | 
| sect409k1 | 409  |        | Koblitz | K­409 | 
| sect409r1 | 409  |        | Random  | B­409 | 
| sect571k1 | 571  |        | Koblitz | K­571 | 
| sect571r1 | 571  |        | Random  | B­571 | 
| secp160k1 | 160  |  1024  | Koblitz |       | 
| secp160r1 | 160  |  1024  | Random  |       | 
| secp160r2 | 160  |  1024  | Random  |       | 
| secp192k1 | 192  |  1536  | Koblitz |       | 
| secp192r1 | 192  |  1536  | Random  | P­192 | 
| secp224k1 | 224  |  2048  | Koblitz |       | 
| secp224r1 | 224  |  2048  | Random  | P­224 | 
| secp256k1 | 256  |  3072  | Koblitz |       | 
| secp256r1 | 256  |  3072  | Random  | P­256 | 
| secp384r1 | 384  |  7680  | Random  | P­384 | 
| secp521r1 | 521  | 15360  | Random  | P­521 | 
+­­­­­­­­­­­+­­­­­­+­­­­­­­­+­­­­­­­­­+­­­­­­­+

It is worthwhile to compare the equivalent strength of Koblitz and Random (ECC) curves when tested more rigorously:

(in bits)

+­­­­­­­­­+­­­­­­­+­­­­­­­­­­­­­­+ 
| Koblitz |  ECC  |  DH/DSA/RSA  | 
+­­­­­­­­­+­­­­­­­+­­­­­­­­­­­­­­+ 
|   163   |  192  |     1024     | 
|   283   |  256  |     3072     | 
|   409   |  384  |     7680     | 
|   571   |  521  |    15360     | 
+­­­­­­­­­+­­­­­­­+­­­­­­­­­­­­­­+

My takeaway from the information in these tables is:

Elliptic Curve equations are far more efficient than the RSA equations.
Elliptic Curve equations using Koblitz curves are slightly (10% or so) less efficient than those using "random" curves.
When choosing an EC equation, it is a good idea to choose a variant that is supported by multiple organizations (SECG,
NIST, etc) for compatibility purposes.
Currently, the best supported variant is prime256v1 (aka secp256r1, NIST P‐256)

Extremely briefly, most worries about Elliptic Curve center on the nature of the "random" curves, and whether or not they are
truly "random". If you are worried about the NSA having a "backdoor" in EC, my suggestion is to use a Koblitz curve variant, like
Bitcoin does. However, this will cost you about 10% of your efficiency, and Koblitz‐based algorithms are not as widely accepted as
those based on the "random" curves.

Ultimately, there is no guarantee that the NSA won't be able to break your encryption regardless of the algorithm you
choose.

As of now, the world is moving towards Elliptic Curve cryptography. Once ejbca gets its implementation straight, it will be the
best algorithm to use for your CAs and certificates.

My opinion is that for interoperability reasons, you're best off using the de facto standard for TLS on the Internet: 2048‐
bit RSA, but with a SHA‐256 key.
When creating a Certificate Authority in ejbca, 2048‐bit RSA is the default algorithm.
Defining the Certificate Fields

The X.509 specification allows a dizzying number of potential information fields to be included in a certificate. Thankfully, most of
these fields are ignored by the average PKI implementation.

To illustrate this, I downloaded a certificate used by Google to secure Gmail, and viewed its properties using the Firefox
certificate viewer:

Gmail TLS Certificate

In the Firefox viewer, the full set of included fields can be viewed in the "Details" tab:

Gmail Certificate Details

Google uses the following fields in this certificate:

Version: 3
Serial Number: 07:29:38:9A:3E:F9:9C:B1
Certificate Signature Algorithm: SHA‐1 with RSA
Issuer: CN=Google Internet Authority G2,O=Google Inc, C=US
Validity: Not After 7‐21‐2014
Subject: (the DN) CN=mail.google.com, O=Google Inc, L=Mountain View, ST=California,C=US
Algorithm Identifier: Elliptic Curve Public Key
Algorithm Parameters: ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P‐256)
 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication
Certificate Subject Alt Name: DNS Name=mail.google.com
Certificate Key Usage: Signing
Authority Information Access: 
CA Issuers: URI: http://pki.google.com/GIAG2.crt
OCSP: URI http://clients1.google.com/ocsp
Certificate Subject Key ID: (160 bit number)
Certificate Basic Constraints: Is not a Certificate Authority
Certificate Authority Identifier: (160 bit number)
Certificate Policies: 1.3.6.1.4.1.11129.2.5.1
CRL Distribution Points: URI: http://pki.google.com/GIAG2.crl
Certificate Signature Value: (2048‐bit number)

This set of fields is a good starting point when defining what your own certificates will contain.

It is EXTREMELY important to note that many of the parameters above can be set with something called a "Critical Flag". Generally
speaking, on certificates used for web TLS functionality the Critical Flag is ONLY set for the "Basic Certificate Constraints" field.

Do not set the Critical Flag on all parameters in your certificates, or they will not work.

By way of comparison, here is the certificate for the Root CA that validates Gmail's certificate:

Geotrust Root CA Certificate

The Root CA uses fewer fields than the Gmail certificate, and uses 2048‐bit RSA encryption:

Version: 3
Serial Number: 02:34:56 (this is not a typo)
Certificate Signature Algorithm: SHA‐1 with RSA
Issuer: CN=GeoTrust Global CA, O=GeoTrust, Inc.,C=US
Validity: Not After 5/20/2022
Subject: CN=GeoTrust Global CA,O=GeoTrust, Inc.,C=US
Subject Public Key Algorithm: RSA Encryption
Subject's Public Key: (2048‐bit number)
Certificate Basic Constraints: Is a Certificate Authority, Unlimited Intermediate CAs
Certificate Subject Key ID: (160‐bit number)
Certificate Authority Key ID: (the same 160‐bit number)
Certificate Signature Value: (2048‐bit number)

These certificates will be used as templates for defining the fields in our initial Profiles, CAs, and certificates.

Creating A Certificate Profile

Ejbca uses Certificate Profiles to store commonly used sets of certificate extension field data. It is mandatory to use a Certificate
Profile when creating a certificate. By default, ejbca has five predefined Profiles that contain minimal information, and cannot be
altered or deleted.

Certificate Profiles Page

In this example, I am creating a new Profile named "Default TLS Certificate Profile", basing it on the default "SERVER" Profile. As
you might guess, the SERVER Profile is intended to issue certificates to servers supporting TLS.

Below are the field data I used in the Profile. Note that some fields were pre‐populated with data from the SERVER Profile:

Available Bit Lengths: 192, 256, 384, 512, 2048, 4096, 8192
When a certificate is requested using this Profile, only requests using algorithms with these key lengths will be fulfilled. Ejbca
does not differentiate between algorithm types in this field, so it is a good idea to allow both 192‐512 bit lengths to support EC
requests, and 2048‐8192 lengths for RSA requests.

Signature Algorithm: "Inherit" or "SHA256 with RSA"

All certificates are "signed" by the issuing CA using a particular hash algorithm. While SHA‐1 is still the de‐facto Internet standard
for signing, it is a good idea to migrate to SHA256 or SHA512. Note that choosing RSA or ECDSA in this field does not affect the
primary public key algorithm used in in the issued certificates. However, you should use the appropriate value for the algorithm
you will be using. Choosing "Inherit" in this field causes all certificates issued using this Profile to inherit the signature algorithm of
the issuing CA.

Validity: 3652d
This is the length of time that the certificate will be valid. The "d" stands for "days". This value corresponds to 10 years.

Overrides: Do not allow overrides

You have the option of allowing values specified in a Certificate Signing Request (CSR) to "override" values specified in the Profile.
While there may be good reasons to do this, we will not allow this when using this Profile. This is an important option with
significant ramifications, which we will discuss again later.

Key Usage: Digital Signature, Key encipherment

These values specify the uses that are "allowed" by the certificate. The word "allowed" is misleading in this context, as the Key Use
field cannot prevent the certificate owner from using the certificate for whatever purpose it wishes.

Extended Key Usage: Server Auth, Client Auth

Much like Key Usage, this field is specified in the certificate, but enforcement is up to the application using the certificate.

Subject Alt Name: Enabled

The default naming convention for identifying a certificate owner is the X.500 standard. However, most certificates are used by
devices that use DNS for identification. This field will typically contain the FQDN of the certificate owner if it is a device, or an
email address if the owner is a human being.

Use CRL Distribution Point: Enabled

This option enables a field in the Certificate Profile that will hold a URL/URI to define the network location of a CRL. Enabling this
field means that the CA that will use this Certificate Profile must support Validation Authority functionality, and maintain an up‐
to‐date CRL.
Use CA defined Distribution Point: Enabled
We will inherit the URL defining the location of the CRL from the issuing CA. If this option is not selected, a URL for the CRL must
be defined manually. This could be a "http://" address, or an "ldap://" address. HTTP is the standard for Internet use, while
Microsoft active directory certificates use both HTTP and LDAP. There is an exception to this addressing rule, which will be
discussed later.

FreshestCRL Extension: Disabled

This option enables the use of differential (or "delta") CRLs. CRLs can become quite long, and the use of "delta" CRLs allows subsets
of the full CRL to be distributed. We will not be using this function. If this option is enabled, the same type of address values used
for the primary CRL must be defined as well.

Certificate Policies: Disabled

Certificate Policies are RFC‐defined options used for administrative purposes. We will not use them.

Authority Information Access: Enabled, Use CA defined OCSP locator

This Profile will include information regarding the URI target to use to reach the OCSP service of the issuing CA, but will inherit the
details of this from the issuing CA.

Subset of Subject Alt Name: Restrict to "DNS Name" only

As we will only use the Certificates generated with this demonstration Profile for device‐based TLS, we will only use DNS‐based
Alternative Names.

Available CAs: Any CA

We will allow this Profile to be used by any CA on our ejbca server.

Creating the End Entity Profile

Ejbca requires "End Entities" to be defined before any certificates can be issued. An "End Entity" can be considered equivalent to a
"user account". However, it is important to understand that while certificates are often issued to human beings, most certificates
are issued to devices. Therefore, the more generic term, "End Entity", is used.

"End Entity" accounts are identified using a username, regardless of whether that name is "Jose Manolo Enrique Hernandez‐
Gonzales" or "yourserver.yourcompany.net".

Each End Entity can be issued 1‐5 certificates, but each certificate must be requested by the Entity via the Public Ejbca Webpage
before it is issued.

To simplify the process of creating similar End Entities, "End Entity Profiles" can be used as templates.

End Entity Profiles Page

In this example, I am creating a Profile called "Default TLS Device Entity Profile". This Profile will contain information that is
tuned for use by TLS‐capable devices.
The only predefined End Entity Profile is "EMPTY", which contains no information. While you are forced to choose an End Entity
Profile when creating an End Entity, you always have the option of choosing the "EMPTY" Profile.

Here are the fields I defined in the Profile:

Username: (Leave Blank)

Password: (Leave Blank)

If you want to use the same password for multiple End Entities, you can set it here. On the "Create Certificate from CSR" webpage,
this password is called the "Enrollment Code".

Minimum password strength: 48 (in bits)

This ensures that passwords are at least eight characters long.

End Entity Email: yourcompany.net  (Use, Required and Modifiable)

This entry is intended to contain the email domain name only, without the "@" sign. You will be allowed to enter the user‐specific
portion of the address when creating the Entity.

Subject DN Attributes: CN (Required, Modifiable, but blank)

O (Required, no modify): Your Company
L (Required, no modify):Your City
ST (Required, no modify):Your State
C (Required, no modify): Your Country

Subject Alternative Name: DNS Name: .yourcompany.net

When using this Profile to create an entity, you will complete this entry with the entity's hostname. If the entity will be a person,
you will use the "RFC 822 Name (email address)" for the Subject Alternatve Name instead of the DNS Name.

Default Certifiate Profile: Default TLS Certificate Profile

Default CA: Use "mgmtca" (for now)

Choose the name of your new root CA (in this how‐to: "rootca.yourcompany.net") once it is created.

Available CAs: Set to Any CA

Default Token: User Generated

Available Tokens: All

Number of Allowed Requests: 2

Usually, it is desirable to ensure that only a single Certificate is issued to an End Entity. Here we allow two, in case we make a
mistake in our first certificate request.

Send Notification: Use default and required

Sender: ejbca@yourcompany.net
Notification Recipient: certadmin@yourcompany.net
Notification Events: All
Subject and message: Hey, ejbca did something!

Now add the notification, then save the Profile.

Creating the Certificate Authority

As descibed in the beginning of the how‐to, a Crypto Token is the logical structure that a CA's keys are held in. As we are only
using "soft" Crypto Tokens, you can think of them as being tables in our database.
As you might expect, this fact makes the security of our database a greater concern than it might otherwise be.

We have two options for defining the Crypto Token used by any CA we create:

Make the Crypto Token first, then associate the new CA with it
Or:
Allow ejbca to create the Crypto Token automatically

There is a consequence to allowing ejbca to generate the Crypto Token: it uses a 2048‐bit RSA key in the CA certificate, and does
not give us an option to choose otherwise.
Once a CA certificate is issued, it cannot easily be updated with a new, stronger key. In fact, just assume for now that it can't be
done. So if you wish to use a stronger key for your CA, you should manually create your Crypto Token.
 Creating a Crypto Token is simple enough. First enter the Crypto Token interface:

Crypto Token Page

Then, select "Create New", which will take you to the New Token page:

New Crypto Token Page

The "Authentication Code" is a password used to encrypt the Crypto Token itself. You will need this code when renewing the CA
that uses this Crypto Token. "Auto‐activation" should also be enabled.

The Crypto Token must be populated with a basic set of keys before we can use it:
 Basic CA Keys

 In this example, I have added the essentials:

certSignKey ‐ Used for Certificate signing
defaultKey ‐ Used for everything else
testKey ‐ Used for internal health checks only

In the example, you will see a key named "crlSignKey". This key is deprecated, and is no longer needed. I have also added a key
called "ec256p1Key" for testing purposes, to show that EC keys can be generated and used by a CA with a RSA defaultKey.

When finished, we will see that our Crypto Token is labeled as "Active", but not "Used". Once we associate the Token with a CA,its
state will change to "Used".

 Now that we have keys defined with the desired strength, we can create the new CA.

Certification Authorities Page

Note that on this page, we do not have the option of using an existing CA as a template.
Here are the settings I used for "rootca.yourcompany.net":

Type of CA: X509

This is the standard for Internet communications.

Signing Algorithm: Sha256WithRSA

I chose this algorithm because it is the next step up in complexity from the current standard of SHA‐1.

Crypto Token: YourTokenName

Select the name of the Crypto Token that you created in the previous step.
Below are the names of the keys (from our Crypto Token) to be used for standard purposes:
defaultKey: defaultKey
certSignKey: certSignkey
keyEncryptKey: ‐ Use default key
hardTokenEncrypt: ‐ Use default key
testKey: testKey
Extended Services Key Specification: RSA 2048

Enforce Unique Serial Number: Enabled

As we will (probably) not be generating a huge number of certificates in a lab environment, we assume that we will not run out of
valid serial numbers.

Use Certificate Request History: Enabled

This is essentially "detailed auditing" for requests.

Validity: 3652d
This value is the length of time that the CA's own certificate will be valid.

Subject DN: CN=rootca.yourcompany.net,O=Your Company,C=US

This is the DN that you wish to be included in the CA's own certificate. It includes the CN by default, but it is common to add O
and C values.

Signed by: Self Signed

Because this will be a new Root CA, it will sign its own initial certificate.

Subject Alternative Name: dNSName=rootca.yourcompany.net

As discussed, this is the FQDN of the CA. However, note that in this field, the FQDN must be prefixed by "dNSName=". As far as I
can tell, this is the only area in ejbca where you must specify this prefix. "dNSName" is defined in the RFC4985 specification for
X.509 Subject Alternative Names.

Use Issuing Distribution Point on CRLs: Enabled

This enables a field to hold the URL for retrieval of this CA's CRL in the CA's own certificate.

Generate Default CRL Distribution Point: Generated, but remove ":8080" from the URL, and change the protocol from "http://" to
"https://"
We do this because of our firewall port translation rules, which force all requests to use HTTPS.

Generate Default CRL Issuer: Generated

Do not edit this string. It should be your DN.

CA Defined FreshestCRL Extension: Not Generated

We are not using "Delta CRLs" with our CA, so this field is not included.

CA Issuer URI: Empty

This is an optional field that can be ignored.

Default OCSP Service Locator: Generated, Remove ":8080", and change "http://" to "https://".
We do this because of our firewall port translation rules.

Now, create the CA. If for whatever reason creation fails, just "go back" in your browser, and all of your settings will be preserved.
Correct what was wrong, and try again.

Once our CA is made, we have one final step to take before it is fully functional. We must activate the internal health check on
the CA Activation page:
 CA Activation Page

This is simple enough to do: just check the "HealthCheck" box next to your CA and hit "Apply".

The Health Check process is an automatic check of CA status whereby a HTTPS session is periodically established and dropped to
each CA. Access to the healthcheck URL is limited to localhost, and by default, the URL always returns the string "ALLOK" (as
defined in the ejbca.properties file).

The URLs for OCSP are also health‐checked, as defined in va.properties.

Creating an End Entity

Now that our CA and Profiles are defined, we can create our first End Entity. After entering the "Add Entity" page, select the name
of the End Entity Profile you created earlier. This will populate the fields with information from that Profile:

Add End Entity Page

Assuming you are using the "Default TLS Device Entity Profile" we created earlier, only the following information will be needed
before creating the Entity:

End Entity Profile: Default TLS Device Entity Profile

Username: yourdevice.yourcompany.net
The FQDN of the device that will request a certificate

Email Address: yourdevice@yourcompany.net

In this example, the Entity is a device, so any administrative email can be entered
CN: yourdevice.yourcompany.net
The FQDN of the device

DNS Name: yourdevice.yourcompany.net

The FQDN of the device

Certificate Profile: Default TLS Certificate Profile

The name of the Device‐specific Certificate Profile created earler

CA: rootca.yourcompany.net
The name of the CA you created in the previous step.

Token: User Generated

In this example, we assume that our Entity will use a password passed to it by the End Entity Profile. You can also have the Token
pulled from other sources (like a JKS file), or enter it manually on this page.

Select "Add" to create the Entity.

Once the Entity is added, you will see the new Entity listed at the bottom of the webpage.

OpenSSL Review ‐ Introduction

Ejbca requires us to submit a Certificate Signing Request before issuing a Certificate, but it does not include an interface to create
one. The simplest way to generate a CSR is using the OpenSSL utility, which has the ability to generate CSRs using the RSA or EC
algorithms. I think it's a good idea to include a short review of OpenSSL's use.

Despite the recent "HeartBleed" bug, OpenSSL is and shall remain the once and future king of open source encryption. It is a
complicated tool, and the majority of its functionality is beyond the scope of this how‐to. I will focus solely on OpenSSL's CSR‐
related functions.

When starting to write this review, I checked the version of OpenSSL on my ejbca server to determine if it was affected by
"HeartBleed", and found that it was:

openssl version

OpenSSL 1.0.1e­fips 11 Feb 2013

Versions of OpenSSL from 1.0.1 through 1.0.1f are vulnerable.

As of May 7th, 2014, TrevorH from CentOS states that they are waiting for RedHat to "backport a fix" to version 1.0.1e (whatever
that means). In the meantime, the version of OpenSSL on our server remains vulnerable.

If you intend to use OpenSSL to protect anything on a CentOS‐based server, you really, really need to manually update
OpenSSL instead of waiting for the CentOS patch to arrive via yum.

OpenSSL Review ‐ Creating a RSA CSR

We are assuming that EC encryption may not be implemented by some or all the devices in your network, so our first CSR will be
for a certificate that uses 2048‐bit RSA encryption and a SHA‐256 signing algorithm. The command below will create a new Private
Key, and include it in a new Certificate Signing Request:

openssl req ­newkey rsa:2048 ­nodes ­sha256 ­keyout server.key ­out server.csr

The syntax is composed of these elements:

req ‐ Defines that this command will relate to a certificate request
­newkey rsa:2048 ‐ A new Private Key will be created using the 2048‐bit RSA algorithm, along with a new CSR
­nodes ‐ The Private Key created by this command will be unencrypted
­sha256 ‐ The Certificate requested in the CSR will use the SHA‐256 signing algorithm
­keyout server.key ‐ The new Private Key will be saved in the file: server.key
­out server.csr ‐The new CSR will be saved in the file: server.csr

cat server.key

­­­­­BEGIN RSA PRIVATE KEY­­­­­ 
MIIEpAIBAAKCAQEA3RFeM/052S+Nf7yVipoLwpvA7uidm/bQ0Qm2DIBz0zjngJG7 
mqchOzodugkY0jZQ+8zFkHm+iJd9pjDGNFDoPE3r270GtrholbsNVpspI+VvTVQ+ 
UiBvccZGB6VGeNJ6Ts5qHbsFWjiU9smhaUd6fnAP6vBWmmYiBz79iLhXRPwUljSb 
dLUao1RZqTXq57ttL7xM6a1n4HkyYmXSQ/k26tsqoff1DYFVe6SWljL/2WL3zoLp 
uqDtt5XhVGHu3sk3UYEpC85bZXf6NPGR2b1Ha+IvixMmzTd2eVo1W1tzlYVqRJG+ 
DQ4kSew6oag8XfvCQ+6x9XCEjWCW2y04TNx8twIDAQABAoIBAQCubG60fH8xMsjl 
WWlwM31F7lh66ES68zHtTUk7cfpxVPurwNCSBH4+2ershxLzgXHCSt4y0SwZX9X+ 
04r/ajrioeSPuwRaFQRH549tnv0F2phIHkkRyY/E6FkG3UvONtvT5B9sF8zwU6aN 
VaeqhoBK1KZqi3j5V85Pg07Nmg0ZWohgzRnfu4URcQ6kOYk03nrgzo4E5Wt1pE7f 
dtfWQExjAKiCwVo7C7RyP6xwX8BMeM62mNsZB6Q5+wTeexS9pHi6Mf4aFqspVbhl 
4faTiqbuck5zGlx2j+mvIIv55HEfU7omknbmMQrJENr3UDGMMzTxeNJRhdK81PoR 
BD0667m5AoGBAPTQLal6CgSoRkNq6bwOK5ptru/+vk33QDHwWfvf3+6GDZyly1gq 
g+6Snr1R3Pul1Kvs5ESlr3vAFZtYoHcJlzMCTeTR3ilzACm8AOp3po6o2ciSRrPM 
AERO5N3MQIkk5CysX0wMuI/fsx12F4+QV77E5o/FCc6W8FbyrxWU4DvtAoGBAOcr 
arH4qUoqxSG6TxEylpyvJJzZkcWyqoueOTW7ks51nts3GB3eEGujcuvCA/+Yl0Qt 
CDtQWU+zCRWDRhQio7CeOJjW+Sef7yJsuECT4fGs8PX2mfabWLEVexMT3kI7u0Jx 
3rhl7z4DarxIVBF3MPtFBQkP6JVX+an/nwrQxi6zAoGAVZ8NqU12fYSA9olI8C2g 
kGU2HtfgpRIJkK24OwBkqF6YGiZeRRqxg9ohzKL5/8VS6UJz35J3Gnfm1qsbjCZ9 
jCiNJ69C3QpMj0wiod5xEUn6yUxnj/CUU0+oee46z/xoFTvAJK/6SM97LJ2lxd88 
4QqqfLP0Jx3hNvevxoOIHU0CgYByaXahJuUCpDB1BPTlGhiY68Y/Kx+OrWLjPygp 
g/Cg5m39KUNyZNnTrE3QiXHZKviS8YbFdHr/iyjP0Oz6Qjqpy2VPn/Youmtsqkp3 
C7okFugblDWXbEN1QaBsTMUQGugPdrQ4p5rFIoPNNC8HhepkMkDPv2PppmUW0kEw 
5StxKQKBgQDO0d5n1hVLvwaU8R5UAr2SD0J2P9lqjv080g8qdx39cR+ObN9h2XYk 
DYGbVu+Ck8yW25SkpoiLYsrD3Wmvf4yMsXLq2IuQ6Lgi8VTmly5Q8KJDxjUrdc6y 
wU8GmrUsbCpYHv6VI7K27UW4vnvQrlk+X9eSppH/5M/2jG+f1cfR2Q== 
­­­­­END RSA PRIVATE KEY­­­­­

cat server.csr

­­­­­BEGIN CERTIFICATE REQUEST­­­­­ 
MIICijCCAXICAQAwRTELMAkGA1UEBhMCQVUxEzARBgNVBAgTClNvbWUtU3RhdGUx 
ITAfBgNVBAoTGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcN 
AQEBBQADggEPADCCAQoCggEBAN0RXjP9OdkvjX+8lYqaC8KbwO7onZv20NEJtgyA 
c9M454CRu5qnITs6HboJGNI2UPvMxZB5voiXfaYwxjRQ6DxN69u9Bra4aJW7DVab 
KSPlb01UPlIgb3HGRgelRnjSek7Oah27BVo4lPbJoWlHen5wD+rwVppmIgc+/Yi4 
V0T8FJY0m3S1GqNUWak16ue7bS+8TOmtZ+B5MmJl0kP5NurbKqH39Q2BVXuklpYy 
/9li986C6bqg7beV4VRh7t7JN1GBKQvOW2V3+jTxkdm9R2viL4sTJs03dnlaNVtb 
c5WFakSRvg0OJEnsOqGoPF37wkPusfVwhI1gltstOEzcfLcCAwEAAaAAMA0GCSqG 
SIb3DQEBCwUAA4IBAQACLnWAJ4z9RPl/24+ChshX6rEoqX4hDPvfdCGs2e1ez5Y/ 
J1OVBm7V1rYQh4X763NPa2hhh83y5oe9h4YFn3W07yBWuY0adGCAe0Ci7X0yoNs2 
w6AoJ171nzBbiFEkH5mgDqqOBQAo6I+rUzQJKHsZpBYoWsfdnGDHyBE2sClw7kuW 
bqFHHZ116b+eQickR6bydYfo6H56vUx1LQHMCv0kOaxG8cFMNvrr1IY6EFbP15Lh 
UpwXn02nAzkoYgnLAxfjoLPEPK/RSDKkBNvefTu1mJHPTPcIzqDg9BK7V6HQvqh4 
LEUVLVvE3kE2/f8oXPVq63xNg5pFR7W+/9/NcLle 
­­­­­END CERTIFICATE REQUEST­­­­­

I have not shown the prompts where OpenSSL asks for the field data to be included in the CSR. Most of these fields will be
disregarded by ejbca during certificate creation as we have disabled "Overrides" in our Certificate Profile. However, you should
still complete these fields with the correct information.

OpenSSL Review ‐ Creating an EC CSR

OpenSSL now supports Elliptic Curve key algorithms, although the supported variants can, um,  vary with the version of OpenSSL
you are using. You can list the available curves in your implementation with this command:

openssl ecparam ­list­curves

secp384r1 : NIST/SECG curve over a 384 bit prime field 
prime256v1: X9.62/SECG curve over a 256 bit prime field

The above output was retrieved using the OpenSSL version (1.0.1.e) currently distributed by CentOS.
Interestingly, a FreeBSD box running an older branch of OpenSSL supports a greater number of curves:

[root@bsdbox] ~# openssl version 
OpenSSL 0.9.8y 5 Feb 2013

[root@bsdbox] ~# openssl ecparam ­list_curves 
  secp112r1 : SECG/WTLS curve over a 112 bit prime field 
  secp112r2 : SECG curve over a 112 bit prime field 
  secp128r1 : SECG curve over a 128 bit prime field 
  secp128r2 : SECG curve over a 128 bit prime field 
  secp160k1 : SECG curve over a 160 bit prime field 
  secp160r1 : SECG curve over a 160 bit prime field 
  secp160r2 : SECG/WTLS curve over a 160 bit prime field 
  secp192k1 : SECG curve over a 192 bit prime field 
  secp224k1 : SECG curve over a 224 bit prime field 
  secp224r1 : NIST/SECG curve over a 224 bit prime field 
  secp256k1 : SECG curve over a 256 bit prime field 
  secp384r1 : NIST/SECG curve over a 384 bit prime field 
  secp521r1 : NIST/SECG curve over a 521 bit prime field 
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field 
  prime192v2: X9.62 curve over a 192 bit prime field 
  prime192v3: X9.62 curve over a 192 bit prime field 
  prime239v1: X9.62 curve over a 239 bit prime field 
  prime239v2: X9.62 curve over a 239 bit prime field 
  prime239v3: X9.62 curve over a 239 bit prime field 
  prime256v1: X9.62/SECG curve over a 256 bit prime field 
  sect113r1 : SECG curve over a 113 bit binary field 
  sect113r2 : SECG curve over a 113 bit binary field 
  sect131r1 : SECG/WTLS curve over a 131 bit binary field 
  sect131r2 : SECG curve over a 131 bit binary field 
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field 
  sect163r1 : SECG curve over a 163 bit binary field 
  sect163r2 : NIST/SECG curve over a 163 bit binary field 
  sect193r1 : SECG curve over a 193 bit binary field 
  sect193r2 : SECG curve over a 193 bit binary field 
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field 
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field 
  sect239k1 : SECG curve over a 239 bit binary field 
  sect283k1 : NIST/SECG curve over a 283 bit binary field 
  sect283r1 : NIST/SECG curve over a 283 bit binary field 
  sect409k1 : NIST/SECG curve over a 409 bit binary field 
  sect409r1 : NIST/SECG curve over a 409 bit binary field 
  sect571k1 : NIST/SECG curve over a 571 bit binary field 
  sect571r1 : NIST/SECG curve over a 571 bit binary field 
  c2pnb163v1: X9.62 curve over a 163 bit binary field 
  c2pnb163v2: X9.62 curve over a 163 bit binary field 
  c2pnb163v3: X9.62 curve over a 163 bit binary field 
  c2pnb176v1: X9.62 curve over a 176 bit binary field 
  c2tnb191v1: X9.62 curve over a 191 bit binary field 
  c2tnb191v2: X9.62 curve over a 191 bit binary field 
  c2tnb191v3: X9.62 curve over a 191 bit binary field 
  c2pnb208w1: X9.62 curve over a 208 bit binary field 
  c2tnb239v1: X9.62 curve over a 239 bit binary field 
  c2tnb239v2: X9.62 curve over a 239 bit binary field 
  c2tnb239v3: X9.62 curve over a 239 bit binary field 
  c2pnb272w1: X9.62 curve over a 272 bit binary field 
  c2pnb304w1: X9.62 curve over a 304 bit binary field 
  c2tnb359v1: X9.62 curve over a 359 bit binary field 
  c2pnb368w1: X9.62 curve over a 368 bit binary field 
  c2tnb431r1: X9.62 curve over a 431 bit binary field 
  wap­wsg­idm­ecid­wtls1: WTLS curve over a 113 bit binary field 
  wap­wsg­idm­ecid­wtls3: NIST/SECG/WTLS curve over a 163 bit binary field 
  wap­wsg­idm­ecid­wtls4: SECG curve over a 113 bit binary field 
  wap­wsg­idm­ecid­wtls5: X9.62 curve over a 163 bit binary field 
  wap­wsg­idm­ecid­wtls6: SECG/WTLS curve over a 112 bit prime field 
  wap­wsg­idm­ecid­wtls7: SECG/WTLS curve over a 160 bit prime field 
  wap­wsg­idm­ecid­wtls8: WTLS curve over a 112 bit prime field 
  wap­wsg­idm­ecid­wtls9: WTLS curve over a 160 bit prime field 
  wap­wsg­idm­ecid­wtls10: NIST/SECG/WTLS curve over a 233 bit binary field 
  wap­wsg­idm­ecid­wtls11: NIST/SECG/WTLS curve over a 233 bit binary field 
  wap­wsg­idm­ecid­wtls12: WTLS curvs over a 224 bit prime field 
  Oakley­EC2N­3: 
        IPSec/IKE/Oakley curve #3 over a 155 bit binary field. 
        Not suitable for ECDSA. 
        Questionable extension field! 
  Oakley­EC2N­4: 
        IPSec/IKE/Oakley curve #4 over a 185 bit binary field. 
        Not suitable for ECDSA. 
        Questionable extension field!

This supports the old adage that "newer is not always better", especially when considering that the 0.9.8 branch is not
affected by HeartBleed.

Unlike a RSA CSR, the process to create an EC CSR requires two separate OpenSSL commands. We will make our request using the
prime256v1 curve, as it is the most commonly‐implemented in EC cryptography.

The first command creates the Private Key:

openssl ecparam ­out eckey.key ­name prime256v1 ­genkey

The second command reads the Private Key and creates the CSR. Note that the syntax differs from RSA version of the command in
that "newkey" is split into two different options:

openssl req ­new ­key eckey.key ­nodes ­sha256 ­outform pem ­out ecreq.csr

The new command options are:

­new ‐ A new CSR will be created 
­key eckey.key ‐ The new CSR will be derived from the Private Key in eckey.key
­outform pem ‐ The new CSR will be written in PEM format

Examining the output, we see that both the EC key and CSR are much smaller in size than their RSA equivalents:

cat eckey.key

­­­­­BEGIN EC PARAMETERS­­­­­ 
BggqhkjOPQMBBw== 
­­­­­END EC PARAMETERS­­­­­ 
­­­­­BEGIN EC PRIVATE KEY­­­­­ 
MHcCAQEEIDtrKu6BbwPabNV0SkbYqdLiRImoyzQ94VR8KdzqgfoGoAoGCCqGSM49 
AwEHoUQDQgAECGwMJiYQA15H2zuM9Xfdxsmyi72vMVHV6+rzWyLYqsH4IyvHGKqh 
ik1BPEQlwd280mmIFtE3ZkCHSRirP+O9eQ== 
­­­­­END EC PRIVATE KEY­­­­­

cat ecreq.csr

­­­­­BEGIN CERTIFICATE REQUEST­­­­­ 
MIH+MIGnAgEAMEUxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEw 
HwYDVQQKExhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggq 
hkjOPQMBBwNCAAQIbAwmJhADXkfbO4z1d93GybKLva8xUdXr6vNbItiqwfgjK8cY 
qqGKTUE8RCXB3bzSaYgW0TdmQIdJGKs/4715oAAwCQYHKoZIzj0EAQNHADBEAiAN 
s+Hm0+XEfKB6kTPbYFSjenSm/0CV2acUfVBm7LCPDgIgCzFr6KSFZM/VR4SIFkWU 
NHSDfhzPXgjv+VC3HJTF1KE= 
­­­­­END CERTIFICATE REQUEST­­­­­

Issuing our First Certificate

We can now take one of our newly‐generated CSRs and generate a Certificate with it. First, we navigate to the public ejbca
webpage:
 Public Ejbca Page

From here, we can navigate to the "Inspect Certificate/CSR" page to verify the CSR's contents:

CSR Inspection Page

If you are satisfied with what you see, navigate to the "Create Certificate from CSR" page and enter the CSR. Be sure to select
"PEM ‐ Full Certificate Chain" to have the CA certificate included in the output:
 Certificate Enrollment Page

Note that I am requesting an Elliptic Curve Certificate in this example.

Once the CA has validated the request and generated the Certificate, you will be prompted to download it:

Certificate Download

Congratulations! You've issued your first certificate from ejbca!

Finalizing the Installation

We are now down to the nitty‐gritty administrative details of our installation. Take a deep breath, and get ready for the final
push...

Defining Services

Ejbca includes a set of services that assist in the maintenance of your CAs, but they are not enabled by default. A framework is in
place to support these services, as well as any custom services you might need. Navigate to the Services section of the
administration webpage:
 Services Page

It is a good idea to enable a few of these services, but not all of them are typically needed. The predefined service types are:
CRL Updater ‐ Updates the published CRLs at a particular frequency.
Certificate Expiration Checker ‐ Alerts you to expired certificates
User Password Expire Service ‐ Alerts you to expiring user passwords
Renew CA Service ‐ Alerts you to expiring CA certificates
Publish Queue Process Service ‐ Used by distributed installations of ejbca
HSM Keepalive Service ‐ prevents you from being locked out of a HSM

To enable a service, you must first create a service instance with a unique name, and then associate that instance with the type of
task you wish it to perform.
On my server, I am using:
CRL Updater 
Certificate Expiration Checker 
Renew CA Service 
User Password Expire Service
Mysql Backup Service ‐ this service runs the script located in /opt/ejbca/bin/backup

Note that the services will fill your logs you define them to run too frequently. For example, the manual suggests that the CRL
Updater be run every 5 minutes. I find that once an hour (or day) is more than enough for a lab environment.

Creating the Default Certificate Authority

Recalling that the Validation Authority needs a CA to respond to unknown OCSP requests, we will now define the "Default CA" for
this purpose.

The procedure is very similar to the one described for creating rootca.yourcompany.net, but with a few simplifications.

First, skip the process of creating a new Crypto Token ‐ we will let ejbca automatically generate it and its keys.

Type of CA: X509

This is the standard for Internet communications.

Signing Algorithm: Sha1WithRSA

I chose this to minimize compute time.

Crypto Token: "‐ Create a new soft Crypto Token with recommended key pairs ‐"
This will autogenerate the Crypto Token and keys using the default 2048‐bit RSA algorithm.

Enforce Unique Serial Number: Enabled

As we will (probably) not be generating a huge number of certificates in a lab environment, we can ensure that certificate serial
numbers are not re‐used.

Use Certificate Request History: Enabled

This is essentially "detailed auditing" for requests.
Validity: 3652d
This value is the length of time that the CA's own certificate will be valid.

Subject DN: CN=defaultca.yourcompany.net,O=Your Company,C=US

Signed by: Self Signed

Because this will be a Root CA (but not one we will actively use), it will still sign its own initial certificate.

Subject Alternative Name: dNSName=defaultca.yourcompany.net

As discussed, this is the FQDN of the CA, with the appropriate prefix.

Use Issuing Distribution Point on CRLs: Enabled

This includes a URL for retrieval of this CA's CRL in the CA's own certificate.

Generate Default CRL Distribution Point: Generated, but remove ":8080" from the URL.
We do this because of our firewall port translation rules.

Generate Default CRL Issuer: Generated

Do not edit this string. It should be your DN.

CA Defined FreshestCRL Extension: Not Generated

We are not using "Delta CRLs" with our CA, so this field is not included.

CA Issuer URI: Empty

This is an optional field that can be ignored.

Default OCSP Service Locator: Generated, Remove ":8080"

We do this because of our firewall port translation rules.

Now, create the CA. Again, if creation fails, just "go back" in your browser.

Lastly, as before, we must activate the internal health check on the CA Activation page.

Adding the Server to Production PKI ‐ Creating the New Server Cert

Now that we have our own CA running on a fully functional server, we can replace the generic TLS certificate created during ejbca
installation with one from our own PKI.
From now on, I will refer to our own CA (rootca.yourcompany.net) as being the "Production" CA.
 We do this, of course, to ensure that every element of our network participates in our PKI, including the PKI server itself.
There are a few things to be reminded of before we perform this step:
When building our Production CA, we created the first of the two identically‐named certificates we discussed at the
beginning of this how‐to. Both of these certificates will have the same CN value (rootca.yourcompany.net), but will be
used for different purposes.
One is the CA certificate, the other is for TLS enciphering and authentication.
We created the CA certificate when defining the CA, and we are about to create the TLS certificate.

The process for updating this certificate is a little complicated, as it requires that multiple items be replaced simultaneously:
The keystore.jks/tomcat.jks file (and the certificates in it)
The truststore.jks file that (and the CA certificate in it)
The certificate used for administrator access (currently: superadmin.p12)

The need to replace all of these items at the same time means the process requires great care, for we have the potential to
lock ourselves out of the administration interface of the server.

Begin by defining the End Entity for the server. You must use the same password for this End Entity that we used for the keystore
when installing ejbca.
This avoids the need to update the (cleartext!) passwords held in standalone.xml.

Navigate to the "Add End Entity" page, and enter the following options:

End Entity Profile: Default TLS Entity Profile

Username: rootca.yourcompany.net
Password: (Enter the password you specified for your tomcat.jks/keystore.jks file)
E‐mail address: rootca@yourcompany.net
CN: rootca.yourcompany.net
DNS Name: rootca.yourcompany.net
Certificate Profile: Default TLS Certificate Profile
CA: rootca.yourcompany.net
Token: JKS file

Now that the Entity exists, we can request the certificate from the server. Because we chose "JKS" for the token format, we do not
need to submit a CSR. The server will provide the completed certificate to us in JKS format.

Navigate to the "Create Keystore" area of the Public Ejbca Webpage, and enter the Entity information. You will be taken to this
page:

Token Enrollment Webpage

Once here, select "2048" or "4096" for the "Key length", and download the JKS file when prompted. You can verify the contents and
password of the file using the keytool command provided earlier in the how‐to:

keytool ­v ­list ­keystore tomcat.jks

Adding the Server to PKI ‐ Creating a New User

We continue by replacing the "superadmin" account with something a little less, uh, "super".

There is an important caveat to be understood here. While a new administrator Entity/certificate will be created in this step, it
will not be recognized by the server until the Production TLS certificate has been installed on the server.

This is due to the nature of TLS, and how Firefox handles the certificate request from ejbca during session establishment. If the
exchange is examined in a packet capture:
 Client Certificate Request

We see that the server (ejbca) provides its own DN when requesting the client's certificate. Firefox takes this DN information and
examines its store of personal certificates to see if any of them were created by the DN specified in the request. If there are no
matches, Firefox returns with "SSL Peer Cannot Verify Your Certificate".

In the example above, the server is still using the initial certificate issued by "mgmtca", and so will not recognize new
administrator certificates issued by "rootca.yourcompany.net".

Proceed by creating a new Certificate Profile named "Default User Certificate Profile", using the "Default TLS Certificate Profile"
as a template.

Update the inherited options in the new Profile with the following:

Key Usage: Digital Signature, Non‐repudiation, Key encipherment

Extended Key Usage: Client Authentication, Email Protection
Subset of Subject Alt Name: RFC 822 Name (e‐mail address)

Next, create a new End Entity Profile named "Default User Entity Profile", using "Default TLS Entity Profile" as a template. In this
new Profile, add/change these options:

Subject DN Attributes: Leave the CN field blank

Subject DN Attributes: Add "emailAddress, E‐mail address in DN", Set as Required
Other subject attributes: Remove the "DNS Name" entry
Other subject attributes: Add "RFC 822 Name (e‐mail address)", Set to "Use entity email field" and "Required"
Default and Available Certificate Profile: "Default User Certificate Profile"
Default and Available CA: "rootca.yourcompany.net"
Default and Available token: "P12 file"

Now, add an End Entity with the following details:

End Entity Profile: Default User Entity Profile

Username: (as desired)
Password: (as desired)
E‐mail address: youremail@yourcompany.net
CN: <First Name> <Last Name>
Certificate Profile: Default User Certificate Profile
CA: rootca.yourcompany.net
Token: P12 file

Now navigate to the Public Ejbca Webpage and select "Create Browser Certificate". You will be prompted for the username and
"Enrollment Code" you chose in the previous step.

Once validated, you will be given the "EJBCA Token Certificate Enrollment" page:
 Token Enrollment Page

Because we are staying with RSA keys in this how‐to, select "2048 bits" from in the "Key length" menu. Click on "Enroll", then save
the .p12 file when prompted.

Adding the Server to PKI ‐ Installing the User Certificate

Now, install the new .p12 file in the same way that "superadmin.p12" was installed earlier in the how‐to. You will be prompted
for the password you chose during the creation of the End Entity.

Do not delete the superadmin certificate at this time!

Again, using Firefox as an example:

Tools ==> Options ==> Advanced ==> Certificates ==> View Certificates

and selecting "Import" from the "Your Certificates" tab.

When the certificate is added to your browser, two actions are actually taken (using Firefox as an example):
The "personal" certificate of the End Entity is added to the "Your Certificates" store
The CA certificate for the issuing CA (rootca.yourcompany.net) is added to the "Authorities" store
We will need a copy of the CA certificate in a future step of the how‐to, so extract it from Firefox's "Authorities" store:

Tools ==> Options ==> Advanced ==> Certificates ==> View Certificates

and selecting "Export" from the "Authorities" tab.

The certificate should be listed under the heading of "Your Company", as "rootca.yourcompany.net". 
In the "Save File" display, stay with the default format of "X.509 Certificate PEM (*.crt, *.pem)".
Now is a good time to make a backup of your "superadmin" certificate, if you don't have one.

Adding the Server to PKI ‐ Granting Admin Rights

Before we can use our new user certificate for administration, we must grant it administrative privileges in ejbca. Navigate to the
"Administrator Roles" page on the ejbca administration site:
 Administrator Roles

Now select "Administrators", next to the "Super Administrator Role" heading.

C.R.E.A.M.

Once on the "Edit Administrators" page, select the following and add a new entry:

CA: "rootca.yourcompany.net"
Match with: X.509 Certificate Serial Number (recommended)
Match type: Equal, case sens.
Match value: (enter the serial number of your new administrator certificate)

 Note that Firefox will insert colons (:) in the serial number of the certificate, but ejbca does not allow them. Remove
them before committing the change.

Adding the Server to PKI ‐ Installing the Keystores

Primekey's instructions for updating the Jboss keystores are convoluted at best, and at worst, downright misleading. They assume
two things:
That you will use the "batch certificate creation" tool to make your keystores
That you will use the ejbca "command line" to execute the batch tool

My problem with both the "ejbca command line" and the batch creation tools (there are both command line and gui versions) is
that they have achieved the trifecta of non‐usability:
Obscure
Undocumented
Unreliable
We will use keytool to manage our keystore files, and avoid this command line silliness altogether.

First, stop ejbca:

service ejbca stop

Next, back up the existing keystore files:

cd /opt/ejbca/P12 
mv tomcat.jks tomcat.orig
mv truststore.jks truststore.orig

cd /opt/jboss/standalone/configuration/keystore
mv keystore.jks keystore.orig
mv truststore.jks truststore.orig

Copy the new keystore file containing our server certificate to /opt/ejbca/P12, and name it "tomcat.jks". Copy the CA
certificate for "rootca.yourcompany.net" to /opt/ejbca/P12 as well, and name it "truststore.crt".

Now we will create a new truststore file that will include the CA certificate for "rootca.yourcompany.net".

It is required that the new truststore use the same password as the existing one. 
This is the truststore password you entered during installation.

cd /opt/ejbca/P12
keytool ­importcert ­alias rootca.yourcompany.net ­file truststore.crt ­keystore truststore.jks

Be sure to validate the contents and passwords of the new keystores. They should be very similar to the examples provided earlier
in the how‐to:

keytool ­v ­list ­keystore tomcat.jks
keytool ­v ­list ­keystore truststore.jks

Now copy the new keystores to the jboss directory:

cp tomcat.jks /opt/jboss/standalone/configuration/keystore/keystore.jks
cp truststore.jks /opt/jboss/standalone/configuration/keystore

Reset the ownership on the directories:

chown ­R jboss:jboss /opt/jboss­as­7.1.1­Final
chown ­R jboss:jboss /opt/ejbca_ce_6_1_1

And finally, start ejbca:

service ejbca start

You should not see any unexpected messages in the console log.

Adding the Server to PKI ‐ Finalizing the Move

To test the new certificate, shut down your browser completely, then start it and browse to the administration website. You
should now be prompted for the new administrator certificate (instead of the superadmin certificate), then forwarded to the
administration site.

When viewing the TLS values for the browser, you should now see that the administration page is protected by a certificate
belonging to "rootca.yourcompany.net", which was issued by the CA "rootca.yourcompany.net".
Our final steps are to clean up the items relating to installation admin access:

Delete the superadmin certificate from your browser's "Your Certificates" store
Delete the "mgmtca" entry from your browser's "Authorities" store
Delete "superadmin" from the "Super Administrator Role" in the administration console
Revoke the certificate issued by "mgmtca" for "rootca.yourcompany.net"

Revoking a certificate is quite easy to do in ejbca. First, use "Search End Entities" to find the Entity you wish to revoke:

Search End Entities

Select the entity to be revoked, then "Revoke and Delete" it. Be sure to add the proper "Revocation Reason" in the menu at the
bottom of the screen.

Assuming that you are not running a Service that will automatically update the CRL for the CA that issued the revoked certificate,
you will need to update it manually. Navigate to the "CA Structure & CRLs" page:

Update CRLs

Select "Create CRL" on the CA you wish to update, and you are finished.

A very final note on permissions: you may have noticed entries in the .properties files and on the "Super
Administrator Role" page relating to command line (CLI) access. I am deliberately ignoring permissions relating to the
command line, as I assume that you are using strong ssh and console login controls.

Fixing the Jboss Web Console Datasource Stats

There is an optional fix to Jboss that can be made once ejbca has been fully installed and deployed. The problem it addresses may
not be something you care about, which is why I include it as an afterthought at the end of this how‐to.

When using the Jboss web console, you may notice that the datasource entries for ejbca are shown as "disabled", but are reported
as being "enabled" when you attempt to "enable" them. This is due to a bug in ejbca's ant target responsible for datasource
creation. The datasources themselves are working, which makes this a cosmetic bug with minor ramifications.

The bug itself relates to a missing "enabled" variable in the datasource definitions held in standalone.xml. You can add this
variable manually to the configuration and temporarily fix the problem.

Unfortunately, there is a good chance that future deployments will "re‐break" this fix.

vi /opt/jboss/standalone/configuration/standalone.xml

### Start standalone.xml Delta ###

Update the following lines:

<datasource jndi­name="java:/EjbcaDS" pool­name="ejbcads" use­ccm="true">
<datasource jta="false" jndi­name="java:/OcspDS" pool­name="ocspds" use­ccm="true">

to:

<datasource jndi­name="java:/EjbcaDS" enabled="false" pool­name="ejbcads" use­ccm="true">
<datasource jta="false" jndi­name="java:/OcspDS" enabled="false" pool­name="ocspds" use­ccm="true">

### End standalone.xml Delta ###

service ejbca restart (be patient)

Reenter standalone.xml and change the added variables to "true"
service ejbca restart (be patient)

The datasources will now be shown as "enabled" in the  "Profile" section of Jboss web console.

This change subsequently allows you to enable Jboss statistics monitoring:

Select the "Runtime" section at the top of the web console.
Select "JPA".
After selecting "ejbca", use the "edit" button to open its properties, and check the box next to "Metrics Enabled?"
Select the "OSGI" section.
You will be asked if you wish to enable OSGI. Answer "Yes".

Jboss subsystem metrics are now fully enabled, and can be checked from the web console.

Finishing the Mail Configuration

First, we finish configuring mail. Our server actually has two java mail relays: one for jboss, and one for ejbca. This "dual setup"
can be seen in the Jboss web console.

Now that we have the ability to generate our own certificates, a good initial step is to issue a unique certificate to your mail
server. The certificate can then be used (instead of the self‐signed certificate your server is probably using) to protect your mail
connections with TLS.

We have already configured the ejbca mail relay to forward traffic to the local mail daemon in the mail.properties file. If your
local mail service is configured to forward to an outside server, this is sufficient. If you wish to have ejbca make connections
directly to an outside server, this configuration will need to be updated.

Ejbca translates the configuration in mail.properties to stanzas in standalone.xml, just as it does for the datasource
configuration. Both the ejbca and the default jboss mail relays are defined in the same locations:

### Start standalone.xml Snip ###

<subsystem xmlns="urn:jboss:domain:mail:1.0"> 
     <mail­session jndi­name="java:jboss/mail/Default"> 
           <smtp­server outbound­socket­binding­ref="mail­smtp"/> 
     </mail­session> 
     <mail­session jndi­name="java:/EjbcaMail" from="ejbca@yourcompany.net"> 
           <smtp­server outbound­socket­binding­ref="ejbca­mail­smtp"/> 
     </mail­session> 
</subsystem>

and:

<outbound­socket­binding name="mail­smtp"> 
     <remote­destination host="localhost" port="25"/> 
</outbound­socket­binding> 
<outbound­socket­binding name="ejbca­mail­smtp"> 
     <remote­destination host="localhost" port="25"/> 
</outbound­socket­binding>

### End standalone.xml Snip ### 

While you can update the ejbca mail variables by editing mail.properties, this will not affect the Jboss default mail instance,
and may not provide all the options you desire.

Below is an example configuration that does the following for both relays:

Sets Gmail as the mail recipient

Uses encrypted SMTP
Uses the encrypted SMTP port number: 465

### Start standalone.xml Delta ###

<subsystem xmlns="urn:jboss:domain:mail:1.0">
      <mail­session jndi­name="java:jboss/mail/Default" from="ejbcamail@gmail.com">
            <smtp­server ssl="true" outbound­socket­binding­ref="mail­smtp­gmail">
                  <login name="ejbcamail@gmail.com" password="your_password"/>
            </smtp­server>
      </mail­session>
      <mail­session jndi­name="java:/EjbcaMail" from="ejbcamail@gmail.com">
            <smtp­server ssl="true" outbound­socket­binding­ref="mail­smtp­gmail">
                  <login name="ejbcamail@gmail.com" password="your_password"/>
            </smtp­server>
      </mail­session>
</subsystem>

<outbound­socket­binding name="mail­smtp­gmail">
      <remote­destination host="smtp.gmail.com" port="465"/>
</outbound­socket­binding>  

### End standalone.xml Delta ###

Setting Production Mode

You might recall a setting in ejbca.properties for something called "Production Mode". Now that we are more‐or‐less finished
with our installation, we can set this value to "true". Frankly, I'm not entirely sure what this does, but it's probably important
enough that we should set it.

vi /opt/ejbca/conf/ejbca.properties

### Start ejbca.properties Delta ###

# Initially, we will set this to false. Once the install is complete, we change
# this to true.
# But DO NOT set it to "ca"!
ejbca.productionmode=true
#ejbca.productionmode=false       

### End ejbca.properties Delta ###
Tightening Mysql Permissions

Mysql is fairly notorious for being vulnerable to various attacks. Some risk can be mitigated by tightening the database permissions
for the ejbcadbuser account.

Primekey provides a script to perform these modifications in /opt/ejbca/doc/howto/mysql­privileges.sh. You will need
to run the script as shown below, then execute the sql commands created by it. This is by no means a comprehensive guide to
securing mysql, but taking these steps is certainly better than nothing.

export SQLUSER=ejbcadbuser
export SQLDATABASE=ejbcadb
cd /opt/ejbca/doc/howto/mysql­privileges.sh
sh mysql­privileges.sh

<enter mysql root password when prompted>

mysql ­u root ­p ejbcadb < mysql­database­privileges.sql

You can verify the privilege changes by doing the following:

mysql ­u ejbcadbuser ­p 
use ejbcadb;
show grants for ejbcadbuser@localhost;
exit 

Securing the Public Web Interface

You may not wish to allow unencrypted access to the Ejbca Public Webpage. I know I don't, considering that we are cutting and
pasting information relating our certificates to the tools on the page.

The easiest way to disable this access is to simply remove the port forwarding rule for port 80==>8080 that we created at the
beginning of the how‐to.

Additionally, you may wish to force users to perform client certificate authentication before accessing the Public Webpage. You
can accomplish this by disabling the forwarder from port 442==>8442.

But I suggest that you leave the encrypted access on port 442, as disabling both 80 and 442 access has the effect of preventing
everyone other than ejbca administrators (with Client Certificates) from accessing the server.

A clean way to configure this is to have a forwarding page that redirects HTTP requests on port 80 to HTTPS on port 442, which
will then be forwarded by the firewall to the goal of port 8442.

This is actually part of the 6.3.1.1 ejbca installation guide, but I leave it to you to find your own preferred way to route traffic.

Fixing the Administration Page Link

There is an additional annoyance that requires a slightly more in‐depth set of changes. This change is completely optional, but I
include it to clarify that from its own point of view, ejbca is doing what it should be doing during deployment.

On the Ejbca public web page, there is a link to the "Administration" page. The URL for this link uses the private HTTPS port that
was defined in  web.properties. Unfortunately, we have changed this port to externally be 443, via the firewall port redirect
we configured at the beginning of the how‐to.

We can't change the entry in web.properties to be 443, or the server will fail to start. The links on the Ejbca Public Page and
the Administration Page are the only things I have found that would care about the external web ports, so updating this link is
probably the easiest way to fix this.

Edit the following five files, all in the /opt/ejbca/modules/publicweb­gui/resources directory:

retrieve/header.jsp
templates/header.jsp
inspect/header.jsp
enrol/header.jsp
header.jsp
In each case, make the following edit:

### Start header.jsp Delta ###

Change:

<% java.net.URL adminURL = new java.net.URL("https",
     request.getServerName(),
     org.ejbca.config.WebConfiguration.getExternalPrivateHttpsPort(),
     "/"
     +org.ejbca.config.InternalConfiguration.getAppNameLower()
     +"/adminweb/");
%>

To:

<% java.net.URL adminURL = new java.net.URL("https",
     request.getServerName(),
     ­1,
     "/"
     +org.ejbca.config.InternalConfiguration.getAppNameLower()
     +"/adminweb/");
%>

### End header.jsp Delta ###

Substituting "‐1" has the effect of telling jboss to use the default port number for HTTPS when building the URL (essentially, by
omitting a port number completely).

Now, redeploy ejbca, and the link will be correct.

In Closing
It's been two years since I initially wrote this document, and the information in it is still surprisingly current.
On the one hand, this is because ejbca is a stable, mature product operating in a niche space.
On the other hand, this is also because the process of installating and operating ejbca hasn't significant improved over
the last two years.

To be fair, I see that the current (as of this writing) version of ejbca (6.3.1.1) includes a significant amount of new functionality
relating to Microsoft Active Directory integration. This is laudable and appreciated.

However, my criticism of two years ago stands: for what it does, installing this product is far, far more painful than it must be. At
a certain point, I must belive that this is a concious decision on the part of PrimeKey.

But I still believe that ejbca is perfect for a lab environment, and remains the best option for open source certificate authorities.

I hope that this guide helps you through a decidedly rough installation process. Good luck!

Password Tally
At the beginning of this how‐to, I mentioned that I would keep a running tally of the passwords required by the installation. Here it
is. I am amused to note that a minimum of 10 unique passwords are required for a basic ejbca installation.

1. Root OS password (root)

2. Mysql root password  (root@localhost)
3. Mysql ejbca password  (ejbcadbuser@localhost)
4. Ejbca OS password  (ejbca)
5. Jboss web console password (jadmin)
6. Initial keystore password (tomcat.jks/keystore.jks)
 7. Initial truststore password (truststore.jks)
8. Superadmin certificate password (superadmin.p12)
9. Soft token authentication key (rootca.yourcompany.net)
10. End entity password/enrollment codes (yourdevice.yourcompany.net)

This list does not include passwords that are likely to be needed, but are optional:

1. Production administrator certificate password (youradmin.p12)

2. Email server password (for SMTP/TLS)
3. Publisher passwords for distributed installation
4. Passwords for OS‐level integrated AAA
5. Active Directory password for integrated certificate publishing

"How to Install EJBCA 6.1.1 on CentOS 6.5" by VES Group, Incorporated is licensed under a
Creative Commons Attribution‐NonCommercial‐ShareAlike 4.0 International License.
Based on a work at http://ejbcacentos.blogspot.com.

Posted by Warren V at 4:53 PM +9   Recommend this on Google

54 comments:
flipy May 2, 2014 at 9:11 AM
If using a mysql connector greater than 5.1.30, follow this advise: https://community.jboss.org/message/866702#866702
Reply

Warren V May 3, 2014 at 2:46 AM

Thanks! I have rewritten the mysql portion of the document to better explain this.
Reply

Replies

flipy May 9, 2014 at 2:15 AM

Thanks to you, as this is the most comprehensive tutorial about deploying EJBCA along with JBoss that I've found.

Reply

Warren V May 12, 2014 at 11:05 PM

Whoever is hitting the blog using MultiZilla: Respect, you circa‐2001 badass.
Reply

Lê Tùng May 17, 2014 at 7:31 AM

Hi,
I install EJBCA following your guide, but i have an error. When i run sudo ‐u jboss ant install it run to:
ejbca:init:
[echo]
[echo] ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ CA Properties ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
[echo] ca.name : atttca
[echo] ca.dn : CN=atttca,O=HVKTMM,C=VN
[echo] ca.tokentype : soft
[echo] ca.keytype : RSA
[echo] ca.keyspec : 4096
[echo] ca.signaturealgorithm : SHA256WithRSA
[echo] ca.validity : 3650
[echo] ca.policy : null
[echo] ca.tokenproperties : /opt/ejbca/conf/catoken.properties
[echo] httpsserver.hostname : rootca.attt.vn
[echo] httpsserver.dn : CN=rootca.attt.vn,O=HVKTMM,C=VN
[echo] superadmin.cn : superadmin
[echo] superadmin.dn : CN=superadmin,O=HVKTMM,C=VN
[echo] superadmin.batch : true
[echo] appserver.home : /opt/jboss
[echo]

ejbca:install:

ejbca:initCA:
[echo] Initializing CA with 'atttca' 'CN=atttca,O=HVKTMM,C=VN' 'soft' '4096' 'RSA' '3650' 'null' 'SHA256WithRSA'
/opt/ejbca/conf/catoken.properties ‐certprofile ROOTCA ‐superadmincn 'superadmin'...
AND SUSPEND (not run).
a Pragraph of LOG jboss file:
21:16:12,837 INFO [javax.enterprise.resource.webcontainer.jsf.application] (MSC service thread 1‐2) JSF1048: PostConstruct/PreDestroy
annotations present. ManagedBeans methods marked with these annotations will have said annotations processed.
21:16:13,369 INFO [org.ejbca.ui.web.admin.configuration.StartServicesServlet] (MSC service thread 1‐2) Init, EJBCA 6.1.1 (working
copy) startup.
21:16:13,722 INFO [org.cesecore.keys.token.CryptoTokenFactory] (MSC service thread 1‐2) Class not found:
se.primeKey.caToken.card.PrimeCAToken.
21:16:13,726 INFO [org.cesecore.keys.token.CryptoTokenFactory] (MSC service thread 1‐2) Can not register
se.primeKey.caToken.card.PrimeCAToken. This is normally not an error.
21:16:51,625 INFO [org.jboss.as.server] (DeploymentScanner‐threads ‐ 2) JBAS015870: Deploy of deployment "ejbca.ear" was rolled back
with failure message Operation cancelled
21:16:51,633 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner‐threads ‐ 1) JBAS015052: Did not receive a response
to the deployment operation within the allowed timeout period [60 seconds]. Check the server configuration file and the server logs to
find more about the status of the deployment.
21:21:13,791 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX
0:ffff7f000001:‐64530e7e:53776f17:8 in state RUN
21:21:13,823 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id
0:ffff7f000001:‐64530e7e:53776f17:8 invoked while multiple threads active within it.
21:21:13,824 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check ‐ atomic action
0:ffff7f000001:‐64530e7e:53776f17:8 aborting with 1 threads active!
21:21:13,831 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker
Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff7f000001:‐64530e7e:53776f17:8

=============================
could you help me solve it. Thank a lot.
Reply

Replies

Warren V May 18, 2014 at 4:28 PM

Looks like a configuration problem. I'd suggest reviewing your properties files and standalone.xml. The relevant message is:

21:16:51,633 ERROR [org.jboss.as.server.

deployment.scanner] (DeploymentScanner‐threads ‐ 1) JBAS015052: Did not receive a response to the deployment operation
within the allowed timeout period [60 seconds]. Check the server configuration file and the server logs to find more about the
status of the deployment.

The problem itself is that jboss hung while attempting to deploy your ear file. Either your config file is incomprehensible, your
jboss installation is corrupt, or you have a permissions problem.

If I had to guess, either the datasource definition in your standalone.xml file is bad, or the database itself did not respond to
attempts to update it.

Amine Diaf March 27, 2015 at 2:02 AM

Lê Tùng, i have the same issue, can you tell me what was the problem and how have you solved it. thanks

Reply

Тимур Кулибаев May 29, 2014 at 3:37 AM

This comment has been removed by the author.
Reply

Replies
 Warren V May 29, 2014 at 12:40 PM
Please check your va‐publisher properties file. It should read:
ocsp‐datasource.jndi‐name=OcspDS
ocsp‐database.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF‐8

Note that the jndi‐name for the OCSP datasource is not "EjbcaDS", but "OcspDS". If the entries in ejbca.properties and va‐
publisher.properties are different, you should not see this error.

Reply

Тимур Кулибаев May 30, 2014 at 12:41 AM

Hello, Warren !
Thank you for your advice.
1) Checking va‐publisher.properties I see ocsp‐datasource.jndi‐name=OcspDS ‐ so no mistake here. Probably EjbcaDS was registered in
JBoss 7 at first running of "ant deploy". I reinstalled EJBCA from the scratch adding
ocsp.properties
va.properties
va‐publisher.properties
before very first running of "ant deploy" and i get "Build successfull", no any errors. "ant install" also gives "build successfull", no any
errors.
But DefaultCA didn'appear in the list of CA in /ejbca/adminweb, only Management CA. ROOTCA is also absent in the list of CA and I
created one myself through console.

2)I use Oracle DB 9i (9.2.0.5.0) and checking DB I see that ejbca db scheme was successfully auto‐populated :

SQL> select count(*) from dba_objects where owner='EJBCA';

COUNT(*)
‐‐‐‐‐‐‐‐‐‐
108

No mistakes in Oracle DB alert log.

It means that db driver is OK ‐ I use ojdbc6.jar , JBoss 7.1.1.Final, EJB 6.1.1, jdk 7u55 (I need only SHA1RSA, no need for ECDSA).
But in EJBCA console log I see:

"20:05:46,064 INFO [org.hibernate.dialect.Dialect] (MSC service thread 1‐4) HHH000400: Using dialect:
org.hibernate.dialect.Oracle10gDialect"

I confirm that ojdbc6.jar is compatible both with Java 7 and Oracle DB 9.2.x as per Oracle note "Starting With Oracle JDBC Drivers (Doc
ID 401934.1)".
Is EJBCA 6.1.1 compatible with Oracle DB 9.2 ?

3) There are no any mistakes at EJBCA installation time with your guide, but trouble is at configuring EJBCA with web‐console
/ejbca/adminweb ‐ I cannot do the creation of my first End Entity ‐ "Add End Entity" failes with error (in console.log):

12:41:35,409 ERROR [org.jboss.ejb3.invocation] (http‐‐0.0.0.0‐8443‐5) JBAS014134: EJB Invocation failed on component

EndEntityManagementSessionBean for method public abstract void
org.ejbca.core.ejb.ra.EndEntityManagementSession.addUser(org.cesecore.authentication.tokens.AuthenticationToken,org.cesecore.cert
ificates.endentity.EndEntityInformation,boolean) throws
org.cesecore.authorization.AuthorizationDeniedException,org.ejbca.core.model.ra.raadmin.UserDoesntFullfillEndEntityProfile,org.ejbca
.core.ejb.ra.EndEntityExistsException,org.ejbca.core.model.approval.WaitingForApprovalException,org.cesecore.certificates.ca.CADoes
ntExistsException,org.ejbca.core.EjbcaException: javax.ejb.EJBException: java.lang.NullPointerException
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss‐as‐ejb3‐
7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss‐as‐ejb3‐7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss‐as‐ejb3‐7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss‐as‐ejb3‐7.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss‐invocation‐1.1.1.Final.jar:1.1.1.Final]
at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.
java:41) [jboss‐as‐ejb3‐7.1.1.Final.jar:7.1.1.Final]

Caused by: java.lang.NullPointerException

at org.ejbca.core.model.ra.raadmin.EndEntityProfile.doesUserFullfillEndEntityProfile(EndEntityProfile.java:899) [ejbca‐util.jar:EJBCA
6.1.1 (working copy)]
at org.ejbca.core.ejb.ra.EndEntityManagementSessionBean.addUser(EndEntityManagementSessionBean.java:311) [ejbca‐ejb.jar:]

Could you please to give light to the error ?

Thank you beforehand,

Timur.
Reply
Тимур Кулибаев May 30, 2014 at 1:52 AM
In my previous post I forgot to say that I use Ubuntu Linux ("13.04, Raring Ringtail") and Java 7 is not openjdk ‐ it's usual oracle jdk
1.7u55 which does not use /etc/alternatives (jdk 1.7u55 was installed from tar.gz distr)
Reply

Replies

Warren V May 30, 2014 at 7:14 PM

Sorry Timur,

Since you are using Oracle Java 1.7, as well as Ubuntu, I'm afraid I can't do much to help you out. What I've observed is that
ejbca is very sensitive to the combination of software modules you run it on, which is largely why I wrote the guide. I was so
irritated a having to test 100 different build combinations that I just wrote a guide for the combination that seems to work
most reliably.

Just glancing at your error, it seems that the null pointer error you are receiving could be from an internal mismatch between
some limitation associated with your end entity profile. But I can't really take the time to read through the source code to
figure out just what is wrong.

For questions like these, you're probably best off sending emails to the ejbca discussion lists on sourceforge.

Good luck‐

Warren V

Reply

Тимур Кулибаев May 31, 2014 at 3:30 AM

I followed your advice about using openjdk 6 ‐ all is ok with openjdk 6 , Oracle 9.2.0.5, ojdbc6.jar, Ubuntu Linux ("13.04, Raring
Ringtail"), JBoss 7.1.1.Final, EJBCA 6.1.1 ‐ no any mistakes for this software modules combination also and I have reached the very end
of your superb rich in content guide. I have successfully issued my first certificate ! Thank you for your creative job and good luck to you
!
Reply

Replies

Warren V June 1, 2014 at 12:18 AM

I'm glad to hear it, Timur!

‐Warren V

Reply

Andreas Calvo June 3, 2014 at 7:12 AM

Warren,
Installation fails with error messages:
16:08:11,586 INFO [org.hibernate.tool.hbm2ddl.SchemaUpdate] (MSC service thread 1‐2) HHH000232: Schema update complete
16:08:58,673 INFO [org.jboss.as.server] (DeploymentScanner‐threads ‐ 2) JBAS015870: Deploy of deployment "ejbca.ear" was rolled back
with failure message Operation cancelled
16:08:58,684 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner‐threads ‐ 1) JBAS015052: Did not receive a response
to the deployment operation within the allowed timeout period [60 seconds]. Check the server configuration file and the server logs to
find more about the status of the deployment.

Oddly enough, first run of ant deply fails (couldn't contact JBoss error message).
Howerver, second runs ok but stops with the mentioned message.

Any hint?
Reply

Replies

Warren V June 3, 2014 at 11:00 PM

Hello Andreas,

I found these three articles within 10 seconds of Googling:

http://stackoverflow.com/questions/15001342/jboss‐7‐war‐deployment‐failed
https://www.openshift.com/kb/kb‐e1037‐timeout‐deploying‐jboss‐applications
 http://vinynigam.blogspot.com/2013/04/increasing‐deployment‐timeout‐for.html

Moral of the story: the machine you are running ejbca on is probably too slow for the deployment to finish. Extend the
timeout and see what happens. Beyond that, you're on your own.

‐Warren V

Reply

Тимур Кулибаев June 4, 2014 at 3:15 AM

This comment has been removed by the author.
Reply

Replies

Warren V June 5, 2014 at 1:31 AM

Sorry Timur,
Your best bet is to post this question to the EJBCA Sourceforge mailing list.
‐Warren V

Reply

Pascal LAFE June 5, 2014 at 1:25 AM

Dear warren,

Thank for this beautiful How to, please have you another to build OCSP with EJBCA ?

Reply

Replies

Warren V June 5, 2014 at 1:31 AM

Hello Pascal,
OCSP configuration is included in this how‐to.

‐Warren V

Warren V July 27, 2016 at 10:43 PM

A belated update: Pascal was totally correct ‐ the OCSP instructions relating to the va.properties file were quite bad. I've
cleaned them up.

Reply

Тимур Кулибаев June 17, 2014 at 9:08 AM

Hello, Warren !

There is a stanza in your guide:

"...Production Deployment and Test

Now we can perform our first true deployment that should give us a functional ejbca server:
sudo ‐u jboss ant deploy"

Do I understand correctly the following flow is correct:

a) ant deploy
b) ant install
c) ant deploy ?

Actually, I have missed c). What does c) do ?

I have successfully created CA and issued certificates.

Thanks a lot, Timur

Reply

Warren V June 18, 2014 at 1:22 AM

The deploy in step "c" pushes the compiled ear file created in the install step to jboss. It is an artifact of how jboss works.

‐W
Reply

Luis A. Uriarte July 31, 2014 at 10:03 AM

Warren.
De verdad muy bueno tu artículo. Muchas gracias. Estamos tratando de armar un CA en el Municipio de Río Grande ‐ Tierra del Fuego y
me estoy basando en tu artículo. Cuando lo terminemos te comento. Usamos Centos 7, jboss 7.1.1 y ejbca 6.2.0.
Saludos.
Luis.
Reply

Replies

Warren V August 2, 2014 at 7:58 PM

De nada, Luis,

Por favor dígame que los cambios que realice con la versión 6.2.0, y voy a actualizar la guía.

‐Warren

Reply

Тимур Кулибаев September 2, 2014 at 10:27 PM

This comment has been removed by the author.
Reply

Rohit Jain November 4, 2014 at 1:08 AM

Warren

Excellent post and thank you for sharing the details. I was planning to write up something myself but landed on your post and it is way
beyond what I had in mind, so kudos!

You have mentioned some best practices in few sections but was wondering if there is more to it? Also, do you plan to release more
articles around EJBCA?

Rohit Jain
Reply

Replies

Warren V November 9, 2014 at 10:32 PM

I intend to publish an update for the newer versions of ejbca as soon as I have time. I've been focusing on vSphere and storage
lately, so not sure when that will be.

As for your question, I'm not sure what exactly what you are asking. There are many possible requirements for setting up a CA,
so I've tried to focus on the simple lab installation paradigm. I do intend to write some articles on Active Directory
integration, as getting AD to play nice with an external CA is never easy. But I'll probably throw in some stuff about SCEP and
mobility while I'm at it.

Reply

Davis Mendoza P. November 19, 2014 at 3:00 PM

Hi.
Congratulations for making a very good guide
I deploy EJBCA inside LXC with debian OS and it works very well

The LXC containers I use are:

* lxc‐ejbca
* lxc‐mysql
* lxc‐apache

I am doing the configuration in order to login via apache to jboss. review the documentation http://www.ejbca.org/guides.html
and I have a problem generating the certificate using the command
bin/ejbca.sh ra addendentity apache‐ssl foo123 "CN=ca‐server.company.local,O=EJBCA Sample,C=SE" "" ManagementCA "" 1 PEM SERVER

how I can fix it

greetings
Reply

Pan B. February 25, 2015 at 5:12 PM

HI,

I follow your guide step by step but when i try sudo ‐u jboss ant deploy i take this error:

BUILD FAILED
/opt/ejbca_ce_6_1_1/build.xml:79: Execute failed: java.io.IOException: Cannot run program "java": java.io.IOException: error=2, No
such file or directory

Can you help me to fix it?

Thanks a lot,
‐P
Reply

Justin White, CCIE #14745 April 17, 2015 at 11:33 AM

Warren,

Congrats on such a fantastic guide. One issue I ran into is likely specific to deploying EJBCA and JBoss on Ubuntu 14.04 LTS, but it
doesn't seem that JBoss 7.1.1 supports ":reload" on Ubuntu. I had to modify /opt/ejbca/bin/jboss.xml to use ":shutdown(restart=true)"
instead.

For others, note that Ubuntu does not offer support for /etc/init.d/functions, so you'll also need to modify the init script to eliminate
the instances of "success" and "failure" that occur.
Reply

Việt Anh Trần August 24, 2015 at 3:58 AM

I want upgrade ocsp and ca from ejbca 4.0.X to ejbca 6.0.X
I read doc/UPGRADE but there is only mentioned upgrade from version 5.0.X. But as I know version 5 never version community.
I tested upgrade ocsp 4 ‐> 6. the steps are as follows
1. config on ejbca config: ejbca.properties, database.properties, ocsp.properties, web.properties.
2. backup db.
3. ant deploy + ant install
4. ocsp have Admin Gui
upgrades on the right or wrong? Why, In Admin GUI ocsp have a CA default and issue certificate from this?
if true, can i upgrade ca same upgrade ocsp?
Reply

香取佑幸 October 5, 2015 at 4:30 AM

Hi,

Excuse me. I got this error when I added new datasouce then build by ant deploy.
‐‐‐
10:56:39,945 ERROR [org.jboss.as.controller.management‐operation] (HttpManagementService‐threads ‐ 2) JBAS014612: Operation
("enable") failed ‐ address: ([
("subsystem" => "datasources"),
("data‐source" => "XXX‐DS")
]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data‐source‐config.XXX‐DS is already registered
‐‐‐

Build itself by ant was fine but datasouce was false.

I want to deploy mariaDB instead of H2.

Before ant deploy, I checked all files HOME_ejbca and HOME_jboss but XXX‐DS not found.
But after ant deploy, I got the above error.

I checked build.xml and jboss.xml, but is there any correct procedure to add new datasouce?
I followed as you customized database.properties but, in this case, I got Service jboss.data‐source‐config.ejbcads is already registered.
# But you didn't?

I checked with the keyword "ejbcads", I found out:

‐‐‐
HOME_ejbca/bin/jboss.xml
306
307
308
‐‐‐

When I set "ant deploy", EJBCA uses the parameter "308 <jboss:adm arg='data‐source add ‐‐name=ejbcads" automatically?
Sorry for my assumption but, ‐‐name=ejbcads is used twice when I set "ant deploy" for some reason? That might be why I get the error
"ejbcads is already registered".

I stepped as follows:
1. setup DB
2. JBoss setup
3. deploy driver
4. customize database.properties and ejbca.properties
5. ant deploy

version
EJBCA 6.3.1.1
JBoss AS 7
JDK 1.7 <<< I used this version because I got the failure when "ant deploy"
ANT 1.8
MariaDB 5.5
Reply

Davide November 1, 2015 at 4:41 AM

Great, fantastic manual. Without your manual I never installed ejbca. Thank you. Thank you. Thank you.
I installed on Centos 7.1.1503 and ejbca_ce_6_3_1_1 without problems.
I think that in your documentation there is only one little error:
"sudo ‐u jboss ant install" give me "[java] Can't define a CAToken properties file for a soft token" so I changed

install.properties
from
ca.tokenproperties=/opt/ejbca/conf/catoken.properties
to
#ca.tokenproperties=/opt/ejbca/conf/catoken.properties

Thank you again!!

Reply

Replies

Warren V July 23, 2016 at 10:01 PM

You're Welcome! And yes, this is totally a mistake on my part which has been fixed. I actually ran into this error while working
on the new 6.3.1.1 version of this document, and a Google search took me to your comment. It's a strange feeling to have a
bug search take you back to your own documentation :‐)

Reply

Việt Anh Trần November 11, 2015 at 8:58 AM

thank you,
I have build ocsp with: ejbca 6.3.1, Jboss 7.1.1, jdk 7, ant 1.9 in centos 5 32 bit.
The build seems unstable. sometimes successfully, sometimes errors.
When run "ant deploy" error in file: jboss.xml. I have check error in line:
seems to work: cli reload JBoss with CLI JBoss unstable.
But strangely, sometimes I successfully deploy.

I stepped as follows:
Config ejbca/conf/ in file: ejbca.properties, database.properties, ocsp.properties, web.properties.
Config jdk 7, ant 1.9
Config jboss: add mysql connector, pkcs#11
Please tell me I'm wrong step.
Thank you.
Reply

noobh April 21, 2016 at 3:33 PM

Hi Warren,

I want to thank you for the lengthy how‐to. All others don't come close! First time working with EJBCA. I see the last comment here was
from last year. I imagine much has changed since you posted this. Namely fixes and modifications.

I am on CentOS 7.1, 64bit. I am at the ant install section and experience a Build Failed message with the following:
/opt/ejbca_ce_6_3_1_1/build.xml:64: The following error occurred while executing this line:
/opt/ejbca_ce_6_3_1_1/build.xml:70: The following error occurred while executing this line:
/opt/ejbca_ce_6_3_1_1/bin/cli.xml:94: The following error occurred while executing this line:
/opt/ejbca_ce_6_3_1_1/bin/cli.xml:112: The following error occurred while executing this line:
/opt/ejbca_ce_6_3_1_1/bin/cli.xml:186: Java returned: 1

The below are the lines referenced above for each file: I removed the less than and greater than syntax.
Line 64 in build.xml ‐ antcall target="runinstall"
Line 70 in build.xml ‐ ant dir="${ejbca.home}/bin" antfile="cli.xml" target="ejbca:install"
Line 94 in cli.xml ‐ antcall target="ejbca:initCA"
Line 112 in cli.xml ‐ ejbca:cli‐hideargs arg="ca init "${ca.name}" "${ca.dn}" ${ca.tokentype} ${ca.tokenpassword} ${ca.keyspec}
${ca.keytype} ${ca.validity} ${ca.policy} ${ca.signaturealgorithm} ${install.catoken.command} ${install.certprofile.command} ‐
superadmincn "${superadmin.cn}""
Line 186 in cli.xml ‐ java dir="${ejbca.home}" jar="${ejbca.home}/dist/ejbca‐ejb‐cli/ejbca‐ejb‐cli.jar" fork="true" failonerror="true"

Can you give assistance with the Ant Build Failure? Thank you sir!

noobh
Reply

clickorbit June 18, 2016 at 10:25 AM

Very detailed information. Thank you for helping me in my jboss online training.
Reply

Warren V July 21, 2016 at 1:05 AM

Hello All,

After a long hiatus, I'm returning to the subject of EJBCA. A new version of the install guide using MariaDB, Java 1.8, and Wildfly 8 is in
the works.

In the meantime, I'm cleaning up a few small errors in this guide (fixing broken reference links, and a couple small bugs in the suggested
my.cnf).
Reply

Warren V July 21, 2016 at 1:06 AM

Oh, and for those who are requesting help: I'm sorry, but I can't help with particular install problems. However, if you find a bug in this
or any other guide of mine, please do let me know.
Reply

Errol July 22, 2016 at 7:48 AM

I really appreciated this tutorial. I adapted it for wildfly 10 and the latest version of ejbca but without this guide, I would never had
stood it up in my lab.
Reply

Replies

Warren V July 23, 2016 at 10:02 PM

Hello Errol,

I'm writing a Wildfly 9 version of this document right now. If you have particular changes that were made to support Wildfly
10, please forward them to me, and I will include them in the new guide.

Errol August 26, 2016 at 9:40 AM

Basically, the adaptations where taken right from the Wildfly site! https://www.ejbca.org/docs/installation.html#WildFly 10
I know the big issue for me was the the deploy kept failing because remoting wasn't enabled OOTB it seemed
I'm using Ubuntu 16.04.1 and OpenJDK 1.8

Reply

ashok a August 1, 2016 at 5:47 AM

I Installed CA server by following your blog. I am able to access https://myhttpservername:8443/ejbca/adminhweb but i'm unable to
access with out port number can you olease help me.
Reply
ashok a August 1, 2016 at 5:50 AM
I'm new to this i just followed what you said please help how can I access with out port number. I changed the web.properties file as
you said but i'm unable to access. please guide me.
Reply

ashok a August 2, 2016 at 10:57 PM

22:50:49,407 ERROR [org.jboss.web] (MSC service thread 1‐1) JBAS018211: Could not load JSF managed bean class:
org.ejbca.ui.web.admin.peerconnector.PeerConnectorMBean

I am getting this error any help??????????????

Reply

Erik Carlseen August 16, 2016 at 4:45 PM

Great guide that really helps address PrimeKey's documentation woes! I was able to adapt it to get EJBCA 6.3.1.1 running on Ubuntu
16.04 / JBoss 7.1.1 / OpenJDK 7 with one tiny change: the JAVA_HOME environment variable must be configured before running apt
install, otherwise there are issues with it finding the keytool program. Hope this tiny bit helps somebody!
Reply

Groen September 9, 2016 at 6:52 AM

thx for this tutorial. took a week to get centos installed and running. with the multiple issues introduced with Jboss, Wildfly ANT,
OpenJDK...

coming from a windows environment i sometimes ask myself. why on earth did i decide to change over... its sure as hell does not seem
worth this amount of effort.
Reply

Replies

Groen September 9, 2016 at 6:52 AM

i mean ejbca. been a long ass week

Reply

Prudence Alvardo September 13, 2016 at 11:53 PM

Thanks to share this post its all information is really great.

Property Management Software

Reply

resplond October 1, 2016 at 4:57 AM

First of all, this is hands down best tutorial on installing and configuring EJBCA, that I have came across.
I have few questions, so if you can, please reply.
1. I dont need Server signing function. Using Comodo certs for that, I need only Client auth functions for publicly accessible url‐s on my
site. That mean, that I am creating End Entity and signing it with my RootCA, right?
2. Does this tutorial assume that your EJBCA installation has to be publicly accessible as well for sake of OSCP and other things, or I can
put it in my intranet, set it up, and then manually transfer certificates, CRL‐s to publicly accessible server each time I publish new
CRL/Certificate?
3. If I don't need SSL Server keys (which I don't) do I still need to follow routine RootCA‐>SubordinateCa‐>Client certs or I can go with
RootCA‐>Client certs? Pros‐cons?
Thanks in advance
Reply

Iulian Aciobanitei October 10, 2016 at 9:08 AM

This comment has been removed by the author.
Reply

Iulian Aciobanitei October 10, 2016 at 9:22 AM

This comment has been removed by the author.
Reply
 Iulian Aciobanitei October 11, 2016 at 9:58 AM
Hello. I'm facing an error when I want to 'ant install'. 'ant deploy' works fine. The error displayed is ejbca:initCA:
[echo] Initializing CA with 'mgmtca' 'CN=mgmtca,O=Your Company,C=US' 'soft' '4096' 'RSA' '3652' 'null' 'SHA256WithRSA' ‐certprofile
ROOTCA ‐superadmincn 'superadmin'...
[java] Could not run execute method for class ca
[java] java.lang.RuntimeException: Internal admin was denied access. This should not be able to happen.
......

I found somewhere that it is a database related error, so I tried /opt/ejbca/bin/ejbca.sh ca listcas ( after successful ant deploy) and I
received somehow the same error:
java.lang.RuntimeException: Internal admin was denied access. This should not be able to happen.
........

Can anyone help?

Reply

Enter your comment...

Comment as:  Select profile...

 
Publish Preview

Newer Post Home

Subscribe to: Post Comments (Atom)

Simple template. Powered by Blogger.