Friday, 25 March 2016

IBM HTTP Server - Tinkering with SSL Client Authentication

I'm tinkering with so-called Mutual Authentication (MA) between various middleware components, from browser through to back-end WebSphere Application Server (WAS).

Here's what I'm reading: -

I'm also referencing this: -

as I'm using openSSL to create personal device certificates etc. to allow a client browser to MA to IHS: -

Generate a Private Key on my Mac

openssl genrsa -out ~/ 2048

Generate a Certificate Service Request

openssl req -new -sha256 -key ~/ -out ~/

Generate a Personal Certificate from the Certificate Service Request

certreq -submit -attrib "CertificateTemplate:Webserver"

- This on a Windows Server 2008 R2 box

Convert the Personal Certificate and Private Key and Certificate Service Request into a PKCS12 file

openssl pkcs12 -export -out -inkey -in -certfile 

- This is required to allow me to import the private key and personal certificate into Firefox

For the record, this is relevant part of my IHS configuration - httpf.conf

LoadModule ibm_ssl_module modules/
Listen 8443
<VirtualHost *:8443>
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
SSLProtocolEnable TLSv12
SSLClientAuth Required
KeyFile /opt/IBM/HTTPServer/ssl/keystore.kdb


and this is the validation of same: -

/opt/IBM/HTTPServer/bin/apachectl -DDUMP_SSL_CONFIG

SSL configuration:
Default server
Server name:
SSL enabled: NO

SSL server defined at: /opt/IBM/HTTPServer/conf/httpd.conf:852
Server name:
SSL enabled: YES
FIPS enabled: 0
Keyfile: /opt/IBM/HTTPServer/ssl/keystore.kdb
Protocols enabled: TLSv12
Ciphers for SSLV2: (protocol disabled)
Ciphers for SSLV3: (protocol disabled)
Ciphers for TLSv10: (protocol disabled)
Ciphers for TLSv11: (protocol disabled)

Syntax OK

and this is how I validate IHS from a client connection, using openSSL: -

openssl s_client -connect < /dev/null

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256


Dave Hay said...

Just to correct myself, for the workstation's personal certificate ( sent by the browser to IHS ), I did, of course, mean to specify that the certificate was created thusly: -

certreq -submit -attrib "CertificateTemplate:User"

i.e. specifying the template of User rather than Web Server


Mikkel Flindt Heisterberg said...

I look forward to following this. Are you planning to perform the client cert authentication on the IHS and if so how is the authenticated user information (usernames etc) propagated to WAS including mapping to an actual user in the federated security configuration? I know there are a field in the fed. repo. setup about mapping cert fields to LDAP but if the auth is done on LDAP how is IHS told.... Hmmm... Will follow with great interest.


Dave Hay said...

Hey Mikkel

So, to be 100% clear, in the context of "authentication" between components using client/personal certificates, there's no end-user context involved. The certificate "merely" reflects the identity of the component connecting into the server component.

In other words, with client certificate authentication, aka Mutual Authentication, we're using a certificate, sent by the "client", as part of the initial SSL handshake, where the client certificate is signed by a CA that the server trusts. This is over and above the normal server authentication, where the server presents the client with a certificate signed by a CA signer that the client trusts.

As an example, IHS presents a CA-signed certificate to it's client, your browser - that's server authentication. However, the client - your browser - also presents a CA-signed certificate ( and the browser presents the user with a choice of personal certificate to send ). The server - IHS - trusts the client's certificate, because it "knows" about the CA. Both client and server trust the same CA - hence Mutual Authentication.

My analogy for my client is this - I wear an ID badge "signed" by the customer's security team. The person to whom I'm talking also has an ID badge, signed by the same security team. I trust my client because he "presents" his ID badge to me. Likewise, he trusts me, because I present my ID badge.

We each have an ID badge - our personal certificate - each of which is issued ( signed ) by the same security team, whom we trust.

Final thought, in the WAS world, IHS participates in the client/server Mutual Authentication exchange. Equally, the WAS Plugin does the same thing with the WAS Web Container; both the Plugin ( which has its own KDB ) and WAS share a common CA signer ( typically WAS itself ), and both present a "personal" certificate to each other.

Hope this helps.


Mikkel Flindt Heisterberg said...

Aahhhhhh okay - read your post wrong then. I thought you were tackling the issue of authenticating end users using certificates and not component to component.

Dave Hay said...

Hi Mikkel

No, it's an interesting idea, and one that's probably better served via other means i.e. Kerberos tickets, LTPA tokens, WebSeal tokens etc.

Thanks again, Dave