Enable HTTP over SSL to employ more secure connections to your servers. Configure the following items in your environment according to the connections that you wish to secure:
- Author instance: Secure client connections to the author instance.
- Publish instance: Secure client connections to the publish instance.
- Replication agents on author: Secure connections from the author instance to the publish. instance.
- Web server that hosts Dispatcher: Secure client connections to the web server (and, indirectly, to the publish instance)
Create or obtain the credential that the server uses to sign HTTP messages:
- For development environments, a self-signed certificate is adequate. When self-signed certificates are used for SSL, the web browser requires you to manually trust the certificate when opening a web page.
- For production environments, use a certificate that is signed by a certificate authority (CA). When the public certificate of the CA is imported in the web browser, your certificate is automatically trusted.
Use the Java keytool to create a self-signed credential and to store it in a keystore file. The following procedure uses a single command that includes all of the information needed to create the keystore. For complete information about the command, see the Oracle Java SE Documentation.
keytool -genkeypair -keyalg RSA -validity 3650 -alias cqse -keystore [quickstart_dir]/ssl/keystorename.keystore -keypass key_password -storepass storepassword -dname "CN=Host Name, OU=Group Name, O=Company Name,L=City Name, S=State, C=Country_ Code"
The following example generates a private/public key pair with the following properties:
- alias: cqse
- keystore file: cqkeystore.keystore
- key password: password
- keystore password: password
keytool -genkeypair -keyalg RSA -validity 3650 -alias cqse -keystore ~/Applications/cq5.5/author/ssl/cqkeystore.keystore -keypass password -storepass password -dname "CN=sbroders-w7, OU=CQ, O=Adobe, L=Ottawa, S=Ontario, C=CA"
In production environments you should use a certificate that is signed from a trusted certificate authority (CA). Use the Java keytool to generate a certificate signing request, and when obtained import it to your keystore.
Name Type Value org.apache.felix.https.enable Boolean true org.osgi.service.http.port.secure Long 5433 org.apache.felix.https.nio Boolean true org.apache.felix.https.keystore String [quickstart_dir]/ssl/cqkeystore.keystore org.apache.felix.https.keystore.password String The password. org.apache.felix.https.keystore.key String alias e.g. cqse org.apache.felix.https.keystore.key.password String The password. org.apache.felix.https.truststore String Path to truststore org.apache.felix.https.truststore.password String Truststore password. (Optional) org.apache.felix.https.clientcertificate String Defaults to none
Enable HTTP over SSL on the publsih instance to secure connections with web clients and with replication agents. (Secure connections with replication agents also require changes to the agent configurations, which is described in the next section.)
Follow the same procedure as for configuring the author instance, with the following differences:
- Create the org.apache.felix.http node below /apps/system/config.publish on the publish instance (http://localhost:4503/crx/de).
- If your author and publish instances are on the same computer, use a different port for the org.osgi.service.http.port.secure property.
If you want content replication to occur using HTTP over SSL, configure replication agents to use the HTTPS protocol and the port that the publish instance uses for SSL.
The following procedure configures the publish agent on the author instance. Perform the procedure for all replication agents that you want to communicate over SSL.
The steps presented below do not force the use of the SSL port for HTTP requests to CRXDE Lite, Package Manager or Content Explorer. The requests going to these administrative consoles do not go through the Sling request pipeline. For these scenarios, you should utilize Dispatcher to redirect the requests by using the Apache Web Server. For further details, see the Dispatcher and the official Apache documentation.
The following example redirects traffic to localhost:4502 to https://localhost:5433. To configure the redirect, create a sling:mapping node. Use a node name that matches requested URL. Add a sling:redirect property to specify the URL for redirection.
Alternatively, you can specify the text for matching the requested URL as a sling:match property (See Mappings for Resource Resolution in the Apache Sling documentation).
When client requests target a dispatcher before reaching an author or publish instance, decide which requests are transmitted over SSL:
- From users to the web server.
- From the author instance to the dispatcher via the flush replication agent.
This section assumes that you have already installed and configured Dispatcher on your web server (See Dispatcher).
For information about configuring Dispatcher to use SSL connections with the publish instance, see Using SSL with Dispatcher.
Configure the web server to use SSL to secure connections between web clients and the web server. For information about enabling SSL for the web server, see the documentation for your web server.
- Apache HTTP Server: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html
- Microsoft IIS: http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis/
- Oracle iPlanet Web Server: http://docs.oracle.com/cd/E19146-01/821-1828/gbthq/index.html
Enabling separate caches for secure and unsecure connection types is beyond the scope of this article. However, you could investigate the following strategies:
- Route all SSL connections to a separate Apache web server and Dispatcher on a different subdomain.
- Use URL redirection rules (for example mod_rewrite directives on Apache) to cache content to different locations below DocumentRoot.
If you want to send flush requests to the dispatcher over SSL, configure the Dispatcher Flush replication agent.
Follow the procedure in Configure Replication Agents, using the SSL port that is confgured for the web server (typically 443).