<X509IssuerSerial> <X509IssuerName>OU=Java,O=IBM,L=Unknown,ST=Oklahoma,C=US</ X509IssuerName> <X509SerialNumber>0</X509SerialNumber></X509IssuerSerial>

Next is the <X509SubjectName>CN=John Doe</X509SubjectName> element, which contains the distinguished name of the service requester — in our case, simply John Doe — and finally the X.509 certificate itself:
<X509Certificate>

MIIB0TCCAToCAQAwDQYJKoZIhvcNAQEEBQAwTzELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE9rbGFo
b21hMRAwDgYDVQQHEwdVbmsam3duMQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBEphdmEwHhcNMDIw
OTI1MTAxMTQ4WhcNMDMwOTI1MTAxMTQ4WjATMREwDwYDVQQDEwhKb2huIERvZTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA2sW+eBjx5D2QMyr8ocZIZWNYHGf9zYhB4XWILPCTvhNV7dIe3l8A
RepOA1ABFK2OMypzb+Rb+nWQeo//yFz/
28PmL63kdLiE72qmmQuzuPa5NXaV9pJ4JKw86QdLhGGp
FIRH18Iugf3xLFwQEZqKYnblTUs7ftnTgW5r4HH492kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCs
OD02WMoYcMR7Sqdb9oQyk7Nn4rQ5DBgZ5mxGGVzWxBZW/
QON+Ir2j4KUjX1jalMvbHa9lnhPQmJi
Ued923rza7fvdRG2CDalbW0R3aPd5q0u3akP0/Ejb7z5o88heajCSgfRruvU+ZdOTT3Oe+RBQgw8
VuzbLApPnXiehowYuA==
</X509Certificate>

The final stage of WS-Security processing is to validate the Web service requester’s digital certificate. When using a digital certificate approach, each Web service requester must have a digital certificate which a trusted Certificate Authority (CA) has signed. The definition of a trusted certificate authority is outside the scope of this paper, but typically either an industry-accepted, 3rd-party certificate authority (a company like VeriSign) performs this role, or the Web service provider takes on the role of the certificate authority for the certificates that their application uses. If the latter approach is used, use of the open source OpenSSL toolkit from Apache, or the basic digital certificate support provided by WebSphere Application Server’s IKEYMAN utility is recommended.

In the initial rollout of our application, our customer chose to play the role of certificate authority. As such, they created their own, self-signed CA certificate. Prior to any Web service interactions, the Web service requester must provide the Web service provider with a certificate that they will use in the application. Playing the certificate authority role, the Web service provider signs the certificate and returns it to the Web service requester.

As described above, the Web service requester includes the CA-signed digital certificate in the SOAP message. After the digital signature has verified the integrity of the message, the certificate is extracted from the message and validated using the CA’s public key. Once the validity of the certificate has been achieved, the Web service requester will have been authenticated and the processing of the WS-Security portion of the message will be complete. The owner has successfully authenticated to the receiver.

Note that if, at a later date, our service provider chooses to relinquish the role of the certificate authority and use an industry-accepted, trusted, 3rd-party certificate authority, the logic of our validation code does not need to change. In this scenario, prior to using the Web service, the Web service requester will need to get a certificate issued by a trusted certificate authority. The service requester will place this 3rd-party certificate in the SOAP message. When the service provider is validating the digital certificate, instead of using their self-signed CA key, the public key of the 3rdparty CA will be used. In this scenario, the service provider has established a trust relationship with the 3rd-party certificate authority, and the CA will be trusted to adequately authenticate users before issuing certificates to them.