What's new in EJBCA 6 part 3: Internal Key Bindings

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.

SignServer 3.4.2 released

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

Certificate Transparency and PreCertificates, how will that work?

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.

What's new in EJBCA 6. Part 2: CMP aliases and GUI configuration

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.

EJBCA and the updated OCSP RFC 6960

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.

What's new in EJBCA 6. Part 1: Crypto Tokens in GUI

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?

1. 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.
2. 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.
3. 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.
4. Easy to see and share a single HSM configuration for multiple CAs. No need to configure the same HSM slot multiple times.
5. 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.
6. 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.
7. Re-use crypto tokens easily for future services.
8. 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...

EJBCA 4.0.16 released

The PrimeKey EJBCA team is happy to announce that EJBCA 4.0.16 has been
released! This is a maintenance release of the EJBCA Community version –
3 issues have been resolved. The most noteworthy changes can be seen below.
This maintenance release contains 1 new feature and 2 bugfixes.

• It is now possible to store the Base64 certificate data in a separate table. This can improve database scalability for massive scale PKIs with hundreds of millions of certificate.

• Fixed possible database rollback when CRL publishing failed.

• Fixed a possible exception viewing old log in the Admin GUI.

Please visit http://www.ejbca.org/ for more information.