EJBCA - Open Source Enterprise PKI

This is the first post in a series about what is new in the upcoming EJBCA 6. EJBCA 6 will be released, in both a Community and Enterprise Edition (more about that in a later post) during the autumn.
EJBCA 6 is a major evolution of EJBCA with another technology upgrade (Java 7, JBoss 7), many new cool features and lots of improvements. So far more than 200 issues has been fixed, reviewed and closed and a few more remains.
Why do we go up from EJBCA 4/5 to EJBCA 6? This is because there are new features that changes the way administrators interact with EJBCA. So administrative work-flows change a bit and a new major version number indicates that administrators might need updated training, and integrations should be thoroughly tested.

Enough about that, and on to todays topic. Crypto Tokens and Crypto Tokens in Admin GUI.

In EJBCA 6 we introduce the concept of separated, generic crypto tokens. Previously a CAs keys have been tighly tied to the CA (as a configuration object). In EJBCA 6 there is a new concept of a crypto token than can be shared among multiple CAs or other services such as OCSP. A crypto token is simply a keystore and can be a software keystore in the database or a hardware keystore such as a PKCS#11 slot on a HSM.
Being separated from CAs you can create, edit and delete unlimited number of crypto tokens individually, not re-configuring any CAs or services. For a crypto token you can create and configure the token (such as PKCS#11 driver, slot etc), generate and delete keys, test keys and create CSRs for individual keys. When you create CAs or OCSP services you connect them to an existing crypto token and select which keys on the token should be used for which purposes, all using simple lists that presents you with what is on the token. No need to use separate tools to to manage keys on the token.

So what benefits does this give you?

Clear and easy to understand management of cryptographic keys. Click and go, no strange HSM commands, no weird hard token properties, easy overview of your HSMs and keys.
Full Admin GUI support for key management, including HSM management with easy drop down selections of your type of HSM. No more editing properties! Generate and manage your keys from the GUI, including full audit logging.
There are also usability short cuts, such as automatic crypto token creation when creating a new soft token CA, to make it easy to get going. But it is really easy to understand the important aspect of key management in a high security PKI environment.
Easy to see and share a single HSM configuration for multiple CAs. No need to configure the same HSM slot multiple times.
Easy renewal and creation of link certificates for CAs. Simple generate new keys on the crypto token (during a key ceremony?) and renew the CA using by selecting a key in a drop down list and renewing the CA.
Since crypto tokens are not tied to CAs you can configure them for OCSP as well. This gives GUI support for standalone OCSP responders through the use of OCSP Key Bindings.
Re-use crypto tokens easily for future services.
and more...

Another thing with the new crypto tokens is that you can use slot number, slot index or slot label to identify a slot. This is good news for users of some HSMs that either have random slot numbers or that may have different slot numbers on different HSMs in a High Availability (HA) environment.

Needles to say, we think this new feature is awesome. Since I don't know much about other products I can't say it is unique, but it's a leap forward in usability for us.

Part 2 of "What's new in EJBCA 6" will be about new improved CMP configuration and CMP aliases.

Until then...

There has recently been posted an update to the old trusted OCSP RFC (rfc2560). The updates in the new RFC6960 are quite few (a good grade for the old RFC, which is exemplary simple yet effective) and clarifies a few points that were previously seen as ambiguous, and could lead to different implementations. It also introduces a few new OCSP extensions.

So how does EJBCA stand on the new RFC? Below I will go through the most important changes, that are relevant for EJBCA implementation.
Changes not mentioned here are either optional and never used/requested in EJBCA, or are already implemented fully by EJBCA OCSP.

o DONE: Section 2.2 extends the use of the "revoked" response to allow
this response status for certificates that have never been issued.

This allows responders (MAY) to return "revoked" status for certificates that are unknown to the OCSP responder.
EJBCA was always designed to include all issued certificates, and to provide "unknown" response for certificates that are really unknown to the responder. So for along time EJBCA was ahead of the pack, prohibiting "ok" responses for certificates the responder did no know about.
In practice an "unknown" response will be treated the same as "revoked" in most cases, i.e. the transaction denied. There was a discussion about the possibility of clients falling back to CRL processing in the case of "unknown", hence the new requirement to respond "revoked" also for unknown certificates.

ECA-3132 has been created to allow responders to be configured to also return "revoked" for unknown certificates, not only "unknown".

o Section 4.4.7 specifies a new extension that may be included in a
request message to specify signature algorithms the client would
prefer the server use to sign the response as specified in [RFC6277].

This option is probably far away from being used in the wild. It can however be interesting for EJBCA to support it in the future.

ECA-3133 has been created to eventually cater for this extension.

o DONE: Section 4.4.8 specifies a new extension that indicates that the
responder supports the extended use of the "revoked" response for
non-issued certificates defined in Section 2.2.

This extension would also be supported as of ECA-3132 above.

This was it! The noteworthy thing is returning of "revoked" status for certificates that are unknown to the responder. It's a small change, brought in by the latest years CA compromises and the work of
browsers and CAs to increase security, and improve interoperability amongs vendors. OCSP has proven to be a remarkably simple, robust, interoperable and widely used protocol, as opposed to many other protocols.
May it live long.

Visit PrimeKey for more information about support subscriptions for EJBCA OCSP Responder.

Welcome to the second part of the series about what is new in the upcoming EJBCA 6.
For the first part in the series, read Part 1: Crypto Tokens in GUI.

In part 2 we will take a look at new major features in the EJBCA support for the CMP protocol, RFC4210.
EJBCA has supported RFC4210 all the way since EJBCA 3.4 in 2005.
(for the history inclined, see ECA-99).

CMP is a very complex protocol with literally hundreds of different options. And those are just the options that are specified in the RFC, then there is also the question how to process them in the back-end with different types of authorization, auto enrollment, support for both end clients and RAs etc etc. The support in EJBCA for different types of clients and different CMP options have grown step by step over the years and we even implement the somewhat cryptic NestedMessageContent as "Multiprotection support".

Currently there is a single URL to access the CMP server, and a single configuration, cmp.properties, for CMP. This means that when you configure CMP in EJBCA for a specific client (or RA), this is the client that will be interoperable.
If you want to run two different clients against the server, with two different configurations, this is not possible since there is only one URL and one configuration. You can of course deploy two separate servers in a cluster, each server running different configurations, but this is not very nice and feels more like a hack.

Introducing CMP aliases. With the arrival of EJBCA 6 you will be able to configure as many CMP URLs (CMP aliases) as you want, each one with a different configuration. There is a set of default (secure by default) options that each new alias configuration inherits and that you can override for each individual URL.

As an example, I set up this test environment for testing with cmpforopenssl.

Client mode with HMAC password authentication on server-address:8080/ejbca/publicweb/cmp
Client mode with client certificate authentication on server-address:8080/ejbca/publicweb/cmp/alias1
RA mode with fixed HMAC RA password 'password' on server-address:8080/ejbca/publicweb/cmp/alias2

Needless to say, alias1 and alias2 are just strings and you can use anything you like.

At first shot this was configured in a new configuration file, cmpaliasconf.properties.
cmp.alias1.operationmode=client
cmp.alias2.operationmode=ra
etc.

But heck, some people here were not satisfied with that, so lets configure everything in the Admin GUI instead.
You heard it, in EJBCA 6 you will configure CMP in the Admin GUI, and you can select and add new aliases simply by clicking some buttons.
Of course there will also be a command line interface (CLI) so you can script it or simply use the CLI if your administrator certificate has expired (but you don't let that happen do you?).

The new CMP configuration is stored in the database so there is a single configuration across your cluster, configure on one node, see the effects on all.
There will also be a possibility to read in an old configuration file in the CLI, so upgrades from the old style file configuration is easy.

All currently available CMP features, such as the CMP proxy is of course available just as before.

Needles to say, we think this new feature is awesome. Since I don't know much about other products I can't say it is unique, but it's a leap forward in usability for us.
With CMP being used more and more now (after all these years as an RFC) and replacing the simple SCEP protocol, this will ensure that EJBCA can work with many different CMP clients out there, all at the same time.

Part 3 of "What's new in EJBCA 6" will be about a completely new feature called Internal Key Bindings and OCSP Key Bindings. Anyone longing for an Admin GUI for EJBCA standalone OCSP responder?

Until then...check in with PrimeKey, or follow us on Twitter, for the latest news and events.

The Certificate Transparency initiative (RFC6962) is an admirable suggestion to improve security of TLS web session for certificates issued by public CAs. It has cool technology with Merkle trees, is admirable short and could have been straight forward was it not for something called PreCertificates. PreCertificates are hard for me to understand, I don't like them. I hope it is because I don't understand them...if so please let me know.

Writing this post is a way to sort things out for myself and I'd be happy to edit this post if explained why I "just don't get it". Of course I am posting this to the CT forum as well...

In the sake of transparency, I'm writing with the view point of an implementer of open source CA software (if you didn't figure that one out from the blog name:-)).

Update 1: I got lots of comments already over at the Certificate Transparency Forum, really good.

Update 2: I created an issue in the Certificate Transparency issue tracker. https://code.google.com/p/certificate-transparency/issues/detail?id=18

Update 3: Of course my views on CT changes as the discussion continues, the post below was my original starting point. Follow the discussion in Update 1 for updates.

Update 4: EJBCA will support Certificate Transparency in EJBCA Enterprise eventually, watch out for news.

On to PreCertificates...

PreCertificates are defined in section "3.1. Log Entries" as (text trimed by me) "The Precertificate is constructed from the certificate to be issued by adding a special critical poison extension to the end-entity TBSCertificate". Then it describes how it can be produced and it is mentioned throughout the spec in many places.
A PreCertificate is a essentially a certificate signed with one of two options:

1. PreCertificates signed by the real CA.
This sounds very dangerous as will break the fundamental X.509 rule of unique issuerDN/serialNumber pairs. The consequences of having two "certificates" with the same issuerDN/serialNumber in the wild can not possibly be estimated, making this practice quite dangerous imho.

2. PreCertificates signed by a separate PreCertificate signing CA, which is a SubCA to the real signing CA. This is a less scary, since it is normal practice that different CAs can issue certificate with the same subjectDN/serialNumber, just not the same issuerDN.

The actual implementation of issuing PreCertificates makes it quite impractical. I would believe that most CA implementations creates the TBSCertificate as part of the actual certificate issuance. The CA will not create the TBSCertificate to have is lying around for a couple of days before using it to issue the real certificate.
Thus, if the CA is to create a PreCertificate to send to the CT log, it might as well issue the real certificate and send it to the log. The time difference should be in the milliseconds for most CAs.
If the CA wants to wait before distributing the real certificate, to make sure it's in the logs before put into production, it can surely do so as well.

The PreCertificate imho suffers from several complicating factors for implementers, both on the CA and the CT log side. The TBSCertificate must have a poison extension inserted, and removed, effectively re-encoding the ASN.1 TBSCertificate several times, all these are points of failure.

The reason for PreCertificates are not clearly explained. Why would you want to use PreCertificates?

Fine combing through the spec gives me some ideas on why, for example to be able to embed the Certificate extension from PreCertificate CT logs in the final certificate (section 3.3). But the the TBSCertificate of the PreCertificate is then no longer the real TBSCertificate? In that case, why is the PreCertificate the TBSCertificate at all, and not just a new data structure with the data the CT log wants?

The PreCertificate complicates the CT spec by orders of magnitude, which is not a good thing. There are so many ifs and buts about PreCertificate the RFC is not even itself consitent about what it is.

Ok, I know the PreCertificate is is optional, but the best standards, who gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping PreCertificates from the CT spec makes it so much simpler.

My suggestion:
- Skip PreCertificates altogether

I see though why people will not accept that just because I say something...so in that case

- Explain the purpose behind PreCertificates well
- Describe what the actual information fro PreCertificate are used
- Be consistent throughout in the RFC

Feel free to contact me at tomas a t primekey dot se.

The PrimeKey SignServer team is happy to announce that SignServer 3.4.2has been released!
This is a maintenance release with in total 13 tickets resolved.

The most noteworthy changes can be seen below. Development continues beyond this version and all requests from the community are scheduled for SignServer 3.4.3 or later releases. More information is available at the project web site and the complete changelog can be viewed in the issue tracker.

Major new features and improvements:

Uses PKCS#11 crypto token implementation from the Common Criteria certified CESeCore
Support for starting audit log verification from a specified sequence number
Option to archive all X-Forwarded-For addresses
Option to include the ordering field in time-stamp tokens even if the
field has value false
Option to not include the signingTime CMS attribute in time-stamp signer
Option to cache PKCS#11 key reference to increase performance
Includes IssuerSerial in the SigningCertificate attribute in
time-stamp signer

Bug fixes:

HSM auto activation was not working when signed audit log were used
Key generation was not working with slotListIndex
ClientCLI over web services was not working unless includemodulesinbuild was specified

Regards,
The PrimeKey SignServer team

Welcome to the third part of the series about what is new in the upcoming EJBCA 6.
For the first part in the series, read Part 1: Crypto Tokens in GUI.

For the second part in the series, read Part 2: CMP aliases and GUI configuration.

In part 3 we take a look at a major new function in EJBCA 6 called Internal Key Bindings. This is a framework function, with two current applications, and can be used for more things in the future.
An Internal Key Binding can be used to make keys in a Crypto Token available for other uses than in a CA. It consists of a reference to a key pair available to the EJBCA instance, a non-CA certificate, an optional list of trusted certificates and properties for its purpose. It can be thought of as a simplified key store with purpose-specific properties.

So what can we do with internal key bindings?

The first thing is to introduce OCSP (RFC6960) Key Bindings. An OCSP Key Binding can be used to sign OCSP responses on behalf of a CA. It has a key in a Crypto Token and an OCSP signing certificate. Additionally a list of trusted certificates can be used to verify that OCSP requests are sent from a trusted source and additional properties can be used to specify how long an OCSP response should be valid etc.

What does this provide us that we could not do before?

Well for example:

Cluster wide OCSP responder key configuration. Configure on one node, and all nodes sharing the same database will be configured.
Full GUI support for configuration of OCSP responder keys and certificates. This is a function of the standard Admin GUI.
Support for multiple Crypto Tokens in an OCSP responder. The old configuration file only supported one PKCS#11 slot.
No need to load OCSP signing certificates into the HSM, signing certificate is read from the database.
Full control of you OCSP signers.
Mix delegated OCSP signers with direct CA signers, CAs and delegated OCSP responders can reside in the same instance.

(See screenshots in the end)

What more can we do?

Authentication Key Bindings is a key binding used as identity in outgoing TLS connections, i.e. TLS client certificates. This can be used to authenticate an OCSP responder's web service calls when using web services to automatically renew certificates from a CA.

On top of this it is possible to create new types of key bindings as we figure out new cool things. Anything that makes use of a key pair and a certificate gains the full maintenance options and HSM support of Internal Key Bindings.

Naturally there are a bunch of general maintenance options available for all Internal Key Bindings.

Enable/Disable: Marks the Internal Key Binding as Active/Disabled. Only Active ones will be used and processed by healthcheck.
Delete: Removes the Internal Key Binding, but will not remove the referenced key pair or certificates.
New keys: Generates a new key pair in the referenced Crypto Token using the same key specification as the current key has and an alias derived from the current alias.
CSR: Creates a Certificate Signing Request using the next key pair (or current key pair when no next key pair exists).
Update: Searches the database for the latest issued matching certificate for the next key pair (or current key pair when no next key pair exists) by using SubjectKeyId.
Renew: When the CA that issued the current certificate is active and resides in the same instance, this will create a new certificate using the same End Entity as the last one was issued with. If a next key pair exists, that key pair will be used.

Part 4 of "What's new in EJBCA 6" will be about Community vs Enterprise edition and how you, with EJBCA 6, will be able to actively participate in the development community.

Until then...check in with PrimeKey, or follow us on Twitter, for the latest news and events.

Pic 1: List of Key Bindings. There are tabs for different types of Key Bindings.

Pic 2: Editing an OCSP Key Binding.

EJBCA 5.0.11 released

8 Nov 2013 — Stockholm, Sweden

The PrimeKey EJBCA team is happy to announce that EJBCA 5.0.11 has been released! This is a maintenance release – 17 issues have been resolved. The most noteworthy changes can be seen below.

EJBCA PKI 5.0.11 release notes

A maintenance release containing a couple of small features and many bug fixes. The following are a selection of the most noteworthy:

New features
- Support for multiple Vendor CAs in CMP for 3GPP/LTE networks.
- Possibility to use token label to reference PKCS#11 slots.
Improvements
- Support ECDSA for automatic key renewal in OCSP responder.
- New WS keyrecovery method for specified certificates.
- Add hostname in startup log.
- Add configuration option for forbidden characters.

Development continues beyond this version and all requests from the community are scheduled for EJBCA 5.0.12 or later releases.

More information is available at the project web site and the complete changelog can be viewed in the issue tracker.

Let's face it, OpenSSL is the number one toolkit for any PKI expert when it comes to dissecting and manipulating files such as CSRs, certificates, PKCS#12 keystores, asymmetric keys etc. We use it all the time when developing EJBCA, Open Source PKI.

Using openssl is not always the easiest task in the world, but there are a number of commands that I find myself using over and over again. So much that I can almost type them in my sleep.

Parsing certificates

Reading X.509 certificates in PEM format:

openssl x509 -in cert.pem -text

Reading X.509 certificates in DER format:

openssl x509 -inform DER -in cert.der -text

Converting X.509 certificates from DER to PEM:

openssl x509 -inform DER -in cert.der -outform PEM -out cert.pem

You can also add parameters to only output specific fields, like certificate serial number, public key etc. I rarely use those though, I just dump the cert and look at the whole thing.

Parsing certificate signing requests (CSRs)

Reading a CSR in PEM format:

openssl req -in req.pem -text

Reading a CSR in DER format:

openssl req -inform DER -in req.pem -text

Converting a CSR from DER to PEM:

openssl req -inform DER -in req.der -outform PEM -out req.pem

Parsing pure ASN.1

Sometimes you really want to see the nitty gritty details of a certificate or CSR, to find out what encoding is used in the DN, how the extensions look, what order fields actually are in the file etc.

openssl asn1parse -in cert.pem

add the dump parameter to dump the (unknown) contents of sequences:

openssl asn1parse -in cert.pem -dump

Generating certificate signing requests (CSRs)

To generate a new key pair and a certificate request, for example for getting a certificate for an apache server:

openssl req -out csr.csr -new -newkey rsa:2048 -nodes -keyout private.key

Check the private key:

openssl rsa -in cesecore2013.key -check


When generating CSRs you can add a lot of options to put in the CSR, like Subject Alternative names, certificate purposes, OCSP URLs etc. When creating CSRs to be sent to a CA this is normally not needed. The CA will populate all the fields for you, and normally ignore any additional fields that you specify (a real CA have no reason to trust arbitrary input from you). If you are generating your own self-signed certificates however, this may be of interest. 


Kevin McArthur has written a nice blog post how to work with OpenSSL to create certificates and CSRs. It's a bit outdated, but Kevin may update it.

Parsing PKCS#12 keystores

Reading a PKCS#12 file, giving output with encrypted private key in PEM format:

openssl pkcs12 -in superadmin.p12

Reading a PKCS#12 file, output with unencrypted private key:

openssl pkcs12 -in superadmin.p12 -nodes

The following commands are useful for splitting a PKCS#12 file up into PEM components (for example for an apache server or for manual sign/verify operations):

Reading a PKCS#12 file, outputing only the certificate to a file:

openssl pkcs12 -in server.p12 -nodes -nokeys -clcerts -out server.pem

Reading a PKCS#12 file, outputing only the private key to a file:

openssl pkcs12 -in server.p12 -nodes -nocerts -out server.priv

Reading the cert, extracting the public key in RSA format:

openssl x509 -in server.pem -pubkey -noout > server.pub

Signing and verifying large files

Signing of large files are done by making a digest (hash) of the file and then signing the hash:

openssl dgst -sign superadmin.key -sha1 file.txt > file.txt.sign

Verification of a file is done by verifying the signed hash (extracting the original hash) and comparing that to a newly calculated hash of the file:

openssl dgst -verify superadmin.pubkey -signature file.txt.sign -sha1 file.txt

See also Code signing over in the EJBCA Admin Guide.

Cmpforopenssl

I have previously written about cmpforopenssl. This is a great tool for using the CMP protocol.
You can read more about cmpforopenssl and EJBCA in the EJBCA Admin Guide.

OCSP

A popular openssl command for me is the OCSP request command. I use this to test OCSP responders all the time:

openssl ocsp -issuer Test-CA.pem -CAfile Test-CA.pem -cert Test.pem -req_text -url http://localhost:8080/ejbca/publicweb/status/ocsp

The tricky thing here is if you have an external OCSP responder, i.e. not requesting directly from the CA, then you must have the right combination of -CAfile and chain commands in order for the verification to succeed without having openssl claim that issuer is not trusted. The above command is perfect if you are requesting directly from the CA...

TLS client

You can test TLS/SSL servers using OpenSSL's s_client command. This is great for debugging TLS connections. It will show you the certificates used by the server and the accepted CA certificates sent by the server when asking for client certificate authentication. It can also be used to see the cipher suites negotiated.
openssl s_client -debug -msg -connect servername:443 > debug-log.txt < /dev/null

Converting between JKS and PKCS#12 (not using openssl)

Another old popular blog post I wrote was about converting between JKS and P12 using simple java commands, keytool.

Remove MS CSP information from a PKCS12/PFX

George L wrote an interesting comment on LinkedIn.
It's about MS adding CSP information when exporting a PKCS12 files, and this can cause errors when importing it into other versions of Windows. He provided a cool script that removes this information, using openssl.

----------------- removeCSP.bat -------------- 
@echo off 
rem make sure you've got openssl and grep either in your path or in the same directory as the batch file 
set /p pass=Please enter keystore password: 
cd /d "%~dp0"
openssl pkcs12 -in "%~f1" -nodes -passin pass:"%pass%" | grep -v  Microsoft | openssl pkcs12 -export -out "%~f1".new.pfx -passout  pass:"%pass%"
echo Conversion complete. 
pause 
------------------ removeCSP.bat --------------

Welcome to the fourth part of the series about what is new in the upcoming EJBCA 6.

For the first part in the series, read Part 1: Crypto Tokens in GUI.
For the second part in the series, read Part 2: CMP aliases and GUI configuration.
For the third part in the series, read Part 3: Internal Key Bindings.

In part 4 we will dig into the concepts of EJBCA Enterprise and Community. The separation was started with the Common Criteria certification of EJBCA 5, and is now completely harmonized with EJBCA 6. EJBCA Enterprise brings additional value to organizations that subscribe to support services, this blog post will tell you what, and why.

The freshest, most up to date, description of EJBCA Enterprise will be available at PrimeKey.

Open Source Enterprise Editions

Enterprise editions is a common way for open source projects and companies to offer additional value to organizations that subscribe to support services, and hence indirectly pay the bills for the developers of the software.
Not a completely unproblematic issue since part of the soul of Open Source is that you can freely download and use the software. So why choose the Enterprise edition? Here is the reasoning:

The requirements on professional enterprise software are very high nowadays and the users demand high quality, lots of features, software certifications etc. There is simply need for a lot of full time staff to develop and support an enterprise scale software today. Income is needed to pay salaries.
The Community is one of the founding pillars of Open Source software, the community has made us what we are. The community needs a comfortable way to use, interact and to contribute to the future of the project.

To keep up that pace of development, and support, there is of course a need for constant business. What we need, as a company, is to provide added value so that you find that you get great benefit from the money. This is where the Enterprise edition comes in.

There are many very appreciated organizations in the world, that subscribes to support.

Thank you, you know who you are!

There are many appreciated community members, thank you as well!

EJBCA Enterprise

PrimeKey, with EJBCA, started out with an Enterprise edition as of EJBCA 5, where PrimeKey, together with partners, made a huge investment to make the software Common Criteria certified.

We have written a little bit about this before in two previous (older) blog posts:

With EJBCA 6 we want to finalize and harmonize the concept and versions.

The idea behind EJBCA Enterprise is simply:

Provide organizations with the best, most hassle free, sleep good at night, PKI experience money can buy - with EJBCA Enterprise
Allow do it yourselfers (DIY), who are confident they can roll their own, to use the best PKI product they can find - with EJBCA Community
All this with Open Source!

A little more in detail, the strategy is:

To focus the enterprise additions on the main target markets where we compete with proprietary software and can provide support services to organization that are prepared to pay for these services. Providing the best PKI services from the most experienced staff, with add-ons that makes their PKI the most efficient and cost-effective PKI on the market.
Enabling the Open Source Community with the best PKI product on the market with full features, allowing everyone to contribute directly to the latest version of the project in a simple way, with full access to the source code.

PrimeKey EJBCA Enterprise features and services

The freshest, most up to date, description of EJBCA Enterprise will be available at PrimeKey.

This is a snapshot at the time this blog post was written.

These are the main value adding features and services that will be available only with EJBCA Enterprise:

Professional support with different SLAs and private support portal access.
Additional development services.
Training courses.
Bug, security and hot fixes.
Additional integration guides and supported integration with 3rd part products (for example token management).
Common Criteria certification with specific features:

Database integrity protection.
Secure audit logging (log signing).

High Availability setups with redundant clusters and disaster recovery.
EAC ePassport PKI, with BAC, EAC, SPOC, PKD etc.
GOST and DSTU algorithms.
3GPP/LTE CMP support.
Add-on tools:

Database CLI for migration between databases, verification of integrity protection etc.
Tools for speeding up deployments across environments.
Validation tool for conformance checking of certificates and OCSP responders.

Upgrade assistance, also from very old versions of EJBCA Community to the latest EJBCA Enterprise.
Last but not least, soon to be available in a plug and play PKI Appliance.

Find out more

If you are using EJBCA Community, and are interested in EJBCA Enterprise, or if you just want to know more. Don't hesitate to contact me at tomas@primekey.se. Migrations from Community to Enterprise is of course trouble free and we can help you every step of the way.

If you are interested in getting to know the different subscription options, contact sales@primekey.se, we are flexible.

Check in with PrimeKey, or follow us on Twitter, for the latest news and events.

Another interesting blog post on Open Source and Enterprises is Feed the Fish, from the people behind TomEE.

The Team

The great team that, with pride, brings you EJBCA, Signserver, PKI Appliance, SPOC and everything around it is:

Joonas, Mike, Marcus, Markus, Johan, Aveen, Samuel, Lars, Konstantin, Admir, Anna, Björn, Anna, Tomas, Lars, Maikel, Marko, Raoul, Joakim, Branko, Dimitrios, Tham, Manuel, Roland, Martin.

Questions and answers

Here are some questions asked by people reading the above:

Q1. Do the improvements in EJBCA Enterprise ever find their way to Community.

Answer: As I tried to state above, EJBCA Enterprise does not contain improvements of Community features. It contains specific features used for specific Enterprise use cases. These features are planned to remain Enterprise features until the concept changes (if it changes).
Improvements to common functionality will be released in both Enterprise and Community. The times will only be constrained by release schedules. Enterprise is expected to have more releases than Community.

Q2. Is it possible to migrate from EJBCA Enterprise back to community? If so, what is the difficulty.

Answer: Yes that is possible. Naturally you will loose the Enterprise functionality such as audit log signing. The CA will continue to work, just without this feature.

Q3. When someone licenses EJBCA Enterprise, if they do not wish to maintain support contract do they have to downgrade when the support contract ends.

Answer: No. Naturally they will however no longer get upgrades from PrimeKey.

Q4. Do improvements in Community ever find their way back into Enterprise? If yes, how long does that take.

Answer: Yes, this will be included in following releases.

Q5. When will EJBCA Community version 6 be released?

Answer: We are currently working on the distinction between Enterprise and Community as described above. There is no fixed date, since this depends on developer resource availability. It will not be too long, don't despair.

Finally there is an actual legal entity established for Bouncy Castle. Legion of the Bouncy Castle Inc., is a not-for-profit association based in Australia. Bouncy Castle is glad to announce that as of the 7th November this year (2013), Legion of the Bouncy Castle Inc. ABN 84 166 338 567 is now officially recognised by the Australian Government as a charity established for the benefit of education and the benefit of the public in general.

Support contracts are handled through Crypto Workshop Pty Ltd, however the recognition of the charity does mean two important things, you can stop worrying about something weird happening in corporate life affecting the availability of the APIs as everything is getting signed over to the charity, and also importantly, Bouncy Castle is actually authorised to start fund raising for things like FIPS.

So in honor of this, and the upcoming 50th Java release, we're launching our 2013 "FIPS or bust!" Fund Raiser.

Click this donations link!
https://www.bouncycastle.org/donate/index.cgi

It's using paypal so if anyone wants to chip in a large amount, direct transfer would be a better option, but you are still recommended to look at the page due to the graphics!

Bouncy Castle currently see over 10000 downloads a week, and gets lots of "When will you be FIPS certified?" emails. The Java API is now over 300,000 lines, the C# one well past 140,000. There are more standards being published every day, and most of the old ones are getting revised. Further on there is trying to constantly monitor for and identify vulnerabilities, as well as taking time out to review contributed code so that the project continues to be a community based effort as well as an Open Source one.

PrimeKey, and me Tomas, supports Bouncy Castle. You should to!

This is a copy of the product release from PrimeKey.

17 Dec 2013 — Stockholm, Sweden

PrimeKey proudly presents the next generation open source enterprise PKI, EJBCA Enterprise 6.0.
Running on the latest technology platforms, this PKI is faster, more resource efficient, more secure and more user friendly than ever.
EJBCA Enterprise v.6 is so flexible it is suitable for any organization, cloud, social or mobile system.

EJBCA Enterprise 6.0 release notes

Having already passed two maintenance releases, EJBCA Enterprise 6.0 is now ready for production! The following are a selection of the most noteworthy changes.

New features
- New Crypto Token concept, giving complete GUI support for configuring signature and keys, either in software or on hardware security modules. Hardware security modules has never been easier.
- CMP configuration can now be done in the GUI, and supports multiple different configurations through CMP Aliases. More flexible than ever you can easily set up CMP to talk to any type of device, all with a single instance of EJBCA.
- The new Internal Key binding concept merges the Certificate Authority and Validation Authority functionality. Use the same instance, or multiple instances, using the same well known admin GUI as a Certificate Authority or Validation Authority or both.
- Full support for the latest platforms. Java 7 and JBoss 7 are now the default recommended platforms, faster, more secure and more resource efficient.
Improvements
- More than 300 issues have been resolved during the development of EJBCA Enterprise v.6.

More information on EJBCA Enterprise PKI is available here. For entire technical details view the changelog in the issue tracker.

EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

SPOC stands for Single Point of Contact: the standard specified by the EU for exchanging certificates needed to perform EAC (Extended Access Control), between member states.

To analyze the possibilities and restrictions related to implementing SPOC for EAC, a bachelor thesis study has recently been performed at the University of Skövde and at PrimeKey Solutions AB.

Conducted in three steps, the study begins with an analysis of the SPOC standard. The results of that analysis were used as input to the next step in which several people involved in developing SPOC were interviewed. Finally a case study was made, with the attempt to see whether or not it was possible to use elliptic curve cryptography in an interoperable environment.

The study analyses potential shortcomings in the SPOC specification, which are believed to potentially cause lack of interoperability between different implementations of SPOC. Also studied are potential interoperability issues arising from the use of elliptic curve cryptography (ECC) for TLS communication between SPOCs.

An abstract of the thesis is available for download (English version), as well as the full thesis written in Swedish.

More information

For more information about the thesis, contact the author:

Joakim Kävrestad, joakim.kavrestad(at)his.se

For more information about PrimeKey SPOC and ePassport PKI contact:
Tomas Gustavsson, tomas(at)primekey.se

PrimeKey is happy to announce that EJBCA Enterprise 6.0.3 has been released! This is a maintenance release – 21 issues have been resolved.

Running on the latest technology platforms, this PKI is faster, more resource efficient, more secure and more user friendly than ever. EJBCA Enterprise v.6 is so flexible it is suitable for any organization, cloud, social or mobile system.

EJBCA Enterprise 6.0.3 release notes

A maintenance release containing a few new features and improvements. The following are a selection of the most noteworthy changes.

New features
- Support for OCSP extended revoked status compliant with RFC6960.
Improvements
- EJBCA now ensures that OCSP RFC5019 responses with unknown response code are not cached.
- OCSP now uses archive cutoff date for expired certificates, compliant with RFC6960.
- Speedups when starting the Command Line Interface.
- Bug fixes for Internal Key Bindings.

More information

Basic information on EJBCA Enterprise PKI is available here.

For entire technical details view the changelog in the issue tracker.

EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

EJBCA, the open source PKI, has been around for quite some time now, since 2001 to be exact. The last major release of EJBCA Community was EJBCA 4, which saw many updates up to the final release 4.0.16 in June 2013. EJBCA 5 was Common Criteria certified, and therefore never released to the public. After a long wait, and much development, EJBCA Community version 6 is now here.

The latest release of EJBCA Enterprise 6.0.3, also marks the release of EJBCA Community 6.0.3. Enjoy! But if you have the means, please help support EJBCA by subscribing to an EJBCA Enterprise support subscription.

EJBCA 6 is the base for future releases of EJBCA Community. This is a good time to Contribute.

More information about EJBCA 6:

Introduction

SignServer participated in the ETSI CAdES Plugtest Interop event with SignServer developers Markus Kilås and Marcus Lundblad. Here is a summary of Markus's report from the event.

The Plugtest Event

The ETSI Centre for Testing and Interoperability (CTI) organized a Remote Plugtest Interop event for CAdES Signatures scheduled from 2nd to 13th December 2013, and later extended to the 20th December.

The event was conducted remotely using the Electronic Signature Plugtest Portal, e-mail and three conference calls.

About 60 companies joined the event.

The Plugtest Portal

The event was conducted mostly through the portal where the participants could download an “inital package”, a zip file with test case specifications for which signatures to create, as well as folders for the different participants.

After creating the signatures (according to the specifications) those could be placed in the participant's folder, the relevant parts of the folder structure zipped together, then uploaded to the portal. The Portal took care of merging the uploaded files and created a new package for download by all participants. In the same way signature verification reports could be uploaded and a matrix with the results could be viewed in the portal.

There were 84 different test cases in the cross-verification part of the event.

SignServer implementation

SignServer did not support any form of CAdES prior to the event. We decided to base our implementation on the library SD DSS.

Because of limited time and SD DSS using an older version of BouncyCastle, we simply developed a standalone proof of concept not yet integrated in SignServer. We based our implementation on SD DSS version 2.0.2, but during the event version 3.0.2 was released. Yet, we decided to continue on 2.0.2 through the event, as we already had done a lot of changes, both bug fixes and added features, since it otherwise would have taken too long to merge it to the new version. We also took contact with the authors of the library and got informed about version SD DSS version 4, planned for January-February 2014, with major changes in the verification parts.

Our implementation consisted of a standalone Java CLI application, which could either sign or verify a document. The application used a configuration file (similar to the signer configuration file in SignServer) configuring the CryptoTokens to use.

Test Cases

To easily create all necessary signatures and also perform validation of the other participants's signatures, we used JUnit test cases that could be run from within the IDE. A Java base class contained a single test method for each type of signature to create/verify. The method took care of calling the PoC application with the right properties for each type of signature, and then performed the necessary verifications to check that the signature complied with the test specification. This was implemented using JUnit asserts, and some magic in a base class took care of producing a verification report, according to the plug test specification.

To be able to perform all the tests implemented for all participants, the base class was extended and parameterized with a list of all participants, so that each test method was executed for each participant.

A complete run produced about 600 verification reports.

Results summary

The support for CAdES-BES, CAdES-BpB and CAdES-T was quite good, except for the missing support for counter signatures (BES-6).
For CAdES-EPES some participants were reporting problems.
For CAdES-C and CadES-X* we had some issues related to the ordering of revocation information references.
We did not perform any CAdES-A and signature upgrades (CAdES-UpdArb).

Support for correctly verifying signatures was mostly lacking and we did not put any big effort into resolving that during the event, as the verification support will be largely changed in the next version of SD DSS.

Conclusions

We participated in the event and had good interoperability results for the basic forms of CAdES, during the limited time-frame.

We now have a lot more knowledge about CAdES and the SD DSS library. We also developed a set of test cases that will be helpful when developing and integrating CAdES support in SignServer.

More work is needed to make our CAdES implementation stable and to integrate it in SignServer, as well as adding support for the more evolved forms of CAdES (which we did not have time for during this event).

We look forward to attending the next CAdES PlugTest Event!

Introduction

Implementing CMP to enroll for certificates and do automatic certificate renewal against a CA that supports the CMP protocol, the open source tool CMP for OpenSSL should be considered. Using the CMP protocol is a great way to integrate client and RAs in a PKI, and CMP for OpenSSL is a very promising tool.

Some background on CMP

The open source CA EJBCA implements many standard PKI protocols. One of them is CMP, which has been around since September 2005 when the RFC4210 first was published. In the early days adoption of CMP was progressing slowly due to the great complexity. The huge amount of options still make CMP somewhat cumbersome both to implement and use.

In the beginning CMP was mostly used from RAs, such as card/token management systems and in-house RAs. In the last couple of years adoption of CMP has increased and is now used in several systems, for example in LTE mobile networks where CMP is profiled by 3GPP (supported in PrimeKey's EJBCA Enterprise).

However, being a complex protocol with many options, CMP can be used for many different use cases.From clients that enrolls for certificates with optional automatic renewal, to RAs that registers end entities and issues certificates for those. All combined with several different ways of authentication, such as shared secrets and client certificates. One important distinction to make, is that messages specified by the protocol are one thing, another is the expected behavior in the back end (for example if a client needs to be pre-registered or not, or if any fields are accepted from an RA, or if there are any profile limitations). The messages themselves are specified in the CMP standard, but the behavior is defined by the specific use cases and sometimes standardization groups such as 3GPP.

CMP has been implemented within EJBCA since ECA-99 in 2006. PrimeKey's implementation has matured a lot during this time, and the latest evolution is CMP Aliases. In the current state CMP can be used for an uncountable number of different use cases with different back-end behavior, depending on the configuration.

CMP for OpenSSL

The main obstacle slowing the adoption of any protocol, is lack of free and open source implementations. So it is both pleasing and welcome to see CMP for OpenSSL appear. Being an excellent tool, we hope to see it integrated into OpenSSL at some point.

Note: Before using CMP for OpenSSL you must download and build it. It is not included in any standard distribution of OpenSSL.

Using CMP for OpenSSL as CMP client

Here I will show three different enrollment types; A client with a pre-registered shared secret, a client using certificate authentication, and an RA using shared secret authentication.
There is of course much else you can do. The RA can for example use certificate authentication, you can do nested messages with multiple layers of authentication etc. Only your imagination sets the limits on how to use CMP :-). Along with EJBCA 6 all these different configurations can be active at the same time.

For complete documentation, see the Admin Guide at EJBCA.org.

Pre-registered client with password authentication

Download the CA certificate to the client
Add a new end entity in EJBCA
Run the command

./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp -srvcert MyCA.cacert.pem -user username -pass password -certout clcert1.pem -newkey key1.pem -keyfmt PEM -certfmt PEM -subject "/CN=username/O=My Organization/C=SE"

Where username is the username you added (you have to type it twice it's in the CN as well) and password is the password you entered when adding the end entity.

The above requires a CMP alias in EJBCA with the following configuration:

Client mode
HMAC authentication module
CN as extract username component

Pre-registered client with certificate authentication

Since this requires an existing certificate for the client, you can use the above enrollment method to generate it, but other possibilities exist of course.

./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp/alias1 -srvcert MyCA.cacert.pem -cert clcert1.pem -key key1.pem -certout clcert2.pem -newkey key1.pem -keyfmt PEM -certfmt PEM

Where clcert1.pem and key1.pem is the cert and key generated previously (used for authentication to the same user). clcert2.pem will be the new certificate, and for simplicity we re-use key1.pem as -newkey, but you can generate a new one as well.

The above requires a CMP alias in EJBCA with the following configuration:

Client mode
EndEntityCertificate authentication module
CN as extract username component

RA with shared secret authentication

Using an RA means that the RA should be able to order certificates for clients of the RA. The clients themselves will not be pre-registered by the CA, but will be added by the RA when the RA enrolls for the client.

./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp/alias2 -srvcert MyCA.cacert.pem -user user4711 -pass password -certout clcert1.pem -newkey key1.pem -keyfmt PEM -certfmt PEM -subject "/CN=user4711/O=My Organization/C=SE"

Where User and CN should be the same, and afterwards the client will be available as "username" in EJBCA.

The above requires a CMP alias in EJBCA with the following configuration:

RA mode
HMAC authentication module
Specified secret 'password1'
DN parts with CN as RA name generation scheme

About the author

Tomas Gustavsson, CTO of PrimeKey, founder of EJBCA

Contact me at: tomas(at)primekey.se

Follow me on Twitter: primetomas

Introduction

A convenient method to enroll for certificates and do automatic certificate renewal, is to use the BouncyCastle API to implement a client that uses the CMP (RFC4210) protocol. In this example the implementation is done using java code and you need a CA that supports the CMP protocol on the server side.

Using the CMP protocol is a good way to integrate clients and RAs in a PKI, and BouncyCastle API is a great tool for this task. By the way, BouncyCastle needs your support to fund a FIPS certification. Help spread the word.

A short background on CMP

The open source CA EJBCA, implements many standard PKI protocols, CMP being one of them.

In the early days of CMP there were mainly commercial SDK implementations, and only a single open source instance (written in C). As always, that slowed down adoption. Nowadays, there is full support for CMP in the governing de-facto standard java crypto API BouncyCastle. No more excuses not to use CMP! :-)

Described more in detail in a previous blog post is CMP and its implementation in EJBCA.

Examples on how to use BouncyCastle CMP API

Here, I will show two different enrollment types (with source code) for the client implementation: 1) an RA using a shared secret authentication and 2) a client using certificate authentication.
These are by no means everything you can do. The RA can also use certificate authentication, or you can do nested messages with multiple layers of authentication. And many, many more! Only your imagination sets the limits :-).

All mentioned configurations can be active at the same time when using EJBCA 6. For complete documentation, see the Admin Guide at EJBCA.org.

Enrollment type 1) RA with shared secret authentication

Using an RA means the RA is configured to order certificates for its clients. The clients themselves will not be pre-registered by the CA, but will be added by the RA when it enrolls for the client.

To create a CMP enrollment message for an RA, using BouncyCastle:


CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(BigInteger.valueOf(certReqId));
X509NameEntryConverter dnconverter = new X509DefaultEntryConverter();
X500Name issuerDN = X500Name.getInstance(new X509Name("CN=AdminCA1").toASN1Object());
X500Name subjectDN = X500Name.getInstance(new X509Name("CN=user", dnconverter).toASN1Object());
msgbuilder.setIssuer(issuerDN);
msgbuilder.setSubject(subjectDN);
final byte[]                  bytes = keyPair.getPublic().getEncoded();
final ByteArrayInputStream    bIn = new ByteArrayInputStream(bytes);
final ASN1InputStream         dIn = new ASN1InputStream(bIn);
final SubjectPublicKeyInfo keyInfo = new SubjectPublicKeyInfo((ASN1Sequence)dIn.readObject());
msgbuilder.setPublicKey(keyInfo);
GeneralName sender = new GeneralName(subjectDN);
msgbuilder.setAuthInfoSender(sender);
// RAVerified POP
msgbuilder.setProofOfPossessionRaVerified();
CertificateRequestMessage msg = msgbuilder.build();
GeneralName recipient = new GeneralName(issuerDN);
ProtectedPKIMessageBuilder pbuilder = new ProtectedPKIMessageBuilder(sender, recipient);
pbuilder.setMessageTime(new Date());
// senderNonce
pbuilder.setSenderNonce(senderNonce);
// TransactionId
pbuilder.setTransactionID(transactionId);
// Key Id used (required) by the recipient to do a lot of stuff
pbuilder.setSenderKID("KeyId".getBytes());
org.bouncycastle.asn1.crmf.CertReqMessages msgs = new org.bouncycastle.asn1.crmf.CertReqMessages(msg.toASN1Structure());
org.bouncycastle.asn1.cmp.PKIBody pkibody = new org.bouncycastle.asn1.cmp.PKIBody(org.bouncycastle.asn1.cmp.PKIBody.TYPE_INIT_REQ, msgs);
pbuilder.setBody(pkibody);
JcePKMACValuesCalculator jcePkmacCalc = new JcePKMACValuesCalculator();
final AlgorithmIdentifier digAlg = new AlgorithmIdentifier("1.3.14.3.2.26"); // SHA1
final AlgorithmIdentifier macAlg = new AlgorithmIdentifier("1.2.840.113549.2.7"); // HMAC/SHA1
jcePkmacCalc.setup(digAlg, macAlg);
PKMACBuilder macbuilder = new PKMACBuilder(jcePkmacCalc);
MacCalculator macCalculator = macbuilder.build("password".toCharArray());
ProtectedPKIMessage message = pbuilder.build(macCalculator);

The above requires a CMP alias with approximately the following EJBCA configuration:

RA mode.
HMAC authentication module.
Specified secret 'password1'.
DN parts with CN as RA name generation scheme.

Enrollment type 2) Pre-registered client with certificate authentication

Using a client means that the client is already registered and present on the CA, able to authenticate itself with a certificate. The certificate can be generated by other means than the CA, or be imported into EJBCA.

To generate a signature protected CMP enrollment message using BouncyCastle:


CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(BigInteger.valueOf(certReqId));
X509NameEntryConverter dnconverter = new X509DefaultEntryConverter();
X500Name issuerDN = X500Name.getInstance(new X509Name("CN=AdminCA1").toASN1Object());
X500Name subjectDN = X500Name.getInstance(new X509Name("CN=user", dnconverter).toASN1Object());
msgbuilder.setIssuer(issuerDN);
msgbuilder.setSubject(subjectDN);
final byte[]                  bytes = keyPair.getPublic().getEncoded();
final ByteArrayInputStream    bIn = new ByteArrayInputStream(bytes);
final ASN1InputStream         dIn = new ASN1InputStream(bIn);
final SubjectPublicKeyInfo keyInfo = new SubjectPublicKeyInfo((ASN1Sequence)dIn.readObject());
msgbuilder.setPublicKey(keyInfo);
GeneralName sender = new GeneralName(subjectDN);
msgbuilder.setAuthInfoSender(sender);
Control control = new RegTokenControl("foo123");
msgbuilder.addControl(control);
Provider prov = Security.getProvider("BC");
ContentSigner popsigner = new JcaContentSignerBuilder("SHA1withRSA").setProvider(prov).build(keyPair.getPrivate());
msgbuilder.setProofOfPossessionSigningKeySigner(popsigner);
CertificateRequestMessage msg = msgbuilder.build();
GeneralName recipient = new GeneralName(issuerDN);
ProtectedPKIMessageBuilder pbuilder = new ProtectedPKIMessageBuilder(sender, recipient);
pbuilder.setMessageTime(new Date());
// senderNonce
pbuilder.setSenderNonce(senderNonce);
// TransactionId
pbuilder.setTransactionID(transactionId);
org.bouncycastle.asn1.crmf.CertReqMessages msgs = new org.bouncycastle.asn1.crmf.CertReqMessages(msg.toASN1Structure());
org.bouncycastle.asn1.cmp.PKIBody pkibody = new org.bouncycastle.asn1.cmp.PKIBody(org.bouncycastle.asn1.cmp.PKIBody.TYPE_INIT_REQ, msgs);
pbuilder.setBody(pkibody);
ContentSigner msgsigner = new JcaContentSignerBuilder("SHA1withRSA").setProvider(prov).build(keyPair.getPrivate());
ProtectedPKIMessage message = pbuilder.build(msgsigner);

The above requires a CMP alias with approximately the following EJBCA configuration (use a new CMP alias so you can run this and the previous config in parallell):

Client mode.
EndEntityCertificate authentication module.
CN as extract username component.

About the author

Tomas Gustavsson, CTO of PrimeKey, founder of EJBCA
Contact me at tomas(at)primekey.se.
Follow me on Twitter.

The PrimeKey EJBCA^® team is happy to announce the release of EJBCA Enterprise 6.1.0.
This release resolves several issues, with a few highlights: Increased performance through OCSP improvements; Key Recovery improvements; support for EAC 2.10 (ePassport) access control templates.
Running on the latest technology platforms, EJBCA Enterprise v.6 is so flexible it is suitable for any organization, cloud, social or mobile system. Faster, more resource efficient, more secure and more user friendly than ever.

EJBCA Enterprise 6.1.0 release notes

A maintenance release containing 32 new features and improvements, below a selection of the most noteworthy:

New features
- New OCSP features related to RFC 6960, minimizing size of OCSP responses.
- Implemented OCSP signing algorithm selection from client requested algorithms.
- CVC certificate profiles (ePassport PKI) now supports EAC 2.10 access control templates.
Improvements
- OCSP improvements with more cache control settings.
- Improvements to Key Recovery, enabling encryption key rollover and providing more information about encryption keys.
- Ability to build and install EJBCA on Windows platforms.
- The ManagementCA created during default install, now uses SHA256WithRSA.
- EJBCA compiles cleanly with Java 8, WildFly 8 and Glassfish 4 (running on those platforms however, is not yet supported).
- EJBCA can now use certificate serial number longer than 64 bits.
- Many reported minor issues have been fixed, as well as minor GUI improvements.

More information

Basic information on EJBCA Enterprise PKI is available here. For entire technical details view the changelog in the PrimeKey Issue Tracker.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

Point of Sale (POS) terminals, communicate not only to all of the cash registers of a store, but also to central location. In order to secure this particular type of communication, and secure other items on the terminals as well, you need to add keys and certificates managed by a PKI.
To enable POS terminals to enroll for certificates specifically against an EJBCA^® Enterprise PKI server, C2 Company and PrimeKey have successfully installed and used the EJBCA Enterprise clientToolBox on several Toshiba 4690 POS terminals.

About POS and Toshiba 4690

Commonly used in POS terminals, the Toshiba 4690 is an operating system which is basically IBM Java and DOS based, using specific 4690 DOS commands. So, if you are used to common computing with Linux or Windows, the Toshiba will appear a bit alien. However, taking the trouble to introduce PKI to the POS system, will enable any user of the 4690 terminals to trade on both strong authentication and encryption.

Steps to Enroll and Renew Certificates

Having IBM Java on board, helped us run EJBCA clientToolBox on Toshiba 4690, and made it possible to enroll and manage certificates. The Toshiba required some figuring out of which new commands to run, but once that was (elegantly) performed by C2, EJBCA clientToolBox was running ever so nicely.
The following steps are only a single example of how you can use the certificate management capability on POS terminals. In fact, there are limitless possibilities.
Use the Native DOS commands to generate keys and CSRs. Once those are generated you can enroll for a certificate against EJBCA, using clientToolBox.
To enroll new terminals for the first time when they are installed in a store, you can use a pre-installed certificate on the POS terminal image. To enroll for the real terminal certificate you use the pre-istalled certificate temporarily, to enable access from the POS terminal to EJBCA. The pre-installed certificate does not need any admin access in the EJBCA system. Do the following:

Install a new POS terminal with an image, including a pre-installed communication certificate on the image.
Register the POS terminal (with serial number or similar) in EJBCA, and you'll receive a one-time enrollment code.
Generate keys and a CSR (to the csr.pem file) on the POS terminal, by using DOS commands.
Submit the CSR to EJBCA, to get the signed certificate back, using this command:

./ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req terminalSerial enrollmentCode csr.pem PEM NONE certificate.pem
Now you are ready to remove the pre-installed communication certificate from the image, to finally make the image secure, only by its rightful individual certificate. However, to block the POS terminal from accessing store systems (in case the terminal gets stolen or hacked) the latter step can be revoked.
A single PKI administrator action is found in the above work-flow; registering the POS terminal in EJBCA. This is done in order to authenticate the initial enrollment and make sure that no unauthorized terminal receives real certificates, that is, illegitimate access to store systems. With the final certificate installed, the terminal can automatically renew it before expiry, requiring no PKI administrator action during daily operations.

More information

Fore more information, or to get in touch with C2 for help with securing your POS terminals, contact Chris or me. Cheers!

Chris Chu
chris at c2company.com

Tomas Gustavsson
tomas at primekey.se
Twitter

As of the release of version 6.0.4, EJBCA Enterprise now supports Certificate Transparency RFC6962.

Google Initiative to Increase https Security

Certificate Transparency (CT) is an initiative by Google to increase security and auditability of the https ecosystem itself. These important aims are accomplished by having CAs (CA services using a software such as EJBCA) issue TLS certificates, which are transparently auditable and exactly reveals which certificates have been issued. The purpose of CT is to create public audit logs of all certificates issued by the public SSL/TLS CAs. For example, this means the owners of a certain web domain can monitor CT Log servers, to see if there are any unknown or suspicious TLS certificates issued for their domain. In addition, the presence of audit records is planned to be required for EV certificates in Google Chrome from February 2015. And perhaps later on for other web browsers and non-EV certificates as well.

Note that Certificate Transparency is only relevant for CAs issuing public SSL/TLS certificates; other types of CAs mustn't use CT at this time. More information can be found on the CT website.
The specification of Certificate Transparency is still being discussed, and a follow up to RFC6962 will likely be available in the not so distant future, including (among other things) a way to handle private subdomains.

How EJBCA Enterprise perceives Certificate Transparency

From the CA's angle, CT works by publishing pre-certificates from itself to the log servers; then in immediate response, Signed Certificate Timestamps (SCTs) are retrieved. Certificate and timestamp exchange is done within a single operation, so requesting an SCT for a certificate also publishes it. The resulting SCTs can then be sent to end-users in any of three different ways: 1) in a certificate extension (embedded when issuing the real certificate), 2) in a stapled OCSP response extension, 3) and/or in a TLS extension (yes, EJBCA does support all of those methods, including any combination of the three).

The EJBCA Admin Guide describes how to configure EJBCA Enterprise for one or more of the above methods.

For more information, contact:

Tomas Gustavsson, CEO of PrimeKey, founder of EJBCA
tomas(at)primekey.se.
Follow me on Twitter

EJBCA 5.0.11 released

8 Nov 2013 — Stockholm, Sweden

EJBCA PKI *5.0.11* release notes

New features

Improvements

Parsing certificates

Parsing certificate signing requests (CSRs)

Parsing pure ASN.1

Generating certificate signing requests (CSRs)

Parsing PKCS#12 keystores

Signing and verifying large files

Cmpforopenssl

OCSP

TLS client

Converting between JKS and PKCS#12 (not using openssl)

Remove MS CSP information from a PKCS12/PFX

Open Source Enterprise Editions

EJBCA Enterprise

PrimeKey EJBCA Enterprise features and services

Find out more

The Team

Questions and answers

17 Dec 2013 — Stockholm, Sweden

EJBCA Enterprise *6.0* release notes

New features

Improvements

More information

EJBCA Enterprise 6.0.3 release notes

New features

Improvements

More information

Introduction

The Plugtest Event

The Plugtest Portal

SignServer implementation

Test Cases

Results summary

Conclusions

Introduction

Some background on CMP

CMP for OpenSSL

Using CMP for OpenSSL as CMP client

Pre-registered client with password authentication

Pre-registered client with certificate authentication

RA with shared secret authentication

About the author

Introduction

A short background on CMP

Examples on how to use BouncyCastle CMP API

Enrollment type 1) RA with shared secret authentication

Enrollment type 2) Pre-registered client with certificate authentication

About the author

EJBCA Enterprise *6.1.0* release notes

New features

Improvements

More information

About POS and Toshiba 4690

Steps to Enroll and Renew Certificates

More information

Google Initiative to Increase https Security

How EJBCA Enterprise perceives Certificate Transparency

EJBCA PKI 5.0.11 release notes

EJBCA Enterprise 6.0 release notes

EJBCA Enterprise 6.1.0 release notes