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.

New status overview in the EJBCA admin GUI

In EJBCA 3.9 the admin GUI will get it's first really nice update in a year or so. Apart from the usual additional options etc that pops up in every release, this release changes a fundamental concept - the first page.
We have long been thinking about have the first page be a kind of portal page where an administrator can get an overview of important status and information of the system. Originally we was planning this for the major re-make of the admin gui planned for 4.1. In 3.9 we got the opportunity, thanks to corporate sponsored development and our new developer Markus.

The first page meeting the administrator now has two panels- One with an overview of CAs on-line/off-line status and CRL status and one with number of pending publisher queue items (new feature in 3.9).



We even got some new style sheet items in there :-).
Combined with the on-line documentation links from the admin GUI (question marks in the image) it's really nice.

View a full set of screen shots at sourceforge.

Migrating ext3 to ext4 on an encrypted root disk (ubuntu 9.04)

Ext4 is supposed to be much faster than ext3. Anything that makes development of EJBCA a bit quicker is interesting, so I just had to migrate to ext4 now that Ubuntu 9.04 is out.
The usual ext3 to ext4 migration guides are for normal unencrypted disk. Since my laptop has full disk enryption a few addition steps are needed.
Also the guides mention that you have to do 'grub-install' after migration. I did not have to do that.
Either it is because:
- I only migrated / and not /boot
- The standard upgrade to Ubuntu 9.04 already installed a new grub for me.

Anyhow, here are the steps hwo to migrate an encrypted root disk from ext3 to ext4.

Shut down computer properly, don't hibernate.
Boot from Ubuntu 9.04 cd and use it as a live cd (no changes to computer).
Open a terminal and become root.
#sudo su -

Set up crypto add encrypted disk to lvm
#cryptsetup luksOpen /dev/sda1 root
#lvm vgchange -a y

Mount root disk and just check that it's the correct disk before migrating
#mkdir /mnt/root
#mount /dev/tlap/root /mnt/root

Unmount and do the migration to ext4 (as described in the ext4 wiki and numerous other sites)
#umount /mnt/root/
#tune2fs -O extents,uninit_bg,dir_index /dev/tlap/root
#e2fsck -pfD /dev/tlap/root

Mount new ext4 disk and change fstab to ext4
#mount /dev/tlap/root /mnt/root
#cd /mnt/root/etc/
#vi fstab

Change ext3 to ext4 for you / disk (/dev/sda1 for me).
# /dev/mapper/tlap-root
UUID=ca86bf3d-40fb-4b4d-89c6-15ce94674fa0 / ext4 relatime,errors=remount-ro 0 1

Save, unmount /mnt/root and reboot.
After reboot check /etc/fstab and 'mount' and you will see that it's ext4 now.

tomas@tlap:~/tmp$ mount
/dev/mapper/tlap-root on / type ext4 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
...

Update:
I migrated my rather slowish home computer (AMD 4200+, 4GB, WD Raptor) running 'ant clean; ant' both before and after migration. The conclusion is that it takes 1 minute, give or take a few seconds, on both ext3 and ext4. Not huge leaps in speed there unfortunately.

What to do when you mac address of eth0 changed (debian/ubuntu)?

It always takes me too long to google up this answer so I'll write it here..

Either edit or delete this file:
/etc/udev/rules.d/70-persistent-net.rules

If you delete it, a reboot will create a new one with your new mac address.