This page last changed on Feb 21, 2007 by dave@atlassian.com.
This document describes how to configure Confluence to use a HTTPS encrypted secure socket layer for user logins and page data.
Unencrypted confidential data within Confluence may be intercepted by an attacker. To secure user logins, you can enable access via HTTPS (HTTP over SSL), and require its use for pages where passwords are sent. In some cases where issue data is sensitive, all pages can be set to be accessed over HTTPS.
Enabling SSL access is different for each application server, but specifying which pages to require protection for is generic. This document is specific to Tomcat, the default application server shipped with Confluence.
Adding Secure User Logins
Adding HTTPS requires a valid SSL certificate. If you have a Certificate prepared, skip to the 'Modify the <INSTALL>/conf/server.xml File' section.
Creating A New SSL Certificate
On Windows, perform the following at the command prompt:
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA
Or on other platforms, perform the following at the command prompt:
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
Some questions will be asked, including a password for the certificate (the default is 'changeit'). Please note down what you choose, as it will be used in the next step.
Modify the <INSTALL>/conf/server.xml File
In the confluence directory, open the conf/server.xml file and insert one of the following just after the closing </Engine> tag:
- For users of Confluence 2.2 or later:
Open conf/server.xml, uncomment the lines:
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
URIEncoding="UTF-8" keystorePass="<MY_CERTIFICATE_PASSWORD>" />
Or for users of Confluence 2.1.x or earlier, add or uncomment the following lines:
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8443" minProcessors="5" maxProcessors="75"
enableLookups="true" acceptCount="100" debug="0" scheme="https" secure="true"
useURIValidationHack="false" disableUploadTimeout="true" URIEncoding="UTF-8">
<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" clientAuth="false" protocol="TLS" keystorePass="<MY_CERTIFICATE_PASSWORD>" />
</Connector>
- Change <MY_CERTIFICATE_PASSWORD> to the password you entered for the certificate when you generated it.
If you have a Certificate Prepared
If you just created your new Certificate or your existing one is in the default location, skip to the 'Testing SSL' section. By default, Tomcat will look for the certificates in C:\Documents and Settings\\#CURRENT_USER#\.keystore on Windows or ~/.keystore on Unix. If your Certificate is not in this location, you will need to update your <INSTALL>/conf/server.xml file as outlined below, so that Tomcat can find it. Advanced users who require an official CA-issued key pair for their Certificate can find instructions in the Tomcat documentation.
- For users of Confluence 2.2 or later:
Open conf/server.xml, add the keystoreFile="<MY_CERTIFICATE_LOCATION>" parameter to the Connector tag as shown below:
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
URIEncoding="UTF-8" keystorePass="<MY_CERTIFICATE_PASSWORD>" keystoreFile="<MY_CERTIFICATE_LOCATION>" />
Or for users of Confluence 2.1.x or earlier, change the <Factory> tag to following:
<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" clientAuth="false" protocol="TLS" keystoreFile="<MY_CERTIFICATE_LOCATION>" keystorePass="<MY_CERTIFICATE_PASSWORD>" />
- Change <MY_CERTIFICATE_LOCATION> to the path of the Certificate.
Testing SSL
Restart Tomcat and access your instance on https://<MY_BASE_URL>:8443/
For more detailed information on setting up SSL with Tomcat (including additional configuration options), have a look at Tomcat 4 SSL Howto or Tomcat 5.5 SSL Howto.
Although HTTPS is now activated and available, the old HTTP URLs (http://localhost:8080) are still available. In most situations one wants these URLs to continue working, but for some to redirect to their HTTPS equivalent.
To configure which URL's you want secured, edit the confluence/WEB-INF/web.xml file and add to the end the following declaration:
<security-constraint>
<web-resource-collection>
<web-resource-name>Login and Restricted Space URLs</web-resource-name>
<url-pattern>/login.action</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Note that the example above specifies a url-pattern for the login URL /login.action. This means that whenever a user tries to access the unprotected version of the login page, they will be redirected automatically to the secured version of it.
If you want to protect individual spaces, there isn't a complete way of doing this at the moment. You can add a pattern like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>Login and Restricted Space URLs</web-resource-name>
<url-pattern>/login.action</url-pattern>
<url-pattern>/display/SALARIES/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
This will redirect all URL's for page views in the SALARIES space. This does not however, protect pages that are accessed via a URL like /pages/viewpage.action?pageId=123. Confluence generates these types of URL's for pages that have non-ASCII characters in the title. Hence this is not a complete solution.
If you want to protect all pages and spaces, use:
<security-constraint>
<web-resource-collection>
<web-resource-name>Restricted URLs</web-resource-name>
<url-pattern>*.action</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Once this change is made, restart Confluence and access http://localhost:8080. You should be redirected to https://localhost:8443/login.action.
 |
There does not seem to be an easy way to make subsequent pages revert to HTTP after logging in via HTTPS - see JRA-7250 |
Note for users of Confluence versions prior to 2.2
You are required to configure a Realm, even though the security-constraint above does not access it. Add this realm tag inside the Engine tag:
<Engine ...
<Realm className="org.apache.catalina.realm.MemoryRealm" />
...
</Engine>
 | You can protect other paths as necessary, but be aware that if attachments are protected, they will not be downloadable from Internet Explorer (see this issue). |
I am trying to set this up and running into a few issues.
I am not able to find a list web-resources when trying to edit the web.xml file.
Is there such a list??
Is there anyone that have a purely SSL environment??

Posted by gmurison at Jul 20, 2006 15:35
|
Please open a support request at http://support.atlassian.com

Posted by tom@atlassian.com at Jul 20, 2006 20:28
|
ust wanted to share this tip about creating SSL certificates.
This issues caused me hours of headache... so read and heed:
When you create your certificate with java's keytool, you are ABLE to specify one password for the "storepass" and one password for the "keypass". DO NOT, i repeat DO NOT make these different. THEY SHOULD USE THE SAME PASSWORD.
There you are, that's it... just saved you hours of headache...
You will never experience the joy of getting this error:
"LifecycleException: service.getName(): "Tomcat-Standalone"; Protocol handler start failed: java.io.IOException: Cannot recover key" REF: http://forum.java.sun.com/thread.jspa?threadID=728744
Another great resource:
http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services

Posted by sachsgang at Sep 21, 2006 10:27
|
Thanks for that info Aaron.

Posted by ivan@atlassian.com at Sep 21, 2006 17:33
|
Note that behavior of Internet Explorer is different for http and https because the standard main.vmd sets up HTTP-EQUIV headers that (some) web servers pay attention to. See
http://support.microsoft.com/default.aspx/kb/234067
It means that you can't go 'back' to a previous page result from a POST operation (such as the administration forms) and other inconveniences.
(I think the #standardHeader use of <META HTTP-EQUIV ...> is wrong, but that's a different issue.)

Posted by masinter at Dec 30, 2006 00:19
|
I am accessing Tomcat via Apache using the mod_jk connector. I also set SSL up for Apache on port 443 and created a VirtualHost with the JkMount to my confluence instance. Just changing the seraph-config.xml to point to
didn't force the https login (my confluence instance is located under webapps/ROOT so there is no contextpath - maybe that is part of the problem?) but instead went to the http login. To redirect to https, I ended up adding the following security-constraint to web.xml:
This was causing the redirect to https but still didn't quite work because the AJP connector by default was pointing to 8443 (and Apache was using 443). So I had to adjust $tomcat/conf/server.xml (I have Confluence running as a webapp under my own Tomcat - not the standalone confluence container):

Posted by medale at Jan 24, 2007 20:07
|
I'm using 2.3.1 and can access my localhost:8443. However, I want SSL only for login and find that modifying the link.url parameter in the seraph_config.xml file as described in the doucmentation does nothing and seems to by default append &os_destination=%2Fdashboard.action to the end of the login url. (even if I delete the parameter).
I find that the link.login.url parameter can be modified to generate the appropriate :8443/login.action url but doing so causes the entire session to be SSL.
I've also found that I can do the following to create https for login and then http for the remainder of session:
https://host:8443/confluence/login.action?os_destination=http://host:8080/confluence/dashboard.action
I'm not sure if this is secure and can't seem to generate the url after numerous attempts at modifying the seraph_config.xml parameters as the link.url parameter always adds its own default os_destination.

Posted by kvancleave at Jan 30, 2007 14:46
|
Hi Keith,
you may want to open a support ticket for that. Attach the different seraph_config.xml you tried as well as a precise explanation of what you are trying to achieve. Someone will help you there.
SaM

Posted by sleberrigaud at Feb 06, 2007 22:37
|
Silly question. If you front Confluence with Apache via a reverse proxy, do you still need to do this? The scenario I am thinking of is that Apache manages the connection with the browser, and here, we could use mod_rewrite or the standard Redirect directive to ensure that all requests are converted (via client side redirects) to SSL. As you are hitting the proxy, you cannot bypass this (i.e. if you half way through a session, and type http instead of https, the mod_rewrite rule would just convert back to SSL).
Would this work, and would this solution require no modification to the WEB.XML?

Posted by ricardo.sueiras@uk.pwc.com at Feb 27, 2007 16:07
|
Ricardo,
You can set up Apache to terminate the SSL connection and use the ProxyPass and ProxyPassReverse directives to pass the connection through to (say) tomcat which is running confluence.
I tried it this morning and it was pretty simply to set up.
- I created a new SSL host by creating a virtual host on 443
- The standard http connection on apache could be used to redirect to https if you want or it could just be firewalled. Up to you.
- Within the VirtualHost definition I:
- defined the SSL options (SSLEngin and SSLCertificateFile)
- defined the ProxyPass and ProxyPassReverse directives to pass through to Tomcat.
Because of how the ProxyPass and ProxyPassReverse directives work, you should not need to modify the tomcat installation at all.
Most of the relevant Apache Config:

Posted by mjensen at Feb 27, 2007 21:24
|
Matt - thanks, I am familiar with this config. However, the question I was asking is if the requests are proxies to the application server (in our case, WebSphere) over SSL, would there be any impact on the application configuration - i.e. any need to change the WEB.XML.
What I am trying to get away from is modifying the WEB.XML if at all possible, and retaining the application configuration "as is" (with the exception of the base URL of course). If I proxy the request via the Apache server, this takes care of the control element (assuming no-one can access the app server directly, which they cannot in our case) will all subsequent SSL requests to the app work without any tweaks?

Posted by ricardo.sueiras@uk.pwc.com at Feb 28, 2007 07:06
|
Yes, as long as the reverse proxy server (or ssl accelerator) is configured correctly, the tomcat instance behind it should not need to be changed at all.

Posted by mjensen at Mar 04, 2007 22:55
|
|