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 ~/macintosh.uk.ibm.com.key 2048

Generate a Certificate Service Request

openssl req -new -sha256 -key ~/macintosh.uk.ibm.com.key -out ~/macintosh.uk.ibm.com.csr

Generate a Personal Certificate from the Certificate Service Request

certreq -submit -attrib "CertificateTemplate:Webserver" macintosh.uk.ibm.com.csr macintosh.uk.ibm.com.cer

- 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 macintosh.uk.ibm.com.pfx -inkey macintosh.uk.ibm.com.key -in macintosh.uk.ibm.com.cer -certfile macintosh.uk.ibm.com.csr 

- 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/mod_ibm_ssl.so
Listen 8443
<VirtualHost *:8443>
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
SSLProtocolEnable TLSv12
SSLCipherSpec ALL NONE
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSLCipherSpec TLSv12 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSLClientAuth Required
SSLEnable
</VirtualHost>
KeyFile /opt/IBM/HTTPServer/ssl/keystore.kdb
SSLDisable


...

and this is the validation of same: -

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

SSL configuration:
Default server
Server name: bpm856.uk.ibm.com:8080
SSL enabled: NO

SSL server defined at: /opt/IBM/HTTPServer/conf/httpd.conf:852
Server name: bpm856.uk.ibm.com:8443
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)
Ciphers for TLSv12: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(C02F),TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(C030)

Syntax OK


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

openssl s_client -connect bpm856.uk.ibm.com:8443 < /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
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256


5 comments:

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" macintosh.uk.ibm.
com.csr macintosh.uk.ibm.com.cer


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.

Thanks

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.

Dave

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