|
|
|
SSL Client Certificates and Reflection for the Web
Technical Note 1766
Last Reviewed 03-May-2007
Applies To
Reflection for the Web version 7.0 or higher
Summary
Technical Note 1766
Last Reviewed 03-May-2007
Applies To
Reflection for the Web version 7.0 or higher
Summary
This technical note explains how to configure Reflection for the Web to use SSL client certificates for direct host SSL connection and explains how to configure a z/OS or OS/390 mainframe for client certificate support.
Note the following:
- Client certificates are not required for SSL connectivity unless the host you are attempting to access is configured to require them. If you are unsure if your mainframe or AS/400 is configured for client certificates, contact your system administrator.
- Reflection for the Web does not create client certificates. Client certificates must be generated from a third-party certificate authority (CA) application.
- This technical note covers only client certificate configuration on an IBM mainframe. For details about enabling SSL on a z/OS or OS/390 mainframe, see Technical Note 1760. For information about enabling SSL on an iSeries or AS/400, see Technical Note 1759.
- For information about using X.509 client certificate Access Control for authentication and authorization of Reflection for the Web sessions, see Technical Note 1756.
- For information about using client certificates with the Reflection for the Web security proxy, see Technical Note 1879.
Client Certificate Configuration Options
Before enabling and importing client certificates you must determine the following:
- Host Configuration: Is the host configured for client certificates?
- Number of Certificates: Do you plan to use one certificate for all users or a unique certificate per user?
Read the following sections to help you answer these questions. When you are done, proceed to "Configuring Reflection and the Mainframe for Client Certificates."
Host Configuration
Before configuring your host for client certificates, the host must first be configured for SSL. For information about how to configure your systems to allow users to authenticate to a z/OS or OS/390 mainframe using SSL and Reflection for the Web, see Technical Note 1760. For information about how to configure your systems to authenticate to an iSeries or AS/400 using SSL and Reflection for the Web, see Technical Note 1759.
Client certificates are needed for SSL connections only if the host is configured to require them. If you are unsure about how your host is configured, contact your administrator.
Steps to configure the mainframe for SSL client certificate connections are provided later in this note, under Configuring the Mainframe. If your host is an AS/400, consult your vendor’s documentation for steps to enable SSL client certificates.
Number of Certificates
Reflection for the Web can be configured to use a single client certificate for all users, or individual certificates for each user.
Single Certificate Method
Using a single client certificate on the Reflection Management Server enables all users to use the same certificate when connecting to the host.
Advantage: The advantage of this method is that it is easier to implement and maintain. Using this method, a single client certificate is created and stored centrally. You do not have to create and distribute certificates to each user.
Disadvantage: This method is not very secure. Because all users are utilizing the same certificate, any Reflection user who can successfully launch a session through the Reflection Management Server can access the host. This method can be made more secure if Reflection for the Web is configured for authentication and authorization, for example, LDAP, SSO through IIS, SSO through Windows, portal authentication, or SiteMinder.
If you choose to use the single certificate method, when you reach the Configuring Reflection for the Web section, follow the Single Certificate for All Users steps.
Multiple Certificate Method
With this method, each user has a unique client certificate that is used when connecting to the host.
Advantage: This method is more secure. Only users who have a valid client certificate installed on their workstation or on a smart card (support for smart cards was introduced in Reflection for the Web 8.5) can connect to the host.
Disadvantage: This method is more difficult to set up and maintain. Client certificates must be generated and distributed securely to each user, and you must add either the root certificate or unique user certificates to the host’s trusted certificate store.
If you choose to use the multiple certificates method, when you reach the Configuring Reflection for the Web section, follow the Certificate Per User steps.
Configuring Reflection and the Mainframe for Client Certificates
Once you have read the Client Certificate Configuration Options section, and determined how you want to set up your client certificate structure, use the information in the following sections to configure Reflection and your mainframe for client certificates.
Configuring Reflection for the Web
To import client certificates for use by Reflection, follow the steps below to import a Single Certificate for All Users or a Certificate Per User.
Single Certificate for All Users
If you've decided to use a single client certificate for all users (see Number of Certificates), follow these steps to import the certificate into the Reflection Management Server.
- Use a third-party Certification Authority (CA) application to generate a client certificate key pair.
- Copy the certificate from your client certificate generation software into the /ReflectionData/Certificates folder.
- Access the Administrative WebStation, click Security Setup (or Settings in versions prior to 8.5), and then click the Certificates tab.
- Under Administer Client Certificate, click "Import a signed certificate and private key."
- On the Import a Key Pair screen, fill in the "Import the Key Pair" fields, and then click Submit.
When you click Submit, the client certificate is added to the client.pfx file located in the \ReflectionData\trustedcerts folder.
Certificate Per User
If you've decided to use a unique client certificate for each user (see Number of Certificates), you have one more decision to make before creating the user certificate key pairs: do you want to trust a single CA root certificate valid for all users or do you want to use individual certificates?
Root Certificate
A root certificate is the master certificate used to create all other certificates. By installing and trusting a root certificate, you configure the host to trust all certificates signed by this CA. Within a corporate environment, this often translates to trusting all company-signed certificates.
Advantage: A unique certificate is created (by the CA) for each user and copied to each user's workstation. Only the root certificate signed by the CA is copied to the host.
Disadvantage: Potentially, an employee leaving the company may retain their certificate key pair. Because the host is configured to trust the root certificate, a single user's certificate cannot be disabled. However, if your host supports certificate revocation lists (CRL), the CRL can be used to avoid this situation.
Individual Certificates
The root certificate is used to create individual key pairs for each users. Each unique key pair/certificate must be imported onto the correct workstation and the certificate must be imported to the host.
Advantage: This method gives you tighter control over individual certificates. If an employee leaves the company, their unique certificate and key pair can be disabled on the host.
Disadvantage: The certificate and private key must be copied to each user's workstation.
Once you have determined if you will import the root certificate or individual certificates to the host, follow the steps below to import the certificates and key pairs.
- Use a third-party Certification Authority (CA) application to generate a client certificate key pair for each user.
Note the following:
- Reflection for the Web requires the client certificate to be in a .pfx or .p12 format.
- Reflection supports files containing only a single key pair.
- Make a copy of each user's certificate.
- Copy each user's certificate to the \reflectionweb folder on their workstation and rename the file to client.pfx.
This folder is created the first time the user accesses Reflection for the Web. The path varies depending on the operating system and virtual machine being used. The Microsoft Windows Search feature can be used to locate the \reflectionweb directory.
Smart Cards—If you plan to use individual certificates, you may want to consider using smart cards. Smart cards are an alternative to manually installing client certificates to each user's local hard drive. Starting in Reflection for the Web 8.5, Reflection supports sessions connecting with PKCS #11 (Public-Key Cryptography Standard) smart card readers. If multiple certificates are present on the card, Reflection provides an interface for the user to select the correct certificate for the current host connection.
To enable smart card support in Reflection for the Web 8.5, follow these steps.
- Follow the vendor's instructions to install the certificate key pair onto the user's smart card.
- Follow the vendor's instructions to install the smart card reader and driver on the user's workstation.
- Specify the smart card driver reader .dll in the Reflection for the Web Administrative WebStation, in Security Settings > Security tab. Refer to the smart card documentation to determine the name of the .dll.
Once enabled, the users must insert their smart card into the reader before the Reflection host connection is attempted.
Configuring the Mainframe
Follow the steps below to configure the mainframe's working TCP/IP profile dataset to support client certificates.
To add support for client certificates, add one of the following parameters to the TELNETPARMS section of your host's TCPIP.PROFILE.TCPIP dataset:
CLIENTAUTH SSLCERTor
CLIENTAUTH SAFCERT- Use CLIENTAUTH SSLCERT if you want to check for a valid certificate.
- Use CLIENTAUTH SAFCERT if you want to check for a valid certificate and require that the certificate is known by RACF.
The following is a generic example of a TCPIP.PROFILE.TCPIP dataset that has been configured for SSL support and client certificates using the CLIENTAUTH SAFCERT parameter (use this example as a guide when configuring your dataset).
TELNETPARMS KEYRING HFS /u/keydb/os390r10.kdb ; Key database ; reference for the TCP/IP SSL connection. SECUREPORT 23001 ; Secure port number CONNTYPE SECURE CLIENTAUTH SAFCERT SSLTIMEOUT 30 TIMEMARK 28800 WLMCLUSTERNAME TN3270E ENDWLMCLUSTERNAMEENDTELNETPARMSBEGINVTAMPORT 23 23001 ; Add entry for secure port. TELNETDEVICE 3278-3-E NSX32703 TELNETDEVICE 3279-3-E NSX32703 . . .ENDVTAM |
After configuration is complete, each client certificate or root certificate must be imported into the hosts trusted certificate store. Consult your host's documentation for information about how to import the client certificate(s) or root certificate.
