EJBCA 3.9.2 released

We are proud to announce the release of EJBCA 3.9.2. We believe this is
the most stable release of EJBCA to date.

This is a minor release but packed with new minor features and fixes, 38
issues have been resolved. Some minor features and options and many bug
fixes and stabilizations.

Noteworthy changes:
- Sign and verify of files with clientToolBox when the private key is
stored on a HSM.
- Possible to limit signing keys for an external OCSP responder to keys
within a set of key aliases.
- Add support for the TSL signer extended key usage
- Use improved validity period parsing in Certificate Profiles
- Add option to use publisher queue or not for CRLs and certificates
- Document MS application policies extension
- Fixes for ejbcaClientToolBox.bat for windows platform
- Timeouts for LDAP publishers to handle unstable LDAP servers
- For issue where CRL service may stop running if database is stopped
for some period
- Change so that Issuing Distribution Point on CRLs is not used by
default in CA configuration
- Fix issue using IAIK provider with several CAs
- Fix slow revocation if a user have many certificates
- cert-cvc: getting expiration date returns 00.00 hours but it means
it's valid the whole day
- cert-cvc: bad encoding of EC points in certificates in rare cases
where affineX and affineY is not same size
- Many small optimizations, fixes and improvements.

Read the full changelog for details.

For upgrade instructions, please see UPGRADE.

----
Work has already started for EJBCA 3.9.3, as well as 3.10. For 3.9.3 we
will for the first time in ages get some new bling on the admin GUI,
thanks to David Carella in France who contributed some styles for the
admin GUI.

EJBCA 3.10 will have many changes, preparing for the big move to EJBCA
4.0. Among other things all configuration in properties files are now
possible to store outside of the ear file, and change dynamically in
runtime.

Regards,
The EJBCA team at PrimeKey.

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!