• No results found

Setting Up SSL From Client to Web Server and Plugin to WAS

N/A
N/A
Protected

Academic year: 2021

Share "Setting Up SSL From Client to Web Server and Plugin to WAS"

Copied!
44
0
0

Loading.... (view fulltext now)

Full text

(1)

IBM Software Group

WebSphere® Support Technical Exchange

Setting Up SSL From Client to Web Server

and Plugin to WAS

Harold Fanning ([email protected]) WebSphere L2 Support

(2)

Agenda

 Secure Socket Layer (SSL) from a Client to an IBM HTTP Server (IHS) web server and WebSphere Application Server (WAS) is a 2 part SSL configuration

 SSL Terminology IHS web server uses a key data base (.kdb) file vs a WAS Keystore

 SSL from Client to IHS web server

 The .kdb passwords and stash (.sth) file  SSL from WebSphere Plugin to WAS  Chained certificates

 Cipher negotiation

(3)

SSL from client to WAS

 Before you begin, it is important to note that you do not have a secure network connection until you have created a key for secure network communications and received a certificate from a Certificate Authority (CA) that is designated as a trusted CA on your server.

 Part 1 SSL session from client to IHS web server

Client to web server where the web server is the SSL server.iKeyman GUI for Interactive Key Managment

GSKit – IBM Global Security Kit

 Part 2 SSL session from WebSphere Plugin to WAS

Plugin to WAS. Plugin is the client and WAS is SSL server WAS Administrator console

(4)

HTTPS SSL (1) Client WebSphere Plugin plugin-key.kdb WebSphere Application Server keystore H HTTPS SSL (2) IBM HTTP Server key.kdb

(5)

Terminology

Client – receives personal certificate from the server

Server – Client must verify and accept the personal certificate

Personal certificate – unique to this host assigned by a Certificate Authority (CA)

Signer certificate – The CA certificate or intermediate certificate

Intermediate certificate – used if chained certificates

.kdb – key database for holding certificates. Holds both signer and personal certificates.

.sth – stash file, encrypted file to hold password to open a .kdb

.rdb – request database when requesting a certificate, must match to receive the certificate.

iKeyman - utility is a tool for key databases containing digital certificates and keys.

(6)

Terminology cont.

Keystore – holds personal certificates

Truststore – holds signer certificates

QoP – Quality of protection. Used to configure client authentication. Level of Cipher also found here

Cipher – Cryptography settings, defines level of security. Strong cipher can mean performance trade off. Provided by group strong, medium and weak or custom selection.

(7)
(8)

Setting up SSL from client to IBM HTTP web server

Configure SSL in the IHS web server's HTTPD.conf configuration file

The IBM GSKit is installed local to IHS install directory

iKeyman GUI, included in installation

Create the kdb, rdb, sth

key.kdb - /<IHS install>/ default

To store the web server personal certificate required by the client.

Request a personal certificate

(9)

Open / create key.kdb - <IHS install directory>

Create a key database file and certificates needed to authenticate the Web server during an SSL handshake

The iKeyman GUI, which is included within the IHS distribution, can be used to create a key database file (for example default: key.kdb). This is needed to store personal and signer server certificates required by the client browser during an SSL handshake.

Create a stash file (key.sth) to store the password for IHS to open the key database. This is required because IHS is not capable of prompting for a password.

(10)

Issue personal certificate request

Builds a key.rdb to request the personal certificate. Use this file to request Personal certificate from a CA. The Personal certificate returned must be received by the same host that made the request. Creates a file to use for making the request from a trusted CA.

(11)

Go to the Signer certificate list for Intermediate and Root certificates

•Populate – Will add all supplied well known CA signer certificate(s).

•Add - signer certificate(s). add provided one if not a well known CA.

•Extract - Extracts a signer certificate from a keystore, and stores the certificate in a file.

(12)

Go to Personal certificate list

Receive - Reads a certificate that comes from a certificate authority (CA) into a keystore. Import - Imports a certificate from a keystore to a keystore.

Note: The signer certificate of the personal certificate must be added first in order to add the personal certificate

(13)

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so Listen 443

<VirtualHost “IP address”:443>

ServerName “fully qualified name” /* Required if multiple SSL hostnames or sitenames*/ SSLEnable

SSLServerCert nameX /* Required and unique for each host if multiple hostnames */ /VirtualHost>

SSLDisable

KeyFile “C:/Program Files/IBM/HTTPServer/key.kdb

/* This is also where the key.rdb and key.sth are kept but path not needed here */

Sample SSL directives in the httpd.conf

Note1: Scope is Global host or virtual host stanza. All host names must have unique IP and be registered with DNS. Therefore VirtualHost stanza required for each Virtual host name / IP

(14)

SSLServerCert – Label name required when there are multiple certificates with multiple SSL virtual hosts. Use to bind the Virtual host using the correct IP and the certificate that goes with that IP. If this directive is absent, then the default certificate is used. SSLClientAuth - Mutual authentication, Client would send us personal. There we need their signer in key.kdb signer list.

SSLCipherSpec – Used to limit the cipher encryption level allowed. If the client does not allow the Cipher access is denied.

SSLCipherRequire

SSLV2Timeout 100 /* Timeouts for SSL version 2 sessions*/ SSLV3Timeout 1000 /* Timeouts for SSL version 3 sessions*/

Additional SSL directives in the httpd.conf

(15)

Setting up SSL from Plugin to WAS

Is it required? If there is no https transport configured to WAS, the plugin will downgrade to use the http transport from plugin to WAS. This may be OK if the web servers are in same DMZ or physical server as the application servers.

On the WAS Admin console go to Servers => Application Servers => server => Ports

For the WC_defaulthost_secure go to the link for “View associated transports”

(16)
(17)

Setting up SSL from Plugin to WAS

When https is required

WAS admin console

plugin-key.kdb is installed by default when a https transport is

configured

WAS has personal certificate with self signed signer certificate.

Populate the signer list with signer certificate of the trusted Certificate Authorities or the one received from the personal certificate assignment.

(18)

SSL between Plug-in and WebSphere Application

Server

 HTTP Server (IBM Http Server, IIS, etc)

 (Plugin for WAS) installation required for plugin communication.

By default plugin use – plugin-cfg.xmlplugin-key.kdb

plugin-key.sth

 WebSphere Application Server

NodeDefaultKeyStoreNodeDefaultTrustStore

• WAS_HOME/profiles/profileName/config/cells/cellName/nodes/nodeName

(19)

Setting up SSL from Plugin to WAS

WebSphere Plugin will install on the webserver with a default plugin-key.kdb file and plugin-key.sth file

This file will have a default password of WebAS. It is expired as of 04/26/2012 and the password must be updated.

There is a self signed personal certificate that is also expired and a new one would need to be created if client authentication is configured at the WAS admin console

This is not the same .kdb file that the IHS web server is using and

therefore requires the stash file so that IHS is able to open the file for https transports.

(20)

Setting up SSL from Plugin to WAS

WebSphere 7.0 ships with a keyfile that is preconfigured to work with the DummyKeyring.jks file or .p12 that the WebSphere Application Server uses for SSL enablement. All these files are installed in the WebSphere etc directory.

If you have a HTTPS Transport defined in the application server that is enabled for SSL all you have to do is regenerate the plugin config file and the transport will be added to the plugin configuration for you.

By default, it will configure the plugin for SSL using the keyfile/stashfile shipped with WAS. The password for this keyfile is WebAS.

(21)

Setting up SSL from Plugin to WAS

Go to plugin properties and propagate plugin-key.kdb to web server. Web server is managed or unmanaged.

(22)

Setting up SSL from Plugin to WAS

If for some reason you want to enable the plugin manually all you would need to do is add the following stanza to the server definition you want to use SSL.

<Transport Hostname="APP_SERVER_HOST"

Port="APP_SERVER_SSL_PORT" Protocol="HTTPS>

<Property name="keyring" value="APP_SERVER_ROOT/etc/plugin- key.kdb"/>

<Property name="stashfile" value="APP_SERVER_ROOT/etc/plugin- key.sth"/>

(23)

Setting up SSL from Plugin to WAS

The plugin keystore (plugin-key.kdb) must have a signer in the signer list that matches the correct SSL signer certificate. It must match the signer of the WAS personal certificate.

The Plugin-key.kdb must have signer certificate for every WebSphere Node.

The Plugin-cfg.xml could be updated to use the same key.kdb file that is used by IHS web server. This is strongly discouraged.

(24)

From WAS admin console

Go to:

Security > SSL certificate and key management > Manage endpoint security configurations.

Click on WAS node (NodeDefaultSSLSettings)

Click on Key stores and certificates on the right side Click on NodeDefaultKeyStore

(25)

You will see a chained certificate. The personal certificate is the first one in the chain. The signer certificate is the second one in the chain. Note the CN in the signer

certificate. Also look at the serial number of the signer certificate.

Go back to the Key store and certificates page. Click on NodeDefaultTrustStore

(26)

Find the signer that matches the serial number, click on Extract

Enter a temporary path and filename (for example: /tmp/nodeRootSigner.arm). Click OK. Go back to the Manage endpoint security configurations page.

(27)

Find the node which contains the web server definition. You will need to look inside the node and look inside the servers folder to find the web server (for example: webserver1). Click on the web server name.

•Click on Key stores and certificates on the right side.

•Click on CMSKeyStore (this is a link to the plugin-key.kdb file).

(28)

Click Add. Enter an Alia

Click Add.

Click add

Enter an Alias like "NodeRootSigner", and enter the path and filename from (for example: /tmp/nodeRootSigner.arm). Click OK.

Click Add.

(29)

Click Add. Enter an Alia

Click Add.

Enter an Alias like "NodeRootSigner", and enter the path and filename from step 7 (for example: /tmp/nodeRootSigner.arm). Click OK.

Save changes, go to Servers > Server Types > WebServers, click on the web server name (webserver1) and go to Plugin properties. Copy to web server key store

(30)

Propagate to web server

Path to .kdb (plugin-key.kdb) is found in the plugin-cfg.xml (from httpd.conf)  Path to .sth (plugin-key.sth) is also required

<Server Name="server1" ConnectTimeout="5" ExtendedHandshake="false"

ServerIOTimeout="60"

LoadBalanceWeight="1" MaxConnections="-1" WaitForContinue="false"> <Transport Hostname="IBM-7LL06ACAMCV" Port="9080" Protocol="http"/> <Transport Hostname="IBM-7LL06ACAMCV" Port="9443" Protocol="https"> <Property name="keyring" value=

"C:\Program Files\IBM\HTTPServer\Plugins/etc/plugin-key.kdb"/> <Property name="stashfile" value=

"C:\Program Files\IBM\HTTPServer\Plugins/etc/plugin-key.sth"/>  </Transport>

(31)

 IHS web server has a built-in list of cipher specifications to use for communicating with clients over SSL. The actual cipher specification that is used for a particular client connection is selected from those which are supported by both IHS and the client.

 Some cipher specifications provide a weaker level of security than others, and might need to be avoided for security reasons. Some of the stronger cipher specifications are more computationally intensive than weaker cipher

specifications and might be avoided if required for performance reasons. You can use the SSLCipherSpec directive to provide a customized list of cipher

specifications that are supported by the Web server in order to avoid the selection of cipher specifications that are considered too weak or too computationally

intensive.

 See InfoCenter for list of supported Cipher specs for SSL version 2, SSL version 3 and TLS version 1.0.

(32)

Tips and Troubleshooting

Personal Certificates may have intermediate signers. All must be in the signer list.

(33)

Tips and Troubleshooting

Identify the root by the certificate that is signed by itself

Pinging 9.37.235.27 with 32 bytes of data:

This screen shot shows a CA root certificate that is not trusted

To correct you would need to add the Corp-Root-CA signer list In this example add it to the IE browser

(34)

Tips and Troubleshooting

.kdb Password expires

Sans certificates

Subject Alternative Names let you protect multiple host names with a

single SSL certificate

Break it down by trying to hit IHS splash screen first

https://IHS.server.com /* default port is :443 */

Hit WAS secure port directly

https://WAS.server.com:9443 You can use browser to display the certificate and compare it with the certificate signer in IHS key.kdb

If you receive an error message stating that "All the signer certificates must exist in the key database", then go back and confirm that the Root Signer certificate and Intermediate Signer Certificate, if used, are both in the key database

(35)

Tips and Troubleshooting

The following error is logged in the plug-in log file:

Failed in r_gsk_secure_soc_init: GSK_ERROR_BAD_CERT(gsk rc = 414)

Key size 2048

(36)

Using other tools to look at certificates

 OpenSSL

 Windows

Copy certificate to .cer file and double click on windows server. Microsoft Windows “Certificate” panel requires this file type.

(37)

Viewing Certificate in IKEYMAN

(38)

KDB Password Expiration

In addition to the certificate, the keystore (.kdb) that the certificate is stored in, may have a password that is set to expire.

Prompted to set password during keystore creation.

Newer versions of iKeyman allow you to check the password expiration date.

(39)

Converting p12 to CMS

IBM's SSL is NOT OpenSSL as used in Apache.

The SSL certificate database on an Apache HTTP Server is a different format than what is used by IBM.

The process involves moving the Apache certificate into a .p12 file (PKCS12 format) to import into the IBM HTTP Server .KDB file (CMS format) key database.

(40)

Summary

 SSL from a Client to a WebSphere Application Server (WAS) application is a 2 part SSL configuration

 IHS web server uses .kdb vs WAS Keystore

 SSL from Client to IHS web server is server and sends personal certificate

 The KDB passwords and .sth file

 SSL from WebSphere Plugin to WAS Plugin is Client and needs WAS signer

 Entire chain certificate of chained certificates must be in signer list.

 Cipher negotiation

(41)

Additional WebSphere Product Resources

 Guide to properly setting up SSL within the IBM HTTP Server

http://www-01.ibm.com/support/docview.wss?uid=swg21179559

 GSK_BAD_CERT error

http://www-01.ibm.com/support/docview.wss?uid=swg21433593

 Using iKeyman to update certificates

https://www-304.ibm.com/support/docview.wss?uid=swg21045925

 Unable to add signer or personal certificates to the Key Management Utility .kdb file

(42)

Additional WebSphere Product Resources

 Learn about upcoming WebSphere Support Technical Exchange webcasts, and access previously recorded presentations at:

http://www.ibm.com/software/websphere/support/supp_tech.html

 Discover the latest trends in WebSphere Technology and implementation, participate in technically-focused briefings, webcasts and podcasts at:

http://www.ibm.com/developerworks/websphere/community/

 Join the Global WebSphere Community:

http://www.websphereusergroup.org

 Access key product show-me demos and tutorials by visiting IBM® Education Assistant:

http://www.ibm.com/software/info/education/assistant

 View a webcast replay with step-by-step instructions for using the Service Request (SR) tool for submitting problems electronically:

http://www.ibm.com/software/websphere/support/d2w.html

 Sign up to receive weekly technical My Notifications emails:

(43)

Connect with us!

1.

Get

notified

on upcoming webcasts

Send an e-mail to [email protected] with subject line “wste subscribe” to get a list of mailing lists and to subscribe

2.

Tell us what you want to learn

Send us suggestions for future topics or improvements about our webcasts to [email protected]

3.

Be connected!

Connect with us on Facebook

(44)

References

Related documents

communicate using proper framing terminology. Define and use terminology related to wall framing. Identify and collect materials and tools needed to complete the assignment.

For example, if the StreamServer is both an SSL server (specified using an HTTPS input connector) and an SSL client (specified using an HTTPS Submit output connector or HTTPS

The keystore contains the SSL certificate that the Cisco IPICS server uses to verify its identity when a client attempts to connect to the server, and the URL for the web

Supporting this result, cultures containing marine ANME-1 and ANME-2 were shown to incorporate carbon derived from labelled methane into archaeol, monounsaturated archaeol

Pufferbench: Evaluating and Op- timizing Malleability of Distributed Storage, in Proceedings of 2018 IEEE/ACM 3 rd Inter- national Workshop on Parallel Data Storage &amp; Data

The tortuous debate about aviation capacity in the South East of England which spans across more than four decades, and is yet to produce an effective way of tackling congestion

The present study has been carried out to examine the self-citation pattern in IASLIC Bulletin on the same line as Rattan (2013) has carried out in his study.. Review

The purpose of this paper is to provide a background to and guide for mainstreaming Disaster Risk Man- agement (DRM) into higher education and training institutions in Small