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.

EJBCA 3.9.0 released

After much hard work, EJBCA 3.9.0 is finally released. This might just
be the best release ever of EJBCA :-)


This is a major release adding many new features and improvements, and fixing numerous bugs.
126 issues have been resolved for this release. Check the changelog, there is a good chance that your favorite issue has been resolved.

Some noteworthy changes:
- Support for CAs using DSA keys. EJBCA now supports all major algorithms; RSA, DSA and ECDSA.
- External RA improvements. CA service running as an EJBCA services gives full cluster functionality and support for multiple external RAs. As a bonus it is now much easier to install and configure.
- Robust re-publishing mechanism for publishers that fail, running as an
EJBCA service.
- OCSP responder improvements with performance improvements and support
for on-line renewal of OCSP responder keys and certificates. The external OCSP responder can now saturate high performance HSMs.
- OCSP monitoring tool for monitoring synchronization between EJBCA and
external OCSP responders.
- GUI for configuring the external OCSP publisher with new options.
- Possible to change OCSP signing keys in a running external OCSP responder.
- New commands and stress tests in the client toolbox.
- A new admin web gui front page with status overview panels.
- Possible to configure status of certificates issued for end entities, i.e. issue certificate revoked "on hold".
- New DN attribute, Name.
- Performance improvement by caching and lowering number of database queries.
- XKMS now works also on Java 6.
- Possibility to set user validity start and end time in WS API.
- Lots of small fixes and improvements to the admin GUI.
- Lots of small bugfixes.
- Keon CA to EJBCA migration guide.

Note that the configuration of External RA changed dramatically (to the better). If using the external RA, please read the manual how to install and configure the RA CA service in EJBCA 3.9.

Note that this version brings database changes. Read the UPGRADE document for upgrade instructions.

This release should, as always, work on JBoss, Glassfish, Weblogic and OC4J, together with most available databases.

Read the changelog for details.