*** This version of Confluence is for testing only and contains a copy of content from June 29th 2026. No changes will be preserved. ***
...
If you wish to have ALL traffic protected by SSL we recommend that you request "HTTPS" for the protocol. This will create a redirect so that any traffic that goes to http://\[my site]/ will be redirected to https://\[my site]/.
In some cases you may wish to only have a portion of your site protected by SSL while the option portion is not. In this case if you specify "BOTH" then you will be responsible for determining whether a page can be displayed using SSL or non-SSL.
...
Note that if you protect a directory with CU WebAuth and you go to the non-SSL site you will get the following error "CUWebAuth error... Server is not properly configured. Check the Kerberos principal.". In this case you need to be sure to specify the "https" URL and not the "http" URL to avoid getting the error. If you wish to setup a redirect from the non-SSL site to the SSL site for the ".htaccess" protected directory you'll either need to specify the redirect in a parent directory or via a custom vhost virtualhost include.
Migrating from a "legacy" configuration
...
This will case a problem for new "HTTP" configurations since CUWebAuth is not loaded for non-SSL traffic. One possible fix is to remove "require noprompt" if you wish to have no CUWebAuth protection. Note that special care should be taken to ensure that there are no directories beneath that were expecting cuwebauth to be enabled. This can be tricky configuration to verify that there is no risk of exposing files that should be protected.
Example of a problem configuration #2 (require valid-user)
...
In this case this configuration will NOT work with non-SSL traffic. You will need to ensure that an SSL certificate is obtained for your site and that CUWebAuth is enabled. Once you have SSL enabled you may notice that requests to the secure directory using http will generate a 500 error while requests to the https directory will work.
This case provides 4 3 possible solutions:
Solution A (recommended): VirtualHost Include
...
A very kludgy solution is to override the 403 error page and have it perform the redirect. This assumes that you add "SSLRequireSSL" to the existing ".htaccess" file that is producing the 500-error and override the top-level ErrorDocument 403 document. This description is intentionally vague and it is left as an exercise to implement. The major problem with this plan is that it will override a default error page that is also used when directory listings are prohibited and/or cuwebauth authorized denied errors.