NetIQ Access Manager Appliance enables SSL communication with the Default Reverse Proxy and the Identity Server, using a self signed certificate.
You can configure the Access Gateway to use SSL in its connections to the browsers, and to its Web servers.
However, the browsers are not set up to trust the Access Manager CA. You need to import the public key of the trusted root certificate (configCA) into the browsers to establish the trust.
This section describes how to set up SSL for the Access Gateway communication channels:
In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy].
To configure the reverse proxy for SSL, fill in the following fields:
Enable SSL with Embedded Service Provider: Select this option to encrypt the data exchanged for authentication (the communication channel between the Identity Server and the Access Gateway). This option is only available for the reverse proxy that has been assigned to perform authentication.
If you enable SSL between the browsers and the Access Gateway, this option is automatically selected for you. You can enable SSL with the embedded service provider without enabling SSL between the Access Gateway and the browsers. This allows the authentication and identity information that the Access Gateway and the Identity Server exchange to use a secure channel, but allows the Access Gateways to use non-secure channels with the browsers and the Web servers. This saves processing overhead if the data on the Web servers is not sensitive.
Enable SSL between Browser and Access Gateway: Select this option to require SSL connections between your clients and the Access Gateway. SSL must be configured between the browsers and the Access Gateway before you can configure SSL between the Access Gateway and the Web servers. For this process, see Enabling SSL between the Reverse Proxy and Its Web Servers.
Redirect Requests from Non-Secure Port to Secure Port: Determines whether browsers are redirected to the secure port and allowed to establish an SSL connection. If this option is not selected, browsers that connect to the non-secure port are denied service.
Generate a certificate key by using the Access Manager CA:
Click Auto-generate Key, then click OK twice.
On the Select Certificate page, make sure the certificate is selected, then click OK.
The generated certificate appears in the Server Certificate text box.
Configure the ports for SSL:
Non-Secure Port: Specifies the port on which to listen for HTTP requests. The default port for HTTP is 80. If you have selected the Redirect Requests from Non-Secure Port to Secure Port option, requests sent to this port are redirected to the secure port. If the browser can establish an SSL connection, the session continues on the secure port. If the browser cannot establish an SSL connection, the session is terminated.
Secure Port: Specifies the port on which to listen for HTTPS requests (which is usually 443). This port needs to match the configuration for SSL. If SSL is enabled, this port is used for all communication with the browsers. The listening address and port combination must not match any combination you have configured for another reverse proxy or tunnel.
In the Proxy Service List, click [Name of Proxy Service] > Protected Resources.
In the Protected Resource List, change the Authentication Procedure from an HTTP contract to an HTTPS contract.
For example, if a protected resource is using the Name/Password - Basic contract, click the name and change it to the Name/Password - Form, the Secure Name/Password - Basic or the Secure Name/Password - Form contract. Then click OK.
The Name/Password - Form contract is capable of using either HTTP or HTTPS.
To enable single sign-on, select the same contract for all the protected resources.
Click the Configuration Panel link near the bottom of the page, then in the confirmation box, click OK.
On the Server Configuration page, click Reverse Proxy / Authentication.
In the Embedded Service Provider section, click Auto-Import Identity Server Configuration Trusted Root, click OK, specify an alias, click OK twice, then click Close.
This option imports the public key of the Identity Server into the trust store of the embedded service provider. This sets up a trusted SSL relationship between the embedded service provider and the Identity Server.
The configCA public key certificate of the Access Manager CA is automatically added to the ESP Trust Store. If you are using Access Manager CA certificates for the Identity Server, you do not need to import the configCA certificate unless someone has deleted it from this trust store.
Click Configuration Panel, then in the confirmation box, click OK.
On the Server Configuration page, click OK.
On the Access Gateways page, click Update > OK.
Update the Identity Server so that it uses the new SSL configuration. Click Devices > Identity Servers, then click Update > OK.
Verify that the trusted relationship between the Identity Server and the Access Gateway has been reestablished:
Enter the URL to a protected resource on the Access Gateway. For example, enter
https://www.mytest.com
Complete one of the following:
If you are prompted for login credentials, enter them. The trusted relationship has been reestablished.
If you receive a 100101043 or 100101044 error, the trusted relationship has not been established. For information about solving this problem, see Section 26.5.2, Troubleshooting 100101043 and 100101044 Liberty Metadata Load Errors.
To enable SSL between the reverse proxy and the Web servers, you must have already performed the following tasks:
Enabled SSL between the Access Gateway and the browsers. See Section 3.6.1, Configuring a Reverse Proxy and select the Enable SSL between Browser and Access Gateway field.
Enabled SSL on the Web server. See your Web server documentation.
If you have completed these tasks:
In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers.
The Web Servers configuration page appears.
To configure SSL, select Connect Using SSL.
This option is not available if you have not set up SSL between the browsers and the Access Gateway. See Section 3.6.1, Configuring a Reverse Proxy and select the Enable SSL between Browser and Access Gateway field.
In the Connect Port field, specify the port that your Web server uses for SSL communication.
Configure how you want the certificate verified. The Access Gateway supports different options. Select one of the following:
Do not verify: Select this option if you do not want to verify the Web Server Trusted Root certificate. Continue with Step 3.
To verify the certificate authority of the Web server certificate, select Any in Reverse Proxy Trust Store. When this option is selected, the public certificate of the certificate authority must be added to the proxy trust store.
IMPORTANT:For an Access Gateway Service, this option is a global option. If you select this option for one proxy service, all proxy services on an Access Gateway Service are flagged to verify the public certificate. This verification is done even when other proxy services are set to Do not verify.
Click the Manage Reverse Proxy Trust Store icon. The auto import screen appears.
Ensure that the IP address of the Web server and the port match your Web server configuration.
If these values are wrong, you have entered them incorrectly on the Web server page. Click Cancel and reconfigure them before continuing.
Click OK.
Wait while the Access Gateway retrieves the server certificate, the root CA certificate, and any CA certificates from a chain from the Web server.
Specify an alias, then click OK.
All the displayed certificates are added to the trust store.
Click Close.
(Optional) For mutual authentication:
Select the certificate. Click the Select Certificate icon, select the certificate you created for the reverse proxy, then click OK.
Import the trusted root certificate of the CA that signed the proxy service’s certificate to the Web servers assigned to this proxy service.
See your Web server documentation for instructions.
Click Configuration Panel, then click OK.
On the Configuration page, click OK.
On the Access Gateways page, click Update.
(Optional). Test this configuration from a client browser:
Enter the published DNS name as the URL in the browser.
Click the links that require authentication for access.
When the Identity Server is configured to use an SSL certificate that is signed externally, the trusted store of the embedded service provider for each component must be configured to trust this new CA. The browsers that are used to authenticate to the Identity Server must be configured to trust the CA that created the certificate for the Identity Server. If you obtain a certificate from a well-known external CA, most browsers are already configured to trust certificates from well-known CAs.
The following procedures explain how to use certificates signed by an external Certificate Authority.
The following sections explain how to create certificate signing requests for the Identity Server and Access Gateway, how to use the requests to obtain signed certificates, then how to import the signed certificates and the root certificate of the Certificate Authority into Access Manager Appliance.
You need to create two certificate signing requests: one for the Identity Server and one for the Access Gateway. The Certificate name and the Common name need to be different, but the other values can be the same.
|
What you need to know or create |
Example |
Your Value |
|
|---|---|---|---|
|
Certificate name |
ipda_test or lag_test |
________________________ ________________________ |
|
|
Certificate Subject Fields: |
|
|
|
|
Common name |
ipda.test.novell.com or lag.test.novell.com |
________________________ ________________________ |
|
Organizational unit |
novell |
________________________ |
|
Organization |
test |
_______________________ |
|
City or town |
Provo |
________________________ |
|
State or province |
UTAH |
_______________________ |
|
Country |
US |
|
To create a signing request for the Identity Server:
In the Administration Console, click Security > Certificates > New.
Select the Use External certificate authority option.
Fill the following fields:
Certificate name: idpa_test
Signature algorithm: Accept the default.
Valid from: Accept the default.
Months valid: Accept the default.
Key size: Accept the default.
Click the Edit icon on the Subject line.
Fill in the following fields:
Common name: idpa.test.novell.com
Organizational unit: novell
Organization: test
City or town: Provo
State or province: UTAH
Country: US
Click OK twice, then click the name of the certificate.
Click Export CSR.
The signing request is saved to a file.
Repeat Step 1 through Step 7 to create a signing request for the Access Gateway.
You can send the certificate signing request to a certificate authority and wait for the CA to return a signed certificate or you can use a trial certificate for testing while you wait for the official certificate. Companies such as VeriSign offer trial signed certificates for testing.
Modify the following instructions for the CA you have selected to sign your certificates:
Set up an account with a certificate authority and select the free trial option.
Open your certificate signing request for the Identity Server in a text editor.
Copy and paste the text of the certificate request into the appropriate box for a trial certificate.
If CA requires that you select a server platform, select eDirectory if available. If eDirectory is not a choice, select unknown or server not listed.
Click Next, then copy the signed certificate and paste it into a new text file or at the bottom of the signing request file.
Click Back, and repeat Step 2 through Step 5 for the Access Gateway.
Follow the instructions of the vendor to download the root certificate of the Certificate Authority and any intermediate CA certificates.
The following steps explain how to imported the signed certificates and the trust root into the Administration Console so that they are available to be assigned to key stores and trusted root stores.
In the Administration Console, click Access Manager > Certificates > Trusted Roots.
Click Import, then specify a name for the root certificate.
Either click Browse and locate the root certificate file or select Certificate data text and paste the certificate in the text box.
Click OK.
The trusted root is added and is now available to add to trusted root stores.
(Conditional) Repeat Step 2 through Step 4 for any intermediate CA certificates.
In a text editor, open the signed certificate for the Identity Server.
In the Administration Console, click Access Manager > Certificates, then click the name of certificate signing request for the Identity Server.
Click Import Signed Certificate, then select Certificate data text (PEM/Based64).
Paste the text for the signed certificate into the data text box. Copy everything from
-----BEGIN CERTIFICATE-----
through
-----END CERTIFICATE-----
Click Add trusted root, then either click Browse and locate the root certificate file or select Certificate data text and paste the certificate in the text box.
(Conditional) For any intermediate CA certificates, click Add intermediate certificate, then either click Browse and locate the intermediate certificate file or select Certificate data text and paste the certificate in the text box.
Click OK.
The certificate is now available to be assigned to the keystore of a device.
If the certificate fails to import and you receive an error, it is probably missing a trusted root certificate in a chain of trusted roots. To determine whether this is the problem, see Resolving a -1226 PKI Error and Importing an External Certificate Key Pair.
Repeat Step 6 through Step 12 for the Access Gateway certificate.
This section explains how to enable SSL communication between the Access Gateway and the Identity Server and between the Access Gateway and the browsers.
In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy].
Select Enable SSL between Browser and Access Gateway.
In the Server Certificate line, click the Browse icon.
Select the Access Gateway certificate, then click OK.
IMPORTANT:If the external certificate authority writes the DN in reverse order (the cn element comes first rather than last), you receive an error message that the subject name does not contain the cn of the device. You can ignore this warning, if the order of the DN elements is the cause.
Specify an Alias for the certificate, then click OK > Close.
On the Reverse Proxy page, click OK.
On the Server Configuration page, click Reverse Proxy / Authentication.
Click OK twice to return to the Access Gateways page.
On the Access Gateways page, click Update.
Verify that the trusted relationship between the Identity Server and the Access Gateway has been reestablished:
Enter the URL to a protected resource on the Access Gateway.
Complete one of the following:
If you are prompted for login credentials, enter them. The trusted relationship has been reestablished.
If you receive a 100101043 or 100101044 error, the trusted relationship has not been established. For information about solving this problem, Section 26.5.2, Troubleshooting 100101043 and 100101044 Liberty Metadata Load Errors.
SSL renegotiation is the process of establishing a new SSL handshake over an existing SSL connection. SSL renegotiation can be initiated either by the SSL client or the SSL server. Initiating an SSL renegotiation on the client or the server requires different set of APIs. The renegotiation messages (ciphers and encryption keys) are encrypted and then sent over the existing SSL connection to establish another session securely and is useful in the following scenarios:
When you require a client authentication.
When you require a different set of encryption and decryption keys.
When you require a different set of encryption and hashing algorithms.
SSL renegotiation is enabled or disabled by the following parameter: "sun.security.ssl.allowUnsafeRenegotiation.
NOTE:By default this parameter is disabled.
This is defined in a registry on Windows and a configuration file on SLES.
You can verify whether the Identity Server, Access Gateway and Administration Console support secure renegotiation by using the following command:
openssl s_client -connect <IP address of the Access Manager component:port>
Port can either be 8443 or 443 based on the Access Gateway configuration.