|
|
|
SSL Client Certificates and Reflection for the Web Security Proxy
Technical Note 1879
Last Reviewed 10-Aug-2006
Applies To
Reflection for the Web 2008 (All Editions except Standard)
Reflection for the Web version 8.0 through 9.6
Summary
Technical Note 1879
Last Reviewed 10-Aug-2006
Applies To
Reflection for the Web 2008 (All Editions except Standard)
Reflection for the Web version 8.0 through 9.6
Summary
This technical note explains how to configure the Reflection for the Web Security Proxy to use SSL client certificates.
Note the following:
- Beginning in Reflection for the Web 2008, the security proxy server is not included in the Standard Edition.
- Reflection for the Web cannot be used to create client certificates. Client certificates must be generated from a third-party application.
- For information about using SSL client certificates with mainframe hosts, see Technical Note 1766.
- For information about using X.509 client certificate Access Control for authentication and authorization of Reflection for the Web sessions, see Technical Note 1756.
- Client certificates are an optional feature of the security proxy that can augment the security of Reflection for the Web. It may be desirable to use client certificates if no other Access Control authentication option, such as LDAP, SSO through IIS, SSO through Windows, or portal authentication. is being used. When the security proxy is configured to check client certificates, only users who have a valid client certificate will be able to launch a session.
Determine How Many Client Certificates to Create
Before enabling and importing client certificates into the Reflection Security Proxy, you must decide if you will be using a single client certificate for all users, or unique 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 launching a secure session.
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 that is stored on the Reflection server, any user who can obtain a session from the Reflection Management Server will be able to present the client certificate to the security proxy. This method can be made more secure if Reflection for the Web is configured for authentication and authorization, for example, to use LDAP, SSO through IIS, SSO through Windows, portal authentication, or SiteMinder.
If you choose to use the single certificate method, when you reach the Configure 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 to authenticate the user to the security proxy.
Advantage: This method is more secure. Only users who have a valid client certificate installed on their workstation (or a smart card—support for smart cards is new in Reflection for the Web 8.5) can launch a secure session.
Disadvantage: This method is more difficult to set up and maintain. Client certificates must be generated and distributed securely to each user and must be added to the security proxy’s trusted certificate store. However, if all the certificates are signed by the same root certificate authority, only the root certificate will need to be added to the security proxy’s trusted certificate store.
If you choose to use the multiple certificates method, when you reach the Configure Reflection for the Web section, follow the Certificate Per User steps.
Configure Reflection for the Web
Use a third-party Certification Authority (CA) application to generate a client certificate key pair for each user, such as the Microsoft Certificate Server.
Note the following:
- Reflection for the Web requires the client certificate to be in a .pfx or .p12 format.
- Reflection supports only files containing a single key-pair.
- It is not recommended that you obtain client certificates from a commercial CA such as Verisign or Thawte if you are going to authenticate against only the root CA certificate. If you import only the root certificate of a commercial Certificate Authority, then any certificate purchased from that vendor would be trusted by the security proxy.
Single Certificate for All Users
If you've decided to use a single client certificate for all users (see Determine How Many Client Certificates to Create), follow these steps to import the certificate into the Reflection Management Server.
- Use a third-party CA application to generate a client certificate key pair.
- Copy the certificate and key pair 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 client certificate for each user (see Determine How Many Client Certificates to Create), you have one more decision to make before creating the user certificate key pairs: do you want to use a single CA root certificate to sign all client certificates for users, or do you want to use multiple Certificate Authorities to issue client certificates?
A root certificate is the master certificate used to issue all other certificates. By installing and trusting a root certificate, you configure the host to trust all certificates signed by this certification authority. 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 security proxy is configured to trust the root certificate, a single user's certificate cannot be disabled. However, if your security proxy server is configured to support 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 user. Each user's unique certificate and private key is then copied to the user's workstation and the certificate is imported into the security proxy.
Advantage: This method gives you tighter control over individual certificates. If an employee leaves the company, their unique certificate can be removed from the security proxy trusted certificate store.
Disadvantage: This method is not recommended. Each certificate and private key must be copied to each user's workstation and each certificate must be imported into the proxy server.
Once you have determined if you will import the individual certificates or the root certificate 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.
- 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 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.
Configure the Security Proxy to Enable Client Authentication
Follow these steps to configure the Security Proxy:
- Start the Security Proxy.
- On the Advanced Settings tab, select Client authentication.
- On the Trusted Certificates tab, click Import and import each client certificate. If the client certificates all have the same root certificate, you need to import only the root certificate.
- Click Save, and then click Exit.
- Stop and restart the Security Proxy.
