How to Configure the CA Single Sign On Agent for SharePoint for SSL (HTTPS) Communications

Document ID : KB000010933
Last Modified Date : 27/03/2018
Show Technical Document Details
Introduction:

The CA Single Sign On Agent for SharePoint is a gateway or a proxy server-based solution that lets your CA Single Sign On Users gain access to resources in your Microsoft SharePoint environment. The Agent is based on the CA Access Gateway with the Federation Gateway enabled to provide access to the 'AffWebServices' WebService hosted on the TomCat Application Server to provide the Authentication or Validation of the SiteMinder Users making SharePoint resource requests. 

The CA Single Sign On Agent for SharePoint includes the 'ClaimsWS' WebService which coupled with the 'CASiteMinderClaimsProvider' provides the ability to perform SharePoint PeoplePicker searches against CA Single Sign On User Directories to allow Single Sign On Users to be added to the SharePoint User Policies. This WebService is also hosted on the Tomcat Application Server component of the CA Single Sign On Agent for SharePoint Server. 

In the CA Single Sign On Agent for SharePoint integration, requests for SharePoint resources are made against the Front-end 'Apache' component of the CA Single Sign On Agent for SharePoint Server, which is configured as the 'Public URL(s)'in the 'Alternate Access Mappings' in the SharePoint Central Admin for the protected SharePoint Application(s). The 'Mod_jk' component of the CA Single Sign On Agent for SharePoint Server is the connector to the TomCat component, and will pass these requests to the configured VirtualHosts configured in TomCat, where the Agent will then process the request. 

Once the request is Authorized, the request is allowed to proceed and the request will be processed against 'ProxyRules' configured to determine where to FORWARD the particular request. The TomCat Proxy will make a connection to the back-end SharePoint Server based on the ProxyRules configured in the ProxyRules.xml file, and then FORWARD the request and wait for a Response to then deliver back to the requesting client. 

 

What Components can be configured for SSL?

With the CA Single Sign On Agent for SharePoint system, there are three components that can be configured for SSL (HTTPS) communications; 

1. Apache Web Server (SSL Server)

The CA Single Sign On Agent for SharePoint Front-End Apache component can be configured to accept Browser requests over HTTPS via the 'httpd-ssl.conf' file. 

2. TomCat Application Server (SSL Server)

The CA Single Sign On Agent for SharePoint TomCat Application Server can be configured to accept 'Browser and SharePoint Web Front Ends (WFE's)' requests over HTTPS, and can optionally be configured to require "Client Authentication" for the SSL communications.

3. TomCat Proxy (SSL Client)

The CA Single Sign On Agent for SharePoint TomCat Proxy Server can be configured to make SSL Client connections to the Back-End SharePoint Servers via configurations in the 'ProxyRules.xml' and 'Server.conf' files. 

 

What Certificates are required to SSL enable these three components?

Apache Web Server (HTTPS Server) - A Server Certificate for each VirtualHost that is defined in both the httpd-ssl.conf and Server.conf files, with the RootCA Certificate(s) that signed the Server Certificate(s) copied into the 'ca-bundle.cert' file to allow the Apache Server to present the entire certificate chain to establish the SSL (HTTPS) connection with the Browsers. Browsers must "trust" the Server Certificate(s). 

TomCat Application Server (HTTPS Server) - A Server Certificate to be presented to Browsers and SharePoint WFE's on WebService requests stored in a JCEKS "KeyStore" in the "SSL/keys" directory, along with a JCEKS "TrustStore" that contains the imported "RootCA" Certificates that signed the Server Certificate if not Self-Signed. This will allow the TomCat Server to present the entire Certificate Chain to the SSL Client. 

OPTIONAL - Client Authentication - With "Client Authentication" enabled at the Agent for SharePoint's TomCat Server, not only is it required for the SSL Client to receive and "Trust" the Server Certificate in the SSL Handshake, but the Client (Browser or SharePoint WFE) must present their Client Certificate in the SSL Handshake, which the Agent for SharePoint's TomCat Server must "Trust". To enable the "Trust", the RootCA Certificates that signed the Browser and SharePoint WFE Client Certificates also need to be imported into the JCEKS "TrustStore" to allow the TomCat Server to "trust" the Client Certificates received in the SSL Handshake. The Browsers and SharePoint WFE's should be configured to present their Client Certificates. 

TomCat Proxy(HTTPS Client) - RootCA Certificates for the Back-End SharePoint Server Certificates copied into the ca-bundle.cert file to allow the TomCat Proxy to "trust" the Server Certificates from the Back-End SharePoint Server(s) that will be received during the SSL Handshake.

NOTE: It is up to the Administrator to obtain the appropriate Server and Client SSL certificates for the environment. This article provides an 'example' of using the 'KeyTool' utility to create the required JCEKS KeyStore and TrustStore for the TomCat Application Server. Providing guidence on generating the Server and Client Certificates for the remainder of the environment is outside of the scope of this article. Please consult your Corporate Certificate Authority.

Environment:
R 12.52 SP1 Agent for SharePoint
R 125.52 SP1 SPS (Secure Proxy Server)
R 12.6 CA Access Gateway (Formally SPS)
R 12.7 CA Access Gateway (Formally SPS)
Instructions:

Verify the Prerequisites

Verify the following prerequisites before enabling SSL:

• Farm administrator privileges and local administrator privileges for each SharePoint server in the farm.

• The java_home variable in your environment points to the proper JDK installation directory.For example, if you are using Java 1.7, your java_home variable must point to the installation directory for the Java 1.7 JDK.

• The Runtime version of Java is patched with the Java Cryptography Extensions (JCE) Patch.

• For UNIX/Linux operating environments, verify the following conditions: 

-The CA Single Sign On Agent for SharePoint environment variables are exported to your environment.

Run the following script:

<Agent-for-SharePoint_home>\ca_sps_env.sh

 

 The two "Servers" of the CA Single Sign On Agent for SharePoint should be configured for SSL at the same time to encrypt both the "access point" components; the TomCat Application Server and the Apache Web Server. 

  

TomCat Application Server (SSL Server) 

When the Single Sign On Agent for SharePoint's Web Services are configured for access over "HTTPS", during the SSL Handshake, the TomCat Application Server acting as the "SSL Server" in the communication must present a Server Certificate with a CN that matches the HostName of the Application Server, and the Browser or the SharePoint Web Front End must "Trust" this Server Certificate. The Server Certificate for the TomCat Application Server is stored in a JCEKS KeyStore. The Root Certificate(s) that signed the Server Certificate are stored in a JCEKS Trust Store to allow the full certificate chain to be presented in the SSL Handshake to the "SSL Client". 

With the "OPTIONAL" Client Authentication configured for the SSL communication for the TomCat Application Server, not only does the TomCat Application Server need to present a Server Certificate in the SSL Handshake to the "SSL Client", but the "SSL Client" (Browser or SharePoint WFE) must present a "Client Certificate" to the TomCat Application Server in the SSL Handshake as well. To allow the TomCat Application Server to "Trust" these "Client Certificates", the "RootCA" Certificates that signed the "Client Certificates" for the Browsers or SharePoint WFS's must be imported into the JCEKS Trust Store.

 

Create the JCEKS Key Store and Private Key for the TomCat Application Server

The JCEKS key store is a repository for the certificates and their related private keys. The certificate that you create are stored in the JCEKS KeyStore. 

This process requires the following information:

• An alias (nickname) for the server certificate you are requesting.

• A password for the JCEKS key store.

• The fully qualified domain name of the server hosting your CA Single Sign On Agent for SharePoint

• The name of your organizational unit (department or group)

• The name of your organization.

• The locality of your organization.

• The two-letter state and country codes for your organization.

 

Follow these steps:

1. Log in to the system hosting your CA Single Sign On Agent for SharePoint.

2. Open a command-line window.

3. Navigate to the following directory:

<Agent_for_SharePoint_home>\SSL\keys

4. Run the following command and enter appropriate values when prompted:

keytool -genkeypair -keysize <numbits> -keyalg RSA -keystore <Path_To_JCEKS_Keystore> -alias <Cert_Alias_Name> -storetype JCEKS -storepass <keystore_password>

eg. keytool -genkeypair -keysize 2048 -keyalg RSA -keystore .\ServerCert.jceks -alias MyAlias -storetype JCEKS -storepass password

 

NOTE: The JCEKS KeyStore must reside in the "<Agent_for_SharePoint_home>\SSL\keys" directory.

 

Generate a Certificate Signing Request and submit it to a Certificate Authority (CA)

 Follow these steps:

1. Run the following command and enter appropriate values when prompted:

keytool -certreq -v -alias <Cert_Alias_Name from #4 above> -sigalg <signingAlgorythm> -file <Path_To_Output_CSR> -keypass <key password> -keystore ServerCert.jceks -storepass <keystore password> -storetype JCEKS

 2. Submit the certificate signing request (CSR)to your Certificate Authority. 

  

Download and Import the Certificate Chain

 After your certificate has been signed, download and install the following items to the server hosting your CA Single Sign On Agent for SharePoint:

• The signed certificate.

• The certificate chain (any additional certificate-authority certificates that your certificate-authority issued).

 

This process requires the following information:

• The alias (nickname) of the server certificate you are importing.

• The password for the JCEKS key store.

 

Follow these steps:

1. Log in to the server hosting your CA Single Sign On Agent for SharePoint.

2. Download the following files with the same Web browser from which sent the certificate signing request: 

 <TomCatServerCert>.cer - (your signed certificate)

 <TomCatServerCert>.p7b - (the certificate chain)

("<TomCatServerCert>" is the name of your signed TomCat Application Server Certificate file.)

3. Move the files that you downloaded in Step 2 to the following directory:

<Agent_for_SharePoint_home>/SSL/keys

4. Import the certificate chain into the keystore;

keytool -importcert -v -noprompt -alias <Cert_Alias_Name> -file .\<TomCatServerCert>.p7b -keypass <key_password> -keystore <KeyStore_Name>.jceks -storepass <keystore_password> -storetype JCEKS

 eg. keytool -importcert -v -noprompt -alias TomCatServerCert -file .\TomCatServerCert.p7b -keypass MyKeyPassword -keystore ServerCert.jceks -storepass MyKeyStorePassword -storetype JCEKS

  

Define the KeyStore and the SSL Ports in the server.conf file

Add the following settings:

•The local SSL port number (defined when you ran the SharePoint Connection wizard).

•The path to the JCEKS KeyStore on the server that is hosting the CA Single Sign On Agent for SharePoint.

 

Follow these steps:

1. Open the following file with a text editor:

<Agent_for_SharePoint_home>\proxy-engine\conf\server.conf

 2. In the <localapp> section, locate the following line:

 #local.https.port=port_number

3. Remove the comment (#) from the beginning of the previous line.

4. Verify that the port number following the equal sign matches what you entered for the Claims WS service SSL port in the SharePoint connection wizard.

eg.  local.https.port=8443

5. Locate the following line:

#local.https.keyStoreFileName="tomcat.keystore"

6. Remove the comment (#) from the beginning of the previous line.

7. Replace "tomcat.keystore" with the relative path to the keystore from the "<Agent_for_SharePoint_home>/SSL/keys" directory.

eg.  local.https.keyStoreFileName="ServerCert.jceks"

8. Locate the following line:

#local.https.sslEnabledProtocols="TLSv1"

9. Remove the comment (#) from the beginning of the previous line.

eg.  local.https.sslEnabledProtocols="TLSv1"

10. Save the file and close text editor.

 

Generate an SSLConfig.properties File

 Follow these steps:

1. On the server hosting your CA Single Sign On Agent for SharePoint, open a command-line window.

2. Run the following command:

GenerateSSLConfig -keystorepass <keystore_password>

3. When prompted, enter the following values: 

<keystore_password> - (keystore password)

false - (Enable Client Authentication - OPTIONAL)

Important! OPTIONAL - Do not enable Client Authentication at this time. Client Authentication will be enabled when the required JCEKS "TrustStore" is created and the Browser and SharePoint WFE RootCA Certificates have been imported.

 

Create the JCEKS TrustStore and Import the RootCA Certificates

The RootCA Certificate chain that signed the TomCat Application Server's Server Certificate; if not a self-signed Server Certificate, needs to be imported into a JCEKS "TrustStore" to allow the Full Certificate Chain to be presented in the SSL Handshake with the SSL Clients (Browsers and SharePoint WFE's).

OPTIONAL - Client Authentication

With the OPTIONAL Client Authentication enabled, the TomCat Application Server needs to "Trust" the SSL Client Certificates that are presented by the Clients (Browsers/SharePoint WFE's) in the SSL HandShake. The RootCA Certificates that signed the Client Certificates (Browsers/SharePoint WFE's) need to be imported into the JCEKS "TrustStore" so that the TomCat Application Server can validate the Client Certificates. 

 

Follow these steps:

1. Log in to the server hosting your CA Single Sign On Agent for SharePoint.

2. Navigate to the "<Agent_for_SharePoint_home>/SSL/keys" directory.

3. Run the following command;

keytool -importcert -alias <Cert_Alias_Name> -file .\<TomCatServerCert>.cer -trustcerts -keystore .\<TrustStore_Name>.jceks -storepass <TrustStore_Password> -storetype JCEKS

 eg. keytool -importcert -alias TomCatServerCert -file .\TomCatServerCert.cer -trustcerts -keystore .\TrustStore.jceks -storepass MyTrustStorePassword -storetype JCEKS

4. Enter "yes" to trust the cert when prompted.

5. OPTIONAL - Client Authentication - Obtain the RootCA Certificates that signed the Client Certificates for the Browsers and SharePoint WFE's, and utilize the "keytool -importcert" utility to import the RootCA Certificates into the TrustStore.

eg. keytool -importcert -alias TomCatServerCert -file .\TomCatServerCert.cer -trustcerts -keystore .\TrustStore.jceks -storepass MyTrustStorePassword

 

Update the SSLConfig.properties File (OPTIONAL - Enable Client Authentication for TomCat Application Server)

Follow these steps:

1.Run the following command on the server that runs your CA Single Sign On Agent for SharePoint:

GenerateSSLConfig -keystorepass <keystore_password> -truststore .\<TrustStore_Name>.jceks -truststorepass <truststore_password>

eg. GenerateSSLConfig -keystorepass MyKeyStorePassword -truststore .\TrustStore.jceks -truststorepass MyTrustStorepassword

A confirmation prompt for your trust store password appears.

2. Re-enter your trust store password.

A confirmation prompt for client authentication appears.

3. Enter "yes" to enable Client Authentication (OPTIONAL) or "no" to leave Client Authentication disabled.

The SSLConfig.properties file is updated.

4. Re-start the Agent and Proxy. 

 

The TomCat Application Server is now configured to accept requests over SSL. To complete the configuration, the following Additional Steps are required in the environment;

 - Add a Trusted Root Authority to your SharePoint Farm

- Configure Trusted Identity Provider for SSL (Sign In URL)

- Register the Claims Search Service Endpoint for all SSO protected SharePoint Applications (ClaimsWS URL)

 

Add a Trusted Root Authority to your SharePoint Farm

Your SharePoint Farm requires a new Trusted Root Authority to validate and "trust" the Server Certificate that is received from the TomCat Application Server in the SSL HandShake. The following steps are provided as is. Please consult with your SharePoint Administrator on creating the required Trusted Root Authority for the ClaimsWS PeoplePicker requests.

 

Follow these steps:

1. Copy the TomCat Application Server certificates to a directory on your SharePoint Central Administration Server. Include the signed certificate that you downloaded from your Certificate Authority (<TomCatServerCert>.cer file) and all the certificates in the certificate chain (<TomCatServerCert>.p7b).

2. Login to the SharePoint Central Administration site.

3. Click "Security".

4. Under General Security, click "Manage trust".

5. Click "New".

The Create Trusted Relationship dialog appears.

6. Enter a name for the trust relationship.

7. Click the "Browse" button next to the Root Authority Certificate, and then locate the certificate that you copied over in Step 1.

8. Click "OK".

9. Repeat Steps 1 through 8 for each Certificate Authority certificate in your certificate chain.

The trusted root authority is created.

 

Configure Trusted Identity Provider for SSL (Sign In URL)

The SignInUrl of theCA SiteMinder® Trusted Identity Provider (Token Issuer) needs to be updated with the HTTPS Protocol.

 

Follow these steps:

1. Log in to your SharePoint Central Administration Server.

2. Open the Microsoft SharePoint Management Shell and Run as a Administrator.

3. Verify the following settings by running the 'Get-SPTrustedIdentityTokenIssuer' command:

- The name of the provider (such as "MyTrustedIdentityProvider")

- The current SignInUrl (such as http://MyTomCatServer.MyCompany.com/affwebservices/public/wsfeddispatcher).

4. Run the following command to modify the Protocol of the "SignInURL" to "https";

Set-SPTrustedIdentityTokenIssuer <Trusted_Identity_Provider_Name> -SignInUrl https://<FQDN_TomCat_App_Server>/affwebservices/public/wsfeddispatcher

eg. Set-SPTrustedIdentityTokenIssuer MyTrustedIdentityProvider -SignInUrl https://MyTomCatServer.MyCompany.com/affwebservices/public/wsfeddispatcher

5. Run the Get-SPTrustedIdentityTokenIssuer command again to verify the change to the SigInUrl.

 

Note: For more information about the 'Set-SPTrustedIdentityTokenIssuer' command, see http://technet.microsoft.com/en-us/library/ff607792.aspx 

 

Register the Claims Search Service Endpoint for all SSO protected SharePoint Applications (ClaimsWS URL)

 The next step in establishing the mutual trust relationship is registering the claims search service endpoint on all WFE servers in your SharePoint farm. Registering a new end point for the claims search service associates the secure connection with the client authentication certificate. A PowerShell script that is installed with the claims provider automates the registration process. 

 

Follow these steps:

1. Log into the SharePoint Central Admin system where the 'CASiteMinderClaimsProvider' is installed.

2. Open the Microsoft SharePoint Management Shell and Run as a Administrator.

3. Remove any previously registered CA SiteMinder® claims service from the Applications by running the following script:

<SharePointClaimsProvider_directory>\scripts\Remove-SMClaimSearchService.ps1 -WebApplication "url_of_SharePoint_web_application[:PORT]

eg. .\Remove-SMClaimSearchService.ps1 -WebApplication "http://SharePointWebApplication.example.com:8286/"

4. Repeat Step 3 for each SharePoint Web Application protected by the CA Single Sign On Trusted Identiry Provider(s).

5. (OPTIONAL) If enabling "Client Authentication" for the TomCat Application Server;

a. Enter the following command for your first web application:

<SharePointClaimsProvider_directory>\scripts\Add-SMClaimSearchService.ps1 -WebApplication <url_of_web_application> -ClaimSearchService https://<claims_search_service_url> -EnableSSLClientAuthentication -ClientCertificateName <name_in_Issued-To:_field_of_SharePoint_Client_Certificate>

eg. C:\CA\CASiteMinderClaimsProvider\scripts\Add-SMClaimSearchService.ps1 -WebApplication http://SharePointWebApplication.example.com:8286/ -ClaimSearchService https://MyTomCatServer.MyCompany.com:8443/ClaimsWS/services/WSSharePointClaimsServiceImpl -EnableSSLClientAuthentication  -ClientCertificateName SharePointWebApplication.example.com

b. Repeat Step a for each SharePoint Web Application protected by the CA Single Sign On Trusted Identity Provider(s).

c. Skip to step 8.

6. Enter the following command for your first web application:

<SharePointClaimsProvider_directory>\scripts\Add-SMClaimSearchService.ps1 -WebApplication <url_of_web_application> -ClaimSearchService https://<claims_search_service_url>

eg. C:\CA\CASiteMinderClaimsProvider\scripts\Add-SMClaimSearchService.ps1 -WebApplication http://SharePointWebApplication.example.com:8286/ -ClaimSearchService https://MyTomCatServer.MyCompany.com:8443/ClaimsWS/services/WSSharePointClaimsServiceImpl

7. Repeat Step 6 for each SharePoint Web Application protected by the CA Single Sign On Trusted Identity Provider(s).

8. Restart the SharePoint Central Admin Server.

 

This completes the SSL configuration for the TomCat Application Server.

 

  APACHE Server (SSL Server)

The Apache Server supports virtual hosts, which are multiple Web hosts that are run from a single Apache binary. Apache virtual hosts can be name-based or IP-based. Name-based virtual hosts can share a single IP address, while IP-based virtual hosts require a different IP address for each virtual host. Apache virtual hosts using the SSL protocol must have virtual host containers in the Apache configuration file for both secure (HTTPS) and not secure (HTTP) requests.

 

The following is an "example" of a secure (HTTPS) virtual host from the httpd-ssl.conf file:

 

<VirtualHost *:443>

 

DocumentRoot "C:/CA/Agent-for-SharePoint/httpd/htdocs"

ServerName MyVirtualHost.MyCompany.com

ServerAdmin webadmin@MyCompany.com

 

SSLEngine on

SSLProtocol +TLSv1

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

 

SSLCACertificateFile "C:/CA/Agent-for-SharePoint/SSL/certs/ca-bundle.cert"

SSLCertificateFile "C:/CA/Agent-for-SharePoint/SSL/certs/MyVirtualHostCert.cer"

SSLCertificateKeyFile "C:/CA/Agent-for-SharePoint/SSL/keys/MyVirtualHostKey.key"

 

SSLVerifyClient none

SSLVerifyDepth  10

 

SSLOptions +StdEnvVars +ExportCertData

<Files ~ "\.(cgi|shtml|phtml|php3?)$">

    SSLOptions +StdEnvVars

</Files>

<Directory "C:/CA/Agent-for-SharePoint/httpd/cgi">

    SSLOptions +StdEnvVars

</Directory>

</VirtualHost>

 

The Apache VirtualHosts for the Apache Front-end are defined in the 'httpd-ssl.conf' file located in the "<Agent-For-SharePoint-Home>\httpd\conf\extra\" directory. The three following parameters define the location of the SSL Certificates required for each VirtualHost; 

 SSLCACertificateFile - Used to define the location of the "Root CA Bundle File" used to hold the RootCA Certificates that signed the Server Certificate for the VirtualHosts.

NOTE: The 'SSLCACertificateFile' parameter must point to the "<Agent_for_SharePoint_home>/SSL/certs/ca-bundle.cert" file.

 SSLCertificateFile - Used to define the location of the Server Certificate for the VirtualHost.

SSLCertificateKeyFile - Used to define the location of the "PrivateKey" for the VirtualHost's Server Certificate.

 

For each Apache VirtualHost;

1. Generate a PrivateKey for the VirtualHost in the "<Agent_for_SharePoint_home>/SSL/keys/" directory.

2. Generate a Server Certificate Signing Request and submit it to a Certificate Authority (CA).

3. Download the Signed Server Certificate to the "<Agent_for_SharePoint_home>/SSL/certs/" directory.

4. Copy the Base64 PEM encoded RootCA Certificate(s) that signed the VirtualHost's Server Certificate into the "<Agent_for_SharePoint_home>/SSL/certs/ca-bundle.cert" file.

5. Modify the httpd-ssl.conf file to update the 'SSLCertificateFile' and 'SSLCertificateKeyFile' parameters, and modify the remaining parameters appropriately for your environment.

 

Enable SSL for the Apache Server

To enable SSL on your CA Single Sign On Agent for SharePoint, do one of the following procedures, as appropriate.

•Enable SSL for an unencrypted private key on Windows

•Enable SSL for an unencrypted private key on UNIX

•Enable SSL for an encrypted private key

 

Enable SSL for an Unencrypted Private Key on Windows

To enable SSL for an unencrypted private key on Windows, generate an spsapachessl.properties file.

 

Follow these steps:

1. Open a command-line window with administrative privileges. Navigate to the following directory:

<Agent-for-SharePoint_home>\httpd\bin

2. Run the following script file:

configssl.bat -enable

Note: If an overwrite warning appears, confirm that you want to overwrite the existing spsapachessl.properties file. 

 

Enable SSL for an Unencrypted Private Key on UNIX

To enable SSL for an unencrypted private key on UNIX, edit the spsapachessl.properties located in the following location:

<Agent-for-Sharepoint_home>/httpd/conf/spsapachessl.properties

 

Follow these steps:

1. Open the spsapachessl.properties file in a text editor.

2. Search for the following line:

apache.ssl.enabled=

3. Do one of the following tasks:

- If the previous line does not exist, add it to the file. Then go to step 4.

- If the previous line exists, go to Step 4.

4. Edit the line as follows:

apache.ssl.enabled=Y

5. Save the changes to the spsapachessl.properties file and close the text editor.

 

 Enable SSL for an Encrypted Private Key 

To enable SSL for an encrypted private key, generate an spsapachessl.properties file.

 

Follow these steps:

1. Open a command-line window with administrative privileges.

2. Navigate to the following directory:

<Agent-for-SharePoint_home>\httpd\bin

3. Run one of the following script files: 

(Windows) - configssl.bat -enable <passphrase>

(UNIX) - configssl.sh <passphrase>

 

Note: If an overwrite warning appears, confirm that you want to overwrite the existing spsapachessl.properties file. 

 

The Apache Server is now configured to accept requests over SSL. To complete the configuration, the following Additional Steps are required in the environment;

- Modify Alternate Access Mappings

- Run the SharePoint Connection Wizard to change the protocol and port of the Authentication URL

- Update the Authentication Scheme protecting the "Authentication URL" for "HTTPS" if served from the Agent for SharePoint system
- Optional: To disable 'client authentication' within Apache, change the following configuration in the "\httpd_conf\conf\extra\httpd-ssl.conf" file.

SSLVerifyClient optional > SSLVerifyClient none 


Modify Alternate Access Mappings

Follow these steps:

1. Login to your SharePoint Central Administration Site.

2. Click Application Management.

3. Under Web Applications, click Configure Alternate Access Mappings.

4. Modify the "Public URL" for HTTPS and the proper SSL PORT for each SSO protected SharePoint Application.

 

 

Run the SharePoint Connection Wizard to edit the protocol and port of the Authentication URL

Follow these steps:

1. Log in to the server that runs your CA Single Sign On Agent for SharePoint.

2. Navigate to the following directory:

<Agent-for-SharePoint_home>/sharepoint_connection_wizard

3. Follow the appropriate step below for your operating environment:

Windows : Right-click on the 'ca-spconnect-12.0-version-win32.exe' executable and then select Run as administrator.

Solaris: Run sh ./ca-spconnect-version-sol.bin

Linux: Run sh ./ca-spconnect-version-rhel30.bin

 

The SharePoint Connection wizard starts.

4. Click Next.

The Login Details screen appears.

5. Enter the your Connection Wizard Credenttials and click "Next".

The Select Action screen appears.

6. Select Edit a SharePoint Connection option and click "Next".

The SharePoint Connection Properties screen appears.

7. Change the protocol of the Authentication URL to HTTPS and modify the PORT.

8. Click Install on the Commit Details screen.

The Save Complete screen appears.

9. Click Done.

 

The partnership details are saved, the SharePoint Connection is modified, and the wizard closes.

 

Update the Authentication Scheme protecting the "Authentication URL" for "HTTPS" if served from the Agent for SharePoint system

 If the Authentication Scheme protecting the Authentication URL (/affwebservices/redirectjsp/redirect.jsp) is hosted on the Agent for SharePoint system, modify the TARGET of the Authentication Scheme for HTTPS.

 

This completes the SSL configuration for the "Server" components of the Agent for SharePoint. The final component that can be SSL enabled is the TomCat Proxy Server acting as the "SSL Client" to the Back-End SharePoint Servers.

 

 

TomCat Proxy (SSL Client)

In order for the TomCat Proxy to connect to the Back-End SharePoint Servers over SSL, the TomCat Proxy; as the "SSL Client", needs to "Trust" the Server Certificates presented by the Back-End SharePoint Servers. To "Trust" these Server Certificates, copy the Base64 PEM encoded RootCA Certificate(s) that signed the SharePoint Server's Server Certificate(s) into the "<Agent_for_SharePoint_home>/SSL/certs/ca-bundle.cert" file. The entire chain of RootCA Certificates that signed the Server Certificate needs to be copied into the ca-bundle.cert file.

 

Follow these steps;

1. Using a text editor copy the base64 PEM encoded certificate for the RootCA certificate and all intermediary certificates in the certificate chain that signed the back-end Server Certificate into the "ca-bundle.cert" file.

------ BEGIN CERTIFICATE ------

 

thru

 

------ END CERTIFICATE ------

 

2. Verify the Protocol (versions) defined in the "<sslparams>" section configured in the Server.conf file match a supported Protocol for the back-end SharePoint Server.

eg. versions="TLSv1"

 

NOTE: For the R12.52 SP1 thru R12.52 SP1 CR-02 Agents, only the "SSLv3" and "TLSv1" Protocols are supported. The R12.52 SP1 CR-04 Agent and above supports "TLSv1", "TLSv1.1", and "TLSv1.2".

3. The Agents provide a default list of Ciphers in the "<sslparams>" section configured in the Server.conf file. Modify this list of ciphers to remove or add any required ciphers to match your security needs. Verify that the back-end Server has a matching cipher.

4. Modify the ProxyRules.xml file to FORWARD the requests over "HTTPS" and to the correct PORTS.

5. Re-start the Agent and Proxy Server.

 

This completes the SSL configuration for the TomCat Proxy (SSL Client).