Access Manager Appliance enables SSL communication with the Default Reverse Proxy and Identity Server, using a self signed certificate.
You can configure 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.
See the following topics:
When 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 Identity Server must be configured to trust the CA that created the certificate for 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 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 Identity Server and one for 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 Identity Server:
Click Security > Certificates > New.
Select the Use External certificate authority option.
Specify the following details:
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.
Specify the following details:
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 Access Gateway.
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 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 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 Administration Console so that they are available to be assigned to key stores and trusted root stores.
Click Security > 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 Identity Server.
Click Security > Certificates, then click the name of certificate signing request for 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.
Repeat Step 6 through Step 12 for Access Gateway certificate.
NOTE: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.
Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].
In the Server Certificate line, click the Browse icon to select Access Gateway certificate.
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.
On the Server Configuration page, click Reverse Proxy / Authentication.
Update Access Gateway and Identity Server on respective pages.
To verify the trusted relationship between Identity Server and Access Gateway:
Enter the URL to a protected resource on 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 30.3.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 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 Access Gateway configuration.