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
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
…
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
…
3 comments:
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
:-)
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
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
Post a Comment