Académique Documents
Professionnel Documents
Culture Documents
More NextBlog
CreateBlog SignIn
S u n d a y, A p r i l 2 7 , 2 0 1 4
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 littleknown fact that all material published on Blogger is automatically copyrighted. Not a GPL copyleft,
but a fullblown 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
NonCommercialShareAlike 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 howto 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 loadspreading 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 31661 alpha2 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 cowritten 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.
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, filebased 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 1024bit 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 8character ASCII password to an 8192bit 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 64bit CentOS 6.5 on a vm. There is a single root partition for storage, a twocore 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 javarelated 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 nonworking 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 ant1.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.733.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 mysqlconnectorjava.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 morerecent version of ejbca and Wildfly.
mysql>javasqlconnector>jboss>ejbcaCA>ejbcaVA>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 howto only covers a standalone installation. But I'll try to point out the distributed stuff as we go along.
In this howto, 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 howto.
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.
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 "selfsigned" one issued by the Management CA and
created during installation.
However, toward the end of this howto, 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
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 yumupdate
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
###Startiptables###
#Firewallconfigurationwrittenbysystemconfigfirewall
#Manualcustomizationofthisfileisnotrecommended.
*mangle
:PREROUTINGACCEPT[0:0]
:INPUTACCEPT[0:0]
:FORWARDACCEPT[0:0]
:OUTPUTACCEPT[0:0]
:POSTROUTINGACCEPT[0:0]
APREROUTINGieth0ptcpdport80jMARKsetmark0x64
APREROUTINGieth0ptcpdport442jMARKsetmark0x65
APREROUTINGieth0ptcpdport443jMARKsetmark0x66
COMMIT
*nat
:PREROUTINGACCEPT[0:0]
:OUTPUTACCEPT[0:0]
:POSTROUTINGACCEPT[0:0]
APREROUTINGieth0ptcpdport80mmarkmark0x64jDNATtodestination:8080
APREROUTINGieth0ptcpdport442mmarkmark0x65jDNATtodestination:8442
APREROUTINGieth0ptcpdport443mmarkmark0x66jDNATtodestination:8443
COMMIT
*filter
:INPUTACCEPT[0:0]
:FORWARDACCEPT[0:0]
:OUTPUTACCEPT[0:0]
AINPUTmstatestateESTABLISHED,RELATEDjACCEPT
AINPUTpicmpjACCEPT
AINPUTilojACCEPT
AINPUTieth0mstatestateNEWmtcpptcpdport8080mmarkmark0x64jACCEPT
AINPUTieth0mstatestateNEWmtcpptcpdport8442mmarkmark0x65jACCEPT
AINPUTieth0mstatestateNEWmtcpptcpdport8443mmarkmark0x66jACCEPT
AINPUTmstatestateNEWmtcpptcpdport443jACCEPT
AINPUTmstatestateNEWmtcpptcpdport22jACCEPT
AINPUTmstatestateNEWmtcpptcpdport80jACCEPT
AINPUTmstatestateNEWmtcpptcpdport442jACCEPT
AINPUTjREJECTrejectwithicmphostprohibited
AFORWARDjREJECTrejectwithicmphostprohibited
COMMIT
###Endiptables###
If you are only working in the cli, I'd manually edit /etc/sysconfig/iptables , then reload the firewall:
serviceiptablesreload
Regardless of how you do it, it's a good idea to back up the firewall config:
cp/etc/sysconfig/iptables/etc/sysconfigiptables.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/vmlinuz2.6.32431.11.2.el6.x86_64roroot=/dev/mapper/vg_rootcalv_rootrd_NO_LUKS
rd_LVM_LV=vg_rootca/lv_rootrd_NO_MDSYSFONT=latarcyrhebsun16rd_LVM_LV=vg_rootca/lv_swapKEYBOARDTYPE=pc
KEYTABLE=usrd_NO_DMLANG=en_US.UTF8rhgbquietcrashkernel=autoipv6.disable=1
It's a pretty good idea to verify our java version with javaversion , both with the implicit path and the full path you will
define as JAVA_HOME in standalone.conf : /usr/lib/jvm/java/bin/javaversion . Once this is done, you can be sure
that java works, and executes the expected version regardless of path:
/usr/lib/jvm/java/bin/javaversion
javaversion"1.6.0_30"
OpenJDKRuntimeEnvironment(IcedTea61.13.3)(rhel5.1.13.3.el6_5x86_64)
OpenJDK64BitServerVM(build23.25b01,mixedmode)
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 utf8 encoding, which is a requirement of ejbca.
The utf8 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.
mkdirp/var/log/mysql/bin
chownRmysql:mysql/var/log/mysql
chmodR750/var/log/mysql/bin
vi/etc/my.cnf
###Startmy.cnf###
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
#Disablingsymboliclinksisrecommendedtopreventassortedsecurityrisks
symboliclinks=0
#UTF8
charactersetserver=utf8
collationserver=utf8_unicode_ci
initconnect='SETNAMESutf8'
#charactersetclient=utf8
#LoggingConfig
#Binarylogging
logbin
serverid=1
log_bin=/var/log/mysql/bin/mysqlbin.log
expire_logs_days=10
max_binlog_size=100M
#log
#logerror
#logslowqueries
[mysqld_safe]
logerror=/var/log/mysql/mysqld.log
pidfile=/var/run/mysqld/mysqld.pid
#Customconfig
#[client]
#defaultcharacterset=utf8
###Endmy.cnf###
To make a point about the mysql user continuing to own everything mysqlrelated:
chownmysql: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:
servicemysqldstart
mysql_secure_installation
mysqlurootp
createdatabaseejbcadb
grantallprivilegesonejbcadb.*to'ejbcadbuser'@'localhost'identifiedby'password'
flushprivileges
exit
Verify that you can log in to mysql as ejbcadbuser and test your access:
mysqluejbcadbuserp
useejbcadb
showgrantsforejbcadbuser@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 servicemysqldrestart and checking the log at
/var/log/mysql/mysqld.log.
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.
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.
###Startstandalone.confDelta###
#ejbcaconfig
#
#javaHome=/usr/lib/jvm/java
#jbossHome=/opt/jboss
#jbossClasspath=/usr/share/java/mysql.jar
JAVA_HOME="/usr/lib/jvm/java"
JAVA_OPTS="Xms128mXmx512mXX:PermSize=128mXX:MaxPermSize=256mDjava.net.preferIPv4Stack=true
Dorg.jboss.resolver.warning=trueDsun.rmi.dgc.client.gcInterval=3600000Dsun.rmi.dgc.server.gcInterval=3600000"
###Endstandalone.confDelta###
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
###Startejbcainit.dDelta###
###BEGININITINFO
#chkconfig3459717
#Provides:ejbca
#RequiredStart:$remote_fs$syslog$networkmysqld
#RequiredStop:$remote_fs$syslog$network
#ShortDescription:ejbcajbossinstance
#Description:ejbcajbossinstance
#DefaultStart:345
#DefaultStop:0126
###ENDINITINFO
#
#processname:ejbca
#pidfile:/var/run/jbossstandalone.pid
#config:/etc/ejbca/ejbcainit.conf
JBOSS_CONF="/etc/ejbca/ejbcainit.conf"
JBOSS_HOME=/opt/jboss
prog='ejbcajbossinstance'
###Endejbcainit.dDelta###
The ejbcainit.conf file has two very important variables in it: the JBoss process username, and the logfile name.
vi/etc/ejbca/ejbcainit.conf
###Startejbcainit.conf###
#Generalconfigurationfortheinit.dscripts,
#notnecessarilyforJBossASitself.
#Theusernamewhoshouldowntheprocess.
#
JBOSS_USER=jboss
#Theamountoftimetowaitforstartup
#
#STARTUP_WAIT=10
#Theamountoftimetowaitforshutdown
#
#SHUTDOWN_WAIT=10
#Locationtokeeptheconsolelog
#
JBOSS_CONSOLE_LOG=/var/log/ejbca/console.log
###Endejbcainit.conf###
Lastly, we use chkconfig to add our services to the rc hierarchy and set the runlevels:
chkconfigaddejbca
chkconfiglevel345mysqldon
chkconfiglevel345ejbcaon
The init files should remain owned by root:root, with the default permissions.
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 CentOSdistributed version of the connector, ensure that
we have a working JBoss installation, and then deal with updating it.
First, install the CentOSdistributed version:
yuminstallmysqlconnectorjava
Now, create the directory that will hold JBoss' link to mysqlconnectorjava.jar , and the link itself:
mkdirp/opt/jboss/modules/com/mysql/main/
cd/opt/jboss/modules/com/mysql/main
lns/usr/share/java/mysqlconnectorjava.jarmysqlconnectorjava.jar
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 "chownRroot:root/opt/jboss" we want root to remain the owner of the symbolic link.
chownRjboss:jboss/opt/jbossas7.1.1.Final
Now, we test how well our init scripting works:
serviceejbcastart
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.
tailf/var/log/ejbca/console.log
You should see something like this at the end of the file:
22:51:40,482INFO[org.apache.coyote.http11.Http11Protocol](MSCservicethread12)StartingCoyoteHTTP/1.1on
http127.0.0.18080
22:51:40,688INFO[org.jboss.as.remoting](MSCservicethread13)JBAS017100:Listeningon/127.0.0.1:4447
22:51:40,690INFO[org.jboss.as.remoting](MSCservicethread12)JBAS017100:Listeningon/127.0.0.1:9999
22:51:40,699INFO[org.jboss.as.server.deployment.scanner](MSCservicethread13)JBAS015012:Started
FileSystemDeploymentServicefordirectory/opt/jboss/standalone/deployments
22:51:40,773INFO[org.jboss.as](ControllerBootThread)JBAS015951:Adminconsolelisteningon
http://127.0.0.1:9990
22:51:40,774INFO[org.jboss.as](ControllerBootThread)JBAS015874:JBossAS7.1.1.Final"Brontes"startedin
1528msStarted130of204services(74servicesarepassiveorondemand)
:reload
exit
This cli action defines our mysql driver in /opt/jboss/standalone/configuration/standalone.xml, then reloads JBoss.
The actual definition is:
###Startstandalone.xmlSnip###
<drivername="com.mysql.jdbc.Driver"module="com.mysql">
<xadatasourceclass>com.mysql.jdbc.jdbc.jdbc2.optional.MysqlXADataSource</xadatasourceclass>
</driver>
###Endstandalone.xmlSnip###
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,580INFO[org.jboss.as.connector.subsystems.datasources](ServerServiceThreadPool27)JBAS010404:
DeployingnonJDBCcompliantdriverclasscom.mysql.jdbc.Driver(version5.1)
Note that this h2 db instance is an ephemeral "inmemory" database which does not store data on disk, does not provide
external TCP/IP connectivity, and can pretty much be ignored.
vistandalone.xml
###Startstandalone.xmlDelta###
Also remove:
<drivername="h2"module="com.h2database.h2">
<xadatasourceclass>org.h2.jdbcx.JdbcDataSource</xadatasourceclass>
</driver>
###Endstandalone.xmlDelta###
Now, if you watch the console log when restarting JBoss, you should no longer see:
22:46:29,570INFO[org.jboss.as.connector.subsystems.datasources](ServerServiceThreadPool27)JBAS010403:
DeployingJDBCcompliantdriverclassorg.h2.Driver(version1.3)
Once this is done, JBoss will fail to load the connector at startup, as shown in the console log:
01:16:31,500ERROR[org.jboss.as.controller.managementoperation](managementhandlerthread17)JBAS014612:
Operation("add")failedaddress:([
("subsystem"=>"datasources"),
("jdbcdriver"=>"com.mysql.jdbc.Driver")
]):org.jboss.msc.service.DuplicateServiceException:Servicejboss.jdbcdriver.com_mysql_jdbc_Driverisalready
registered
The fix for this is quite simple: add a single line to standalone.xml to update the driver stanza:
###Startstandalone.xmlDelta###
<datasources>
<drivers>
<drivername="com.mysql.jdbc.Driver"module="com.mysql">
<driverclass>com.mysql.jdbc.Driver</driverclass>
<xadatasourceclass>com.mysql.jdbc.jdbc.jdbc2.optional.MysqlXADataSource</xadatasource
class>
</driver>
</drivers>
</datasources>
###Endstandalone.xmlDelta###
Restart the service, and the updated connector now loads properly.
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 JBossspecific 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 autopopulated 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 antinstall 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 antbuild and antinstall, 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 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 runningantinstall, 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 "antinstall" 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
vapublisher.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
mkdirsample
mv*.samplesample
Now we copy a specific subset of files back to the main directory:
cpsample/certstore.properties.samplecertstore.properties
cpsample/cesecore.properties.samplecesecore.properties
cpsample/crlstore.properties.samplecrlstore.properties
cpsample/database.properties.sampledatabase.properties
cpsample/ejbca.properties.sampleejbca.properties
cpsample/install.properties.sampleinstall.properties
cpsample/mail.properties.samplemail.properties
cpsample/web.properties.sampleweb.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. Doublecheck the syntax in each file before applying!
certstore.properties
###Startcertstore.properties###
#RFC4387Certificatestoreconfiguration
certstore.enabled=true
#Thisisthewebdirectorythatthewebinterfaceforthecertstorewilluse.
#Itisnotthefullpath!
certstore.contextroot=/certificates
#Thisisanunusedalternatelocation
#certstore.contextroot=/ejbca/publicweb/certificates
###Endcertstore.properties###
cesecore.properties
###Startcesecore.properties###
#allow.externaldynamic.configuration=false
#Youdonotneedtoconfigurethispassword!
#ca.keystorepass=!secret!
#ca.rngalgorithm=SHA1PRNG
#ca.serialnumberoctetsize=8
ca.toolateexpiredate=80000000
#ca.toolateexpiredate=2038011903:14:08+00:00
#ca.doPermitExtractablePrivateKeys=true
#forbidden.characters=\n\r!\u0000%`?$~
#intresources.preferredlanguage=EN
#intresources.secondarylanguage=SE
#Thesevariableswillenableexplicitlogging.Youcanturnthemofflater
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
#Morelogconfigbelow
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
###Endcesecore.properties###
crlstore.properties
###Startcrlstore.properties###
#Thisisallverysimilartocertstore.properties
#RFC4387CRLstoreconfiguration
crlstore.enabled=true
crlstore.contextroot=/crls
#crlstore.contextroot=/ejbca/publicweb/crls
###Endcrlstore.properties###
database.properties
###Startdatabase.properties###
#Databaseconfiguration
#Thisvariableisusedinourstandalone.xml<datasource>stanza
datasource.jndiname=EjbcaDS
#ThisistheTYPEofdb,nottheNAMEOFthedb
database.name=mysql
#Besuretouseutf8
database.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF8
database.driver=com.mysql.jdbc.Driver
database.username=ejbcadbuser
#Changethistoyourmysqluserpassword:
database.password=pumpkin
###Enddatabase.properties###
ejbca.properties
###Startejbca.properties###
#Thenexttwovariablesareveryimportant...
appserver.home=/opt/jboss
appserver.type=jboss
#Initially,wewillsetthistofalse.Oncetheinstalliscomplete,wechange
#thistotrue.
#ButDONOTsetitto"ca"!
#ejbca.productionmode=true
ejbca.productionmode=false
#allow.externaldynamic.configuration=false
#Don'tsetthese!
#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=Select1FromCertificateDatawherefingerprint='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'simportanttochangethisto8:
ejbca.passwordlogrounds=8
###Endejbca.properties###
install.properties
###Thisfileisessentiallyan"answerfile"usedwhenrunningthe"antinstall"command.
###Thevariableslistedhereare*not*usedbyejbcawhileitisrunning.
###Startinstall.properties###
#Ineverycasethat"CA"ismentionedinthisfile,itreferstothe"management"CAONLY.
#ThiswillbetheinitialnameofthemanagementCAinstance
#ejbcawillusethisforadministrationpurpose,notyourproductionCAs
#NotethattheCNgivenhereisNOTtheFQDNofyourCA!
#Whydoesthismatter?Thiscertificatewillbetemporarilyinstalled
#onyourbrowserasatrustedrootCA,butwillnotbecommunicated
#with.
ca.name=mgmtca
ca.dn=CN=mgmtca,O=YourCompany,C=US
ca.tokentype=soft
ca.tokenpassword=null
#Thisisthepathtoa"catoken.properties"filethatwillbecreatedwhen'ant
#install'isrun.ItwillcontainencryptionparametersusedbythemgmtCA.
#Itisonlyusedwithhardencryptiontokens,andcanbeignoredifyourcerts
#willbestoredintheejbcadatabase(whichiswerewewillbeputtingthem.)
#ca.tokenproperties=/opt/ejbca/conf/catoken.properties
#THISISIMPORTANT
#YoucanassumethatejbcacannotuseECalgorithmsforthemanagementCA.
#ThisdoesnotmeanthatejbcacannotissuecertificatesthatuseEC.
#ItjustmeansthatthemanagementCAwilluseRSAforinternalpurposes.
#ThereasonforthislimitationisthatthevariousECalgorithmsare
#notequallysupportedbythevariousjavaflavorsthatcouldbeused.
#Moreimportantly,ejbcadoesnotincludeanysortoflogictoidentify
#theversionofjavayouareusingtolimitorcorrectyouroptions.
#Choosinganunsupportedalgorithmhereleadstoacorruptinstallation.
#Thiscanwasteagreatamountoftime,sojustavoidEC.
#YoucanuseEClaterwiththeactualproductionCAsyoudefine.
#KeyspecforRSAkeysissizeofRSAkeys(1024,2048,4096,8192).
ca.keyspec=4096
#ThekeytypefortheadministrativeCA,canbeRSA,ECDSAorDSA
ca.keytype=RSA
#EventhoughSHA1isstilllargelyinuseasacertificatehashing
#algorithm,I*strongly*suggestthatyougowithSHA256WithRSA.
#Also,pleasenotethatthe"with/With"inthehashnamesisindeedcasesensitive.
#Stayclassy,Oracle.
#SHA1WithRSA,SHA1withECDSA,SHA256WithRSA,SHA256withECDSA.
ca.signaturealgorithm=SHA256WithRSA
#IsetaCAvalidityof10years(includingtheleapyears,rainman)
ca.validity=3652
ca.policy=null
ca.certificateprofile=ROOTCA
###Endinstall.properties###
mail.properties
###Startmail.properties###
#Thisconfigisfortheejbcaapplicationmailer,notthejbossmailer.Wewill
#setthatuplater.Fornow,wejustpointtothelocalmailserverinorderto
#preventerrorsintheconsolelog.
mail.jndiname=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=UTF8
###Endmail.properties###
web.properties
###Startweb.properties###
#Thekeytothisportionoftheconfigisunderstandingthatthisfileaffects
#thecertificateusedbytheejbcaadminwebpage.Ininstall.properties,we
#definedvariablesforthemanagementCArootcertificate.Butthatcertificate
#isnotusedforsessionTLS.ThemanagementCAissuesaseparate"server
#certificate"forthatpurposethatisdefinedhere.
#WebGUIconfiguration
#Cannotbesettofalse,commentedawaymeansthatwebwillbeconfigured.
#web.noconfigure=true
#Cannotbesettofalse,commentedawaymeansthatwebwillbeconfigured.
#web.nosslconfigure=true
#Youdonotneedtosetthispassword!
#java.trustpassword=changeit
superadmin.cn=superadmin
superadmin.dn=CN=${superadmin.cn},O=YourCompany,C=US
#Youdonotneedtosetthispassword!
#superadmin.password=ejbca
superadmin.batch=true
#Youdonotneedtosetthispassword!
#httpsserver.password=serverpwd
httpsserver.hostname=rootca.yourdomain.net
httpsserver.dn=CN=${httpsserver.hostname},O=YourCompany,C=US
#ThisistheportthatwillhosttheunencryptedEjbcaPublicWebpage.
#NotethatthiswillbeusedtheCRLandOSCPURLs,althoughitwillbeNATtedtoport80byourfirewallrules.
httpserver.pubhttp=8080
#ThisistheportthatwillhosttheencryptedEjbcaPublicWebpage,*without*clientcertificateauthentication.
httpserver.pubhttps=8442
#ThisistheportthatwillhosttheencryptedEjbcaPublicWebpage,
#aswellastheAdministrationpage.Accessingcontenthostedon
#thisportrequiresclientcertificateauthentication.
#NotethattheEjbcaPublicWebpagelinktotheadministration
#pagewilltrytoincludethisportintheURL,regardlessofany
#portredirectionyoumaybeusing.Thiswillfixedattheendof
#thehowto.
httpserver.privhttps=8443
#Tryingtouseport443willnotworkhere,asitisa"privileged"port.
#httpserver.external.privhttps=443
#Don'tsettheseupunlessyouuseanapacheproxyforporttranslation
#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
#WholettheSwedesinhere?
#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=UTF8
#Well,thisdoesn'tsoundlikeagoodidea.
#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=Usercertificate
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=Anexceptionhasoccurred.
web.errorpage.notification=ZOMGPWND!!111!!!1!!!1
#Thissettingisgoodforalabenvironment.Don'tusethisinproduction.
web.errorpage.stacktrace=true
#web.enableproxiedauth=true
web.log.adminremoteip=true
#web.log.adminforwardedip=true
###Endweb.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:
tailf/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.
serviceejbcastop
chownRjboss:jboss/opt/jbossas7.1.1.Final
chownRjboss:jboss/opt/ejbca_ce_6_1_1
serviceejbcastart
cd/opt/ejbca
sudoujbossantdeploy
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:
displayproperties:
[echo]
[echo]EJBCA6.1.1(workingcopy)CONFIGURATIONPROPERTIES
[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=YourCompany,C=US
[echo]ocsp.signaturealgorithm=SHA1WithRSASHA1WithECDSASHA1WithDSA
[echo]datasource.jndiname=EjbcaDS
[echo]datasource.jndinameprefix=java:/
[echo]database.name=mysql
[echo]database.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF8
[echo]database.driver=com.mysql.jdbc.Driver
[echo]database.username=ejbcadbuser
[echo]database.password=***
[echo]database.useSeparateCertificateTable=false
[echo]database.valid.connection.sql=select1
[echo]mail.jndiname=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=UTF8
[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
This message refers to the fact that the community version of ejbca does not support database integrity protection:
06:06:13,175INFO[org.cesecore.dbprotection.ProtectedData](MSCservicethread14)Nodatabaseintegrity
protectionavailableinthisversionofEJBCA.
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,724INFO[org.jboss.as](MSCservicethread11)JBAS015874:JBossAS7.1.1.Final"Brontes"startedin
7761msStarted2855of2968services(111servicesarepassiveorondemand)
01:38:38,769INFO[org.jboss.as.server](DeploymentScannerthreads2)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
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,480SEVERE[javax.enterprise.resource.webcontainer.jsf.application](MSCservicethread14)JSF1051:
Serviceentry'org.jboss.as.web.deployment.jsf.JsfInjectionProvider'doesnotextendDiscoverableInjectionProvider.
Entrywillbeignored.
06:31:43,811INFO[org.jboss.as.controller](ControllerBootThread)JBAS014774:Servicestatusreport
JBAS014777:Serviceswhichfailedtostart:servicejboss.web.connector.httpspub:
org.jboss.msc.service.StartExceptioninservicejboss.web.connector.httpspub:
JBAS018007:Errorstartingwebconnectorservicejboss.web.connector.httpspriv:org.jboss.msc.service.StartException
inservicejboss.web.connector.httpspriv:
JBAS018007:Errorstartingwebconnector
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 outofmemory errors that jboss can occasionally throw.
If you do happen to lock up jboss with an outofmemory condition, just "kill9" the jboss process and do a service
ejbcarestart. 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:
serviceejbcarestart
cd/opt/ejbca
sudoujbossantinstall
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 crossserver 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/jre1.6.0openjdk.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 fullyfunctioned 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, antinstall 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, antinstall 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:
PleaseenterthepasswordofthetruststorewiththeCAcertificateforhttps?[changeit]
PleaseenterthepasswordofthekeystorewiththeTLSkeyforhttps[serverpwd]
(and later)
Pleaseenterthesuperadminpassword(default:ejbca)?[ejbca]
While keystore creation is taking place, antinstall will return messages like these:
[echo]InitializingCAwith'mgmtCA''CN=mgmtca,O=YourCompany,C=US''soft'<ca.tokenpasswordhidden>'4096''RSA'
'3650''null''SHA384withRSA'/home/ejbca/conf/catoken.propertiessuperadmincn'SuperAdmin'...
After this, you will see another summary stanza describing the management CA being created:
[echo]
[echo]CAProperties
[echo]ca.name:mgmtca
[echo]ca.dn:CN=mgmtca,O=YourCompany,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=YourCompany,C=US
[echo]superadmin.cn:superadmin
[echo]superadmin.dn:CN=superadmin,O=YourCompany,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), antinstall will return a message
like:
[java]org.ejbca.ui.cli.ErrorAdminCommandException:org.cesecore.certificates.ca.InvalidAlgorithmException:
SignaturealgorithmSHA384withRSAisnotoneoftheallowedsignaturealgorithms.Availablealgorithms:
{SHA1WithRSA,SHA256WithRSA,SHA384WithRSA,SHA512WithRSA,SHA256WithRSAAndMGF1,
SHA1withECDSA,SHA224withECDSA,SHA256withECDSA,SHA384withECDSA,SHA1WithDSA,
GOST3411withECGOST3410,GOST3411withDSTU4145}.
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 antinstall puts together. You can infer this syntax from the messages
given in the ant console output.
/ejbca/publicweb/apply
06:20:59,491INFO[org.jboss.web](MSCservicethread13)JBAS018210:Registeringwebcontext:
/ejbca/publicweb/webdist
06:20:59,506INFO[org.jboss.web](MSCservicethread13)JBAS018210:Registeringwebcontext:/ejbca/publicweb
06:20:59,516INFO[org.jboss.web](MSCservicethread13)JBAS018210:Registeringwebcontext:
/ejbca/publicweb/healthcheck
06:20:59,521INFO[org.jboss.web](MSCservicethread13)JBAS018210:Registeringwebcontext:/ejbca/clearcache
06:20:59,521INFO[org.jboss.web](MSCservicethread13)JBAS018210:Registeringwebcontext:/ejbca/ejbcaws
06:20:59,571INFO[org.jboss.web](MSCservicethread14)JBAS018210:Registeringwebcontext:/ejbca
06:20:59,727INFO[org.jboss.web](MSCservicethread11)JBAS018210:Registeringwebcontext:/crls
06:20:59,728INFO[org.jboss.web](MSCservicethread12)JBAS018210:Registeringwebcontext:/certificates
06:21:00,141INFO[org.jboss.web](MSCservicethread13)JBAS018210:Registeringwebcontext:/ejbca/adminweb
06:21:16,576INFO[org.jboss.web](MSCservicethread11)JBAS018210:Registeringwebcontext:/ejbca/doc
WSDLpublishedto:file:/opt/jbossas7.1.1.Final/standalone/data/wsdl/ejbca.ear/ejbcaws
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 "BUILDSUCCESSFUL"):
06:31:43,812ERROR[org.jboss.as](ControllerBootThread)JBAS015875:JBossAS7.1.1.Final"Brontes"started(with
errors)in162msStarted135of218services(2servicesfailedormissingdependencies,80servicesarepassive
orondemand)
###Startstandalone.xmlDelta###
Remove:
<subsystemxmlns="urn:jboss:domain:web:1.1"defaultvirtualserver="defaulthost"native="false">
<connectorname="http"protocol="HTTP/1.1"scheme="http"socketbinding="http"redirectport="8443"/>
<connectorname="httpspriv"protocol="HTTP/1.1"scheme="https"socketbinding="httpspriv"secure="true">
<sslkeyalias="rootca.yourcompany.net"password="blahblahblah"certificatekey
file="/opt/jboss/standalone/configuration/keystore/keystore.jks"verifyclient="true"cacertificate
file="/opt/jboss/standalone/configuration/keystore/truststore.jks"cacertificatepassword="blahblahblah"/>
</connector>
<connectorname="httpspub"protocol="HTTP/1.1"scheme="https"socketbinding="httpspub"secure="true">
<sslkeyalias="rootca.yourcompany.net"password="blahblahblah"certificatekey
file="/opt/jboss/standalone/configuration/keystore/keystore.jks"/>
</connector>
<virtualservername="defaulthost"enablewelcomeroot="true">
<aliasname="localhost"/>
<aliasname="example.com"/>
</virtualserver>
</subsystem>
###Endstandalone.xmlDelta###
serviceejbcastart
sudoujbossantclean
sudoujbossantdeploy
sudoujbossantinstall
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:
*****************WARNINGWARNINGWARNING*****************
*Theintegrityoftheinformationstoredinyourkeystore*
*hasNOTbeenverified!Inordertoverifyitsintegrity,*
*youmustprovideyourkeystorepassword.*
*****************WARNINGWARNINGWARNING*****************
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,566ERROR[org.apache.tomcat.util.net.jsse.JSSESocketFactory](MSCservicethread14)Failedtoload
keystoretypeJKSwithpath/opt/jboss/standalone/configuration/keystore/keystore.jksduetoKeystorewastampered
with,orpasswordwasincorrect:java.io.IOException:Keystorewastamperedwith,orpasswordwasincorrect
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):
###Startkeystore.jks###
Keystoretype:JKS
Keystoreprovider:SUN
Yourkeystorecontains2entriesAliasname:cacert
Creationdate:Apr26,2014
Entrytype:trustedCertEntry
Owner:C=US,O=YourCompany,CN=mgmtca
Issuer:C=US,O=YourCompany,CN=mgmtca
Serialnumber:1e1369e62435a307
Validfrom:SatApr2606:20:16GMT08:002014until:TueApr2306:20:16GMT08:002024
Certificatefingerprints:
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
Signaturealgorithmname:SHA256withRSA
Version:3
Extensions:
#1:ObjectId:2.5.29.15Criticality=true
KeyUsage[
DigitalSignature
Key_CertSign
Crl_Sign
]
...
]
*******************************************
*******************************************
Aliasname:rootca.yourcompany.net
Creationdate:Apr26,2014
Entrytype:PrivateKeyEntry
Certificatechainlength:2
Certificate[1]:
Owner:C=US,O=YourCompany,CN=rootca.yourcompany.net
Issuer:C=US,O=YourCompany,CN=mgmtca
Serialnumber:5a797a3381345da2
Validfrom:SatApr2606:10:21GMT08:002014until:MonApr2506:10:21GMT08:002016
Certificatefingerprints:
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
Signaturealgorithmname:SHA256withRSA
Version:3
Extensions:
#1:ObjectId:2.5.29.15Criticality=true
KeyUsage[
DigitalSignature
Key_Encipherment
]
...
]
Certificate[2]:
Owner:C=US,O=YourCompany,CN=MgmtCA
Issuer:C=US,O=YourCompany,CN=MgmtCA
Serialnumber:1e1369ef834ea307
Validfrom:SatApr2606:20:16GMT08:002014until:TueApr2306:20:16GMT08:002024
Certificatefingerprints:
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
Signaturealgorithmname:SHA256withRSA
Version:3
Extensions:
#1:ObjectId:2.5.29.15Criticality=true
KeyUsage[
DigitalSignature
Key_CertSign
Crl_Sign
]
...
]
*******************************************
*******************************************
###Endkeystore.jks###
The truststore.jks file contains the keys of all authorities trusted by jboss, which initially is only the management CA:
###Starttruststore.jks###
Keystoretype:JKS
Keystoreprovider:SUN
Yourkeystorecontains1entry
Aliasname:mgmtca
Creationdate:Apr26,2014
Entrytype:trustedCertEntry
Owner:C=US,O=YourCompany,CN=mgmtca
Issuer:C=US,O=YourCompany,CN=mgmtca
Serialnumber:1e1369ef834ea307
Validfrom:SatApr2606:20:16GMT08:002014until:TueApr2306:20:16GMT08:002024
Certificatefingerprints:
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
Signaturealgorithmname:SHA256withRSA
Version:3
Extensions:
#1:ObjectId:2.5.29.15Criticality=true
KeyUsage[
DigitalSignature
Key_CertSign
Crl_Sign
]
...
]
*******************************************
*******************************************
###Endtruststore.jks###
If your outputs vary wildly from what is shown above, you will need to go back and revalidate your properties files, then reinstall
mysql>javasqlconnector>jboss>ejbcaCA>ejbcaVA>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 vapublisher.properties file.
Like the CA datasource, the VA datasource configuration will be added to standalone.xml during deployment (once
the VAspecific .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 vapublisher.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 validationrelated properties files in the
/opt/ejbca/conf directory:
cpsample/ocsp.properties.sampleocsp.properties
cpsample/va.properties.sampleva.properties
cpsample/vapublisher.properties.samplevapublisher.properties
ocsp.properties
###Startocsp.properties###
#OCSPresponderconfiguration
ocsp.enabled=true
#ocsp.enabled=false
#ThisisthepathfortheOCSPURL
ocsp.contextroot=/ejbca/publicweb/status
#ocsp.contextroot=/status
#ThisistheDNoftheCAthatwillrespondtorequestsforunknowncerts
ocsp.defaultresponder=CN=defaultca,O=YourCompany,C=US
ocsp.includecertchain=true
ocsp.includesignercert=true
ocsp.responderidtype=keyhash
ocsp.signaturealgorithm=SHA1WithRSASHA1WithECDSASHA1WithDSA
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.trxlog=true
ocsp.logdate=yyyyMMdd:HH:mm:ss:z
#ocsp.logtimezone=GMT
#ocsp.trxlogpattern=\\$\\{(.+?)\\}
#Thenextlinewillprobablylinewrapinyourbrowser:
#ocsp.trxlogorder=
${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}0000000"${ISSUER_NAME_DN}"${ISSUER_NAME
_HASH}${ISSUER_KEY}${DIGEST_ALGOR}${SERIAL_NOHEX}${CERT_STATUS}
ocsp.auditlog=true
#ocsp.auditlogpattern=\\$\\{(.+?)\\}
#Thenextlinewillprobablylinewrapinyourbrowser:
#ocsp.auditlogorder=SESSION_ID:${SESSION_ID}LOGID:${LOG_ID}"${LOG_TIME}"REPLYTIME:${REPLY_TIME}\nTIMETO
PROCESS:${PROCESS_TIME}\nOCSPREQUEST:\n"${OCSPREQUEST}"\nOCSPRESPONSE:\n"${OCSPRESPONSE}"\nSTATUS:${STATUS}
#ocsp.logsafer=true
###Endocsp.properties###
va.properties
###Startva.properties###
#ValidationAuthority(VA)Healthchecksettings
ocsphealthcheck.signtest=true
ocsphealthcheck.checkSigningCertificateValidity=true
#PrimeKey'sinstructionshereareparticularlyterrible.LetmeseeifIcantranslate:
#Inthislastsetting,wewilldefineanalias'root'foraparticularRFC4985Section2.1"SearchKeyIDHash"or
"sKIDHash"
#OurexamplesKIDHashis:'O4RdnGNf3WPioslAQsX71aR1/MI'
#sKIDHashesareuniquetoeachCAinstancethatyourunonyourejbcaserver.
#ThishastheeffectofmakingthefollowingURLsequivalent.Thissimplifiestheentriesinyourcertificatesthat
specify
#CRL/OCSPdownloadlocations,andgrantstheabilitytohavesimultaneousCRL/OCSPdownloadURLs
#Typically,youwilldefineauniquesKIDHashaliasforeachofyourCAinstances.
#ExampleURLforcertificatesearch:http://myhost.com:8080/certificates/search.cgi?
sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI
#Thiswillbethesameashttp://myhost.com:8080/certificates/search.cgi?alias=root
#ExampleURLforCRLdownload:http://myhost.com:8080/crls/search.cgi?sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI
#isthesameashttp://myhost.com:8080/crls/search.cgi?alias=root
#ExampleURLforDeltaCRLdownload:http://myhost.com:8080/crls/search.cgi?
sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI&delta=
#isthesameashttp://myhost.com:8080/crls/search.cgi?alias=root&delta=
#Todeterminethehashtousehere,navigatetohttp://yourhost.com:8080/crls/search.cgior
http://yourhost.com:8080/certificates/search.cgi
#(Omitthe:8080ifyouarebrowsingfromsomewhereotherthanlocalhost)
#ThisURLwillgiveyoualistoftheuniquevalidationidentifiers(includingthesKIDHash)foreachofyour
definedCAs.
#CopythesKIDHashesfortheCAinstances.Remember,youwillhavemorethanone,andyoucanomittheManagement
CAasitissolelyinternaltoejbca.
#AddanentryliketheonebelowforeachofyourCAs,pastethesKIDHashintotheentry,thenredeployejbca.
#va.sKIDHash.alias.root=O4RdnGNf3WPioslAQsX71aR1/MI
###Endva.properties###
vapublisher.properties
###Startvapublisher.properties###
#ValidationAuthority(VA)publisherdbconfiguration
#Allthe"ocspdatabase.*"propertiesareusedtoconfiguretheVAconnectiontothedatabase.
#
#In"PrimeKeyese":ConfiguretheseoptionsifyouareconfiguringEJBCAthatwillpublish
#certificatestoaVA.
ocspdatasource.jndiname=OcspDS
ocspdatabase.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF8
ocspdatabase.driver=com.mysql.jdbc.Driver
ocspdatabase.username=ejbcadbuser
#Setyourdatabaseuserpasswordhere
ocspdatabase.password=pumpkin
###Endvapublisher.properties###
To enable the VA, we perform the same set of commands we ran before our initial deployment:
serviceejbcastop
chownRjboss:jboss/opt/jbossas7.1.1.Final
chownRjboss:jboss/opt/ejbca_ce_6_1_1
serviceejbcastart
cd/opt/ejbca
sudoujbossantdeploy
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 howto. 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,379INFO[org.cesecore.certificates.ocsp.cache.OcspSigningCache](MSCservicethread14)DefaultOCSP
responderwithsubject'CN=defaultca'wasnotfound.OCSPrequestsforcertificatesissuedbyunknownCAswillfail
withresponsecode2(internalerror).
Lastly, if for whatever reason you have problems with your vapublisher.properties file, you may see the following warning:
06:31:45,632WARN[org.ejbca.core.protocol.certificatestore.CertificateCache](MSCservicethread12)
org.bouncycastle.ocsp.OCSPException:problemcreatingID:java.security.NoSuchProviderException:nosuchprovider:
BC
"BC" is the default bouncycastle (the OCSP java module) instance name.
Administration Homepage
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:
SECGNAME SECG "nickname" of the elliptic curve variant
SIZE length in bits of the field order
RSAEQ 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
++++++
|SECGNAME|SIZE|RSAEQ|CURVE|NIST|
++++++
|sect163k1|163||Koblitz|K163|
|sect163r1|163||Random||
|sect163r2|163||Random|B163|
|sect193r1|193||Random||
|sect193r2|193||Random||
|sect233k1|233||Koblitz|K233|
|sect233r1|233||Random|B233|
|sect239k1|239||Koblitz||
|sect283k1|283||Koblitz|K283|
|sect283r1|283||Random|B283|
|sect409k1|409||Koblitz|K409|
|sect409r1|409||Random|B409|
|sect571k1|571||Koblitz|K571|
|sect571r1|571||Random|B571|
|secp160k1|160|1024|Koblitz||
|secp160r1|160|1024|Random||
|secp160r2|160|1024|Random||
|secp192k1|192|1536|Koblitz||
|secp192r1|192|1536|Random|P192|
|secp224k1|224|2048|Koblitz||
|secp224r1|224|2048|Random|P224|
|secp256k1|256|3072|Koblitz||
|secp256r1|256|3072|Random|P256|
|secp384r1|384|7680|Random|P384|
|secp521r1|521|15360|Random|P521|
++++++
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|
++++
In the Firefox viewer, the full set of included fields can be viewed in the "Details" tab:
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: (2048bit 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:
The Root CA uses fewer fields than the Gmail certificate, and uses 2048bit RSA encryption:
Version: 3
Serial Number: 02:34:56 (this is not a typo)
Certificate Signature Algorithm: SHA1 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: (2048bit number)
Certificate Basic Constraints: Is a Certificate Authority, Unlimited Intermediate CAs
Certificate Subject Key ID: (160bit number)
Certificate Authority Key ID: (the same 160bit number)
Certificate Signature Value: (2048bit number)
These certificates will be used as templates for defining the fields in our initial Profiles, CAs, and certificates.
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.
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 prepopulated 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 192512 bit lengths to support EC
requests, and 20488192 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 SHA1 is still the defacto 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
todate CRL.
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 TLScapable 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 userspecific
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 howto: "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.
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:
Then, select "Create New", which will take you to the New 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. "Autoactivation" should also be enabled.
The Crypto Token must be populated with a basic set of keys before we can use it:
Basic CA Keys
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 SHA1.
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 healthchecked, as defined in va.properties.
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 Devicespecific 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.
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==
ENDRSAPRIVATEKEY
catserver.csr
BEGINCERTIFICATEREQUEST
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
ENDCERTIFICATEREQUEST
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.
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]~#opensslversion
OpenSSL0.9.8y5Feb2013
[root@bsdbox]~#opensslecparamlist_curves
secp112r1:SECG/WTLScurveovera112bitprimefield
secp112r2:SECGcurveovera112bitprimefield
secp128r1:SECGcurveovera128bitprimefield
secp128r2:SECGcurveovera128bitprimefield
secp160k1:SECGcurveovera160bitprimefield
secp160r1:SECGcurveovera160bitprimefield
secp160r2:SECG/WTLScurveovera160bitprimefield
secp192k1:SECGcurveovera192bitprimefield
secp224k1:SECGcurveovera224bitprimefield
secp224r1:NIST/SECGcurveovera224bitprimefield
secp256k1:SECGcurveovera256bitprimefield
secp384r1:NIST/SECGcurveovera384bitprimefield
secp521r1:NIST/SECGcurveovera521bitprimefield
prime192v1:NIST/X9.62/SECGcurveovera192bitprimefield
prime192v2:X9.62curveovera192bitprimefield
prime192v3:X9.62curveovera192bitprimefield
prime239v1:X9.62curveovera239bitprimefield
prime239v2:X9.62curveovera239bitprimefield
prime239v3:X9.62curveovera239bitprimefield
prime256v1:X9.62/SECGcurveovera256bitprimefield
sect113r1:SECGcurveovera113bitbinaryfield
sect113r2:SECGcurveovera113bitbinaryfield
sect131r1:SECG/WTLScurveovera131bitbinaryfield
sect131r2:SECGcurveovera131bitbinaryfield
sect163k1:NIST/SECG/WTLScurveovera163bitbinaryfield
sect163r1:SECGcurveovera163bitbinaryfield
sect163r2:NIST/SECGcurveovera163bitbinaryfield
sect193r1:SECGcurveovera193bitbinaryfield
sect193r2:SECGcurveovera193bitbinaryfield
sect233k1:NIST/SECG/WTLScurveovera233bitbinaryfield
sect233r1:NIST/SECG/WTLScurveovera233bitbinaryfield
sect239k1:SECGcurveovera239bitbinaryfield
sect283k1:NIST/SECGcurveovera283bitbinaryfield
sect283r1:NIST/SECGcurveovera283bitbinaryfield
sect409k1:NIST/SECGcurveovera409bitbinaryfield
sect409r1:NIST/SECGcurveovera409bitbinaryfield
sect571k1:NIST/SECGcurveovera571bitbinaryfield
sect571r1:NIST/SECGcurveovera571bitbinaryfield
c2pnb163v1:X9.62curveovera163bitbinaryfield
c2pnb163v2:X9.62curveovera163bitbinaryfield
c2pnb163v3:X9.62curveovera163bitbinaryfield
c2pnb176v1:X9.62curveovera176bitbinaryfield
c2tnb191v1:X9.62curveovera191bitbinaryfield
c2tnb191v2:X9.62curveovera191bitbinaryfield
c2tnb191v3:X9.62curveovera191bitbinaryfield
c2pnb208w1:X9.62curveovera208bitbinaryfield
c2tnb239v1:X9.62curveovera239bitbinaryfield
c2tnb239v2:X9.62curveovera239bitbinaryfield
c2tnb239v3:X9.62curveovera239bitbinaryfield
c2pnb272w1:X9.62curveovera272bitbinaryfield
c2pnb304w1:X9.62curveovera304bitbinaryfield
c2tnb359v1:X9.62curveovera359bitbinaryfield
c2pnb368w1:X9.62curveovera368bitbinaryfield
c2tnb431r1:X9.62curveovera431bitbinaryfield
wapwsgidmecidwtls1:WTLScurveovera113bitbinaryfield
wapwsgidmecidwtls3:NIST/SECG/WTLScurveovera163bitbinaryfield
wapwsgidmecidwtls4:SECGcurveovera113bitbinaryfield
wapwsgidmecidwtls5:X9.62curveovera163bitbinaryfield
wapwsgidmecidwtls6:SECG/WTLScurveovera112bitprimefield
wapwsgidmecidwtls7:SECG/WTLScurveovera160bitprimefield
wapwsgidmecidwtls8:WTLScurveovera112bitprimefield
wapwsgidmecidwtls9:WTLScurveovera160bitprimefield
wapwsgidmecidwtls10:NIST/SECG/WTLScurveovera233bitbinaryfield
wapwsgidmecidwtls11:NIST/SECG/WTLScurveovera233bitbinaryfield
wapwsgidmecidwtls12:WTLScurvsovera224bitprimefield
OakleyEC2N3:
IPSec/IKE/Oakleycurve#3overa155bitbinaryfield.
NotsuitableforECDSA.
Questionableextensionfield!
OakleyEC2N4:
IPSec/IKE/Oakleycurve#4overa185bitbinaryfield.
NotsuitableforECDSA.
Questionableextensionfield!
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 commonlyimplemented in EC cryptography.
The first command creates the Private Key:
opensslecparamouteckey.keynameprime256v1genkey
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:
opensslreqnewkeyeckey.keynodessha256outformpemoutecreq.csr
The new command options are:
new A new CSR will be created
keyeckey.key The new CSR will be derived from the Private Key in eckey.key
outformpem 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:
cateckey.key
BEGINECPARAMETERS
BggqhkjOPQMBBw==
ENDECPARAMETERS
BEGINECPRIVATEKEY
MHcCAQEEIDtrKu6BbwPabNV0SkbYqdLiRImoyzQ94VR8KdzqgfoGoAoGCCqGSM49
AwEHoUQDQgAECGwMJiYQA15H2zuM9Xfdxsmyi72vMVHV6+rzWyLYqsH4IyvHGKqh
ik1BPEQlwd280mmIFtE3ZkCHSRirP+O9eQ==
ENDECPRIVATEKEY
catecreq.csr
BEGINCERTIFICATEREQUEST
MIH+MIGnAgEAMEUxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEw
HwYDVQQKExhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAAQIbAwmJhADXkfbO4z1d93GybKLva8xUdXr6vNbItiqwfgjK8cY
qqGKTUE8RCXB3bzSaYgW0TdmQIdJGKs/4715oAAwCQYHKoZIzj0EAQNHADBEAiAN
s+Hm0+XEfKB6kTPbYFSjenSm/0CV2acUfVBm7LCPDgIgCzFr6KSFZM/VR4SIFkWU
NHSDfhzPXgjv+VC3HJTF1KE=
ENDCERTIFICATEREQUEST
From here, we can navigate to the "Inspect Certificate/CSR" page to verify the CSR's contents:
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 Download
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.
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 identicallynamed certificates we discussed at the
beginning of this howto. 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)
Email 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:
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 howto:
keytoolvlistkeystoretomcat.jks
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, Nonrepudiation, Key encipherment
Extended Key Usage: Client Authentication, Email Protection
Subset of Subject Alt Name: RFC 822 Name (email 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, Email address in DN", Set as Required
Other subject attributes: Remove the "DNS Name" entry
Other subject attributes: Add "RFC 822 Name (email 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"
Because we are staying with RSA keys in this howto, select "2048 bits" from in the "Key length" menu. Click on "Enroll", then save
the .p12 file when prompted.
Administrator Roles
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.
We will use keytool to manage our keystore files, and avoid this command line silliness altogether.
First, stop ejbca:
serviceejbcastop
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
keytoolimportcertaliasrootca.yourcompany.netfiletruststore.crtkeystoretruststore.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 howto:
keytoolvlistkeystoretomcat.jks
keytoolvlistkeystoretruststore.jks
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:
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.
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 howto.
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 "rebreak" this fix.
vi/opt/jboss/standalone/configuration/standalone.xml
###Startstandalone.xmlDelta###
to:
<datasourcejndiname="java:/EjbcaDS"enabled="false"poolname="ejbcads"useccm="true">
<datasourcejta="false"jndiname="java:/OcspDS"enabled="false"poolname="ocspds"useccm="true">
###Endstandalone.xmlDelta###
<mailsessionjndiname="java:/EjbcaMail"from="ejbca@yourcompany.net">
<smtpserveroutboundsocketbindingref="ejbcamailsmtp"/>
</mailsession>
</subsystem>
and:
<outboundsocketbindingname="mailsmtp">
<remotedestinationhost="localhost"port="25"/>
</outboundsocketbinding>
<outboundsocketbindingname="ejbcamailsmtp">
<remotedestinationhost="localhost"port="25"/>
</outboundsocketbinding>
###Endstandalone.xmlSnip###
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
###Startstandalone.xmlDelta###
<subsystemxmlns="urn:jboss:domain:mail:1.0">
<mailsessionjndiname="java:jboss/mail/Default"from="ejbcamail@gmail.com">
<smtpserverssl="true"outboundsocketbindingref="mailsmtpgmail">
<loginname="ejbcamail@gmail.com"password="your_password"/>
</smtpserver>
</mailsession>
<mailsessionjndiname="java:/EjbcaMail"from="ejbcamail@gmail.com">
<smtpserverssl="true"outboundsocketbindingref="mailsmtpgmail">
<loginname="ejbcamail@gmail.com"password="your_password"/>
</smtpserver>
</mailsession>
</subsystem>
<outboundsocketbindingname="mailsmtpgmail">
<remotedestinationhost="smtp.gmail.com"port="465"/>
</outboundsocketbinding>
###Endstandalone.xmlDelta###
mysqlurootpejbcadb<mysqldatabaseprivileges.sql
You can verify the privilege changes by doing the following:
mysqluejbcadbuserp
useejbcadb
showgrantsforejbcadbuser@localhost
exit
###Startheader.jspDelta###
Change:
<%java.net.URLadminURL=newjava.net.URL("https",
request.getServerName(),
org.ejbca.config.WebConfiguration.getExternalPrivateHttpsPort(),
"/"
+org.ejbca.config.InternalConfiguration.getAppNameLower()
+"/adminweb/")
%>
To:
<%java.net.URLadminURL=newjava.net.URL("https",
request.getServerName(),
1,
"/"
+org.ejbca.config.InternalConfiguration.getAppNameLower()
+"/adminweb/")
%>
###Endheader.jspDelta###
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 howto, 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.
"How to Install EJBCA 6.1.1 on CentOS 6.5" by VES Group, Incorporated is licensed under a
Creative Commons AttributionNonCommercialShareAlike 4.0 International License.
Based on a work at http://ejbcacentos.blogspot.com.
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
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
Whoever is hitting the blog using MultiZilla: Respect, you circa2001 badass.
Reply
[echo]
[echo]
[echo]
[echo]
[echo]
[echo]
[echo]
[echo]
[echo]
[echo]
[echo]
ca.signaturealgorithm : SHA256WithRSA
ca.validity : 3650
ca.policy : null
ca.tokenproperties : /opt/ejbca/conf/catoken.properties
httpsserver.hostname : rootca.attt.vn
httpsserver.dn : CN=rootca.attt.vn,O=HVKTMM,C=VN
superadmin.cn : superadmin
superadmin.dn : CN=superadmin,O=HVKTMM,C=VN
superadmin.batch : true
appserver.home : /opt/jboss
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 12) 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 12) Init, EJBCA 6.1.1 (working
copy) startup.
21:16:13,722
INFO
[org.cesecore.keys.token.CryptoTokenFactory]
(MSC
service
thread
12)
Class
not
found:
se.primeKey.caToken.card.PrimeCAToken.
21:16:13,726
INFO
[org.cesecore.keys.token.CryptoTokenFactory]
(MSC
service
thread
12)
Can
not
register
se.primeKey.caToken.card.PrimeCAToken. This is normally not an error.
21:16:51,625 INFO [org.jboss.as.server] (DeploymentScannerthreads 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] (DeploymentScannerthreads 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
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] (DeploymentScannerthreads 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.
Warren V
2)I use Oracle DB 9i (9.2.0.5.0) and checking DB I see that ejbca db scheme was successfully autopopulated :
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]
org.hibernate.dialect.Oracle10gDialect"
(MSC
service
thread
14)
HHH000400:
Using
dialect:
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 webconsole
/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] (http0.0.0.084435) 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)
[jbossasejb3
7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jbossasejb37.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jbossasejb37.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jbossasejb37.1.1.Final.jar:7.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jbossinvocation1.1.1.Final.jar:1.1.1.Final]
at
org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.
java:41) [jbossasejb37.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) [ejbcautil.jar:EJBCA
6.1.1 (working copy)]
at org.ejbca.core.ejb.ra.EndEntityManagementSessionBean.addUser(EndEntityManagementSessionBean.java:311) [ejbcaejb.jar:]
Could you please to give light to the error ?
Thank you beforehand,
Timur.
Reply
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
Hello Andreas,
I found these three articles within 10 seconds of Googling:
http://stackoverflow.com/questions/15001342/jboss7wardeploymentfailed
https://www.openshift.com/kb/kbe1037timeoutdeployingjbossapplications
http://vinynigam.blogspot.com/2013/04/increasingdeploymenttimeoutfor.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
Sorry Timur,
Your best bet is to post this question to the EJBCA Sourceforge mailing list.
Warren V
Reply
Hello Pascal,
OCSP configuration is included in this howto.
Warren V
Warren V
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
Warren V
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
De nada, Luis,
Por favor dgame que los cambios que realice con la versin 6.2.0, y voy a actualizar la gua.
Warren
Reply
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
bin/ejbca.sh ra addendentity apachessl foo123 "CN=caserver.company.local,O=EJBCA Sample,C=SE" "" ManagementCA "" 1 PEM SERVER
how I can fix it
greetings
Reply
HOME_ejbca/bin/jboss.xml
306
307
308
When I set "ant deploy", EJBCA uses the parameter "308 <jboss:adm arg='datasource 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
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
Warren V
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
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
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.
11)
JBAS018211:
Could
not
load
JSF
managed
bean
class:
Publish
Preview
Newer Post
Home