Presentation from EJBCA Developers conference

We held an EJBCA developers conference in Sweden on the 13-15 of September. Some presentations from the conference are now up on http://www.primekey.se/Community/.

/Tomas

Open Source security project gets EU funding

Article (in Swedish) about PrimeKey Solutions (in a consortium that the article does not mention) getting funding for developing an EAL certified open source security core.

http://www.idg.se/2.1085/1.243826/eu-miljoner-till-svenska-it-foretag

JMRTD and ISODL

JMRTD and ISODL are two open source projects that are using the cert-cvc library available in EJBCA. Cert-cvc was created for handling the CVC certificates used for EU EAC ePassports. The ISODL project uses the library, slightly modified, to handle CVC certificates used for driving licenses. JMRTD has build a complete library for handling the different parts of ePassports, not only EAC. Using JMRTD for example we built a MRTD SO signer in SignServer, that takes data group hashes and returns a finished signed SO(d).

Open source is great!

Cert-cvc: http://www.ejbca.org/.

JMRTD: http://www.jmrtd.org/

ISODL: http://isodl.sourceforge.net/

EJBCA 3.9.1 released

We are pleased to announce the release of EJBCA 3.9.1.

This is a minor release but packed with new minor features and fixes, 46
issues have been resolved.

Noteworthy changes:
- Improvements to public enrollment process including automatic renewal.
- Ability to specify approvals on certificate profiles.
- Configurable list of extended key usages.
- Dynamic update of max-age and nextUpdate for OCSP responders, also per
certificate profile.
- In CRL update service you can select which CAs to generate CRLs for.
- Possible to schedule CRLs more often than hourly.
- Possible to remove soft CA key and possibility to import it back again.
- Possibility to remove passwords from properties files.
- Support for CRL distribution points with URI:s containing semicolon.
- Transaction log for web service certificate issuance.
- Possibility to specify Any CA in end entity profiles.
- More flexible configuration of CA validity, years, months days.
- Improved error message in GUI when HSM activation fails.
- Many small optimizations, fixes and improvements.

Read the full changelog for details.
https://jira.primekey.se/browse/ECA?report=com.atlassian.jira.plugin.system.project:changelog-panel

This is a plug-in upgrade for users of EJBCA 3.9.0.

Visit EJBCA.org to download the latest release!

Regards,
The EJBCA team.

Accessing the WS signing certificate from inside a JAX-WS webservice

When I have set up the webservice as in the previous post to require signatures, it's very normal that I would like to know who signed the certificate. Also I probably want to access the credentials of the signature, in this case the certificate.

How do I retrieve the signature certificate of a WS-security signed SOAP message?

I could not find any good post describing this on the Internet...

Well here it is now:

 @Resource
 private WebServiceContext wsContext; 

<snip>

     MessageContext mctx = wsContext.getMessageContext(); 
     Subject s = (Subject)mctx.get("CLIENT_SUBJECT");
     Set cs = s.getPublicCredentials();
     for (Iterator iterator = cs.iterator(); iterator.hasNext();) {
   Object object = (Object) iterator.next();
   System.out.println("Object: "+object.getClass().getName());
   if (object instanceof X509Certificate) {
    System.out.println("Found a certificate");
    X509Certificate cert = (X509Certificate) object;
    System.out.println(cert.toString());
   }
  }
     if (s != null) {
      Set ps = s.getPrincipals();
      for (Iterator iterator = ps.iterator(); iterator.hasNext();) {
       Principal principal = (Principal) iterator.next();
       if (principal instanceof X500Principal) {
        X500Principal xp = (X500Principal) principal;
    System.out.println(xp.getName());
       }
      }
     }

<snip>

Configuring Glassfish and SOAPui to use message level security with digital signatures

I made a simple Jax-WS project with simple webservice. The tricky part is that I wanted message level security with WS-security digital signatures authenticating the message. It took me a while to get it right, so here is how it's done. You can configure WS-security layer on the server side simply by configuring Glassfish use it for all soap messaging. This was the easiest way for me to set it up.

* Configure glassfish:

This will use the default server keystore for signatures, the same keystore that is used for SSL.

In admin console go to: Configuration->Security->Message Security->SOAP
In Message Security tab select:

Default Provider: ServerProvider
Default Client Provider: ClientProvider

In Providers tab click ServerProvider:

Provider Type: server
class name (default): com.sun.xml.wss.provider.ServerSecurityAuthModule
Request policy:
- Authenticate Source: content
- Authenticate Recipient: null (blank)

Response policy:
- Authenticate Source: content
- Authenticate Recipient: null (blank)

Additional Properties:
leave as default

* Configure SOAPui

Create a project and send a message to the server. When the server is configured to require signature you should receive a "Error validating request" message back.

Open project view. Go to tab Security Configuration->Keystores/Certificates.
Add a keystore glassfish/domains/domain1/config/keystore.jks, password changeit and default alias s1as.
Change to tab Outgoing WS-Security Configurations. Create a new configuration called "sign".
Add a new WSS Entry called Timestamp with Time To Live 1000 (or something).
Add a new WSS Entry called Signature:
- Keystore: keystore.jks
- Alias: s1as
- Password: changeit
- Key Identifier Type: Binary Security Token
- Signature Algorithm: http://www.w3.org/2000/09/xmldsig#rsa-sha1
- Signature Canonicalization: http://www.w3.org/2001/10/xml-exc-c14n#
- Use single certificate for signing
- Add a new part: Name=Body, Namespace=http://schemas.xmlsoap.org/soap/envelope/, Encode=Element
- Add a new part: Name=Timestamp, Namespace=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd, Encode=Element

Finally in the request window add the configuration. Select XML view and click Aut in the bottom, select Outgoing WSS=Sign

Now you will probably have an issue with glassfish being unable to verify your message. This is due to canonicalization and SOAPui making nice display of the XML for you.
Go into the XML view and remove all whitespace and newlines in the soapenv:Body tag.

Now it should work!

Build an open source enterprise OCSP validation service

Build a high performance OCSP responder using EJBCA. EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an ocsp responder.

EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an ocsp responder.

With the release fo EJBCA 3.9.0 it is easier than ever to set up a high performance, high reliability OCSP responder.
OCSP stands for online certificate status protocol and is defined in RFC2560. In short it provides an online service for validating that a certicate, as used by SSL or VPN etc, has not been revoked. OCSP has the basic functionality defined in RFC2560 and this, in it's plain form, it widely used. If using a high speed hardware security module (HSM) for signature operations you can easily answer 500 requests per second with the EJBCA external OCSP responder. Certificate status information is kept in a regular database, such as MySQL, making it very suitable for online services because you can really update the information on line without waiting for the certificate authority to issued certificate revocation lists (CRLs).

To further improve scalability of OCSP IETF has defined a lighweight OCSP profile in RFC5019. This profile builds on the usage of http get instead of http post which is the default transport used. Using http get the responder can set http headers to enable caching by regular proxies. Caching makes the service slightly less online, in the meaning that you always gets fresh information, but can improve performance across networks. EJBCA 3.9.0 improves the EJBCA external OCSP responder with full support for RFC5019.

If you plan on building an OCSP service there are many things to consider:
- standards support
- performance
- scalability by adding cluster nodes
- transaction and audit logging
- authentication of callers, possibly requiring signed requests
- use of custom OCSP extensions
- OCSP responder independent of CA service provider
- renewal of OCSP responder keys

A typical configuration for OCSP uses two or more OCSP responder nodes. Each OCSP responder keeps it's own database. By using it's own database you can assure truly high availability because the nodes are completely independent and you can do maintenance on one node, including the database, without affecting uptime of the service. The OCSP responder nodes should be connected to a set of HSMs in a high availability setup, if one HSM breaks, another keeps the service running albeit with less available performance.
Each OCSP responder will produce full transaction and audit logging. Audit logging is needed in order to maintain trust, since a validation service such as OCSP is about trust. Transaction logging will be needed if you want to keep records of users of the service either for billing purposes or to keep statistics.

Visit EJBCA.org for downloads and documentation.