Last updated 4 April 2017. Created on 11 November 2009.
Edited by hansfn, marcus7777, DamienMcKenna, TravisCarden. Log in to edit this page.

HTTPS is a protocol which encrypts HTTP requests and their responses. This ensures that if someone were able to compromise the network between your computer and the server you are requesting from, they would not be able to listen in or tamper with the communications.

When you visit a site via HTTPS, the URL looks like this: When you visit a site via plain (unencrypted) HTTP, it looks like this:

Why is it important to you (and when)

HTTPS is typically used in situations where a user would send sensitive information to a website and interception of that information would be a problem. Commonly, this information includes:

  • Credit cards
  • Sensitive cookies such as PHP session cookies
  • Passwords and Usernames
  • Identifiable information (Social Security number, State ID numbers, etc)
  • Confidential content

Especially in situations where you, as the administrator, are sending your Drupal password or the FTP password for your server, you should use HTTPS whenever possible to reduce the risk of compromising your web site.

HTTPS can also prevent eavesdroppers from obtaining your authenticated session key, which is a cookie sent from your browser with each request to the site, and using it to impersonate you. For example, an attacker may gain administrative access to the site if you are a site administrator accessing the site via HTTP rather than HTTPS. This is known as session hijacking and can be accomplished with tools such as Firesheep.

Security is a balance. Serving HTTPS traffic costs more in resources than HTTP requests (both for the server and web browser) and because of this you may wish to use mixed HTTP/HTTPS where the site owner can decide which pages or users should use HTTPS.

How to enable HTTPS support in Drupal

Web server configuration

  1. Get a certificate. Many hosting providers set these up for you - either automatically or for a fee. You can also use Let’s Encrypt which is free, automated, and open Certificate Authority. If you want to secure a test site, you could instead generate a self-signed certificate.
  2. Configure your web server. A few helpful links:

    Chances are, your webhost can do this for you if you are using shared or managed hosting.

Note: Clean URLs If you're using Apache for HTTP and HTTPS:

You will probably have two different VirtualHost buckets.

  1. A bucket for port :80 http
  2. A bucket for port :443 https

Each of these VirtualHost containers or buckets require that a specific Apache directive be added within them if you're using Clean URLs. This is because Drupal makes extensive use of .htaccess and mod_rewrite to provide friendly URLs.

Ensure you have the following within the directive, which is a child under the VirtualHost container: See Apache Documentation for AllowOverride

 <Directory "/path/to/yoursite">
AllowOverride All

This means that your .htaccess takes precedence and that the Apache configuration will allow it to run as you would expect for Drupal.

If you enabled HTTPS and it only works on the homepage and your sub links are broken, it's because the VirtualHost:443 bucket needs AllowOverride All enabled so URLs can be rewritten while in HTTPS mode.

Drupal configuration

  • On Drupal 7, if you want to support mixed-mode HTTPS and HTTP sessions, open up sites/default/settings.php and add $conf['https'] = TRUE;. This enables you use the same session over both HTTP and HTTPS -- but with two cookies where the HTTPS cookie is sent over HTTPS only. You will need to use contributed modules like securepages to do anything useful with this mode, like submitting forms over HTTPS. While your HTTP cookie is still vulnerable to all usual attacks. A hijacked insecure session cookie can only be used to gain authenticated access to the HTTP site, and it will not be valid on the HTTPS site. Whether this is a problem or not depends on the needs of your site and the various module configurations. For example, if all forms are set to go through HTTPS and your visitors can see the same information as logged in users, this is not a problem.

    Note that in Drupal 8, mixed-mode support has been removed #2342593: Remove mixed SSL support from core.

  • For even better security, send all authenticated traffic through HTTPS and use HTTP for anonymous sessions. On Drupal 8, install Secure Login module which resolves mixed-content warnings. On Drupal 7, leave $conf['https'] at the default value (FALSE) and install Secure Login. Drupal 7 and 8 automatically enable the session.cookie_secure PHP configuration on HTTPS sites, which causes SSL-only secure session cookies to be issued to the browser. On Drupal 6, see contributed modules 443 Session and Secure Login.

  • For best possible security, set up your site to only use HTTPS, and respond to all HTTP requests with a redirect to your HTTPS site. Drupal 7's $conf['https'] can be left at its default value (FALSE) on pure-HTTPS sites. Even then, HTTPS is vulnerable to man-in-the-middle attacks if the connection starts out as a HTTP connection before being redirected to HTTPS. Use the HSTS module or Security Kit module, or set the Strict-Transport-Security header in your webserver, and add your domain to the browser HSTS preload list, to help prevent users from accessing the site without HTTPS.

    You may want to redirect all traffic from and to You can do that by adding the code below to your .htaccess file (after the RewriteEngine on line):

    RewriteCond %{HTTPS} off [OR]
    RewriteCond %{HTTP_HOST} ^www\.example\.com*
    RewriteRule ^(.*)$$1 [L,R=301]

    There are existing comments in .htaccess that explain how to redirect to (and vice versa), but this code here redirects both of those to

    NB! Note that if you have access to the global Apache configuration, i.e., the VirtualHost definitions, you should use Redirect instead as explained in the Apache documentation.

Looking for support? Visit the forums, or join #drupal-support in IRC.


sstedman’s picture

Acquia Cloud users, please note the use of {HTTP:X-Forwarded-Proto} in your .htaccess to achieve redirects. Took me an age to find this info, so reposting from acquia to here:

# Redirect to HTTPS
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
bjdeliduka’s picture

As the subject says.... the Joys.

A client of mine has numerous customers with Drupal 7 sites. We are moving all of them behind CloudFlare ( we they offer FREE SSL Certs, web caching, and ddos protection/mitigation. We then firewall the servers to only accept connections from the CF Caches and make sure that the actual HTTP Server is not listed in DNS (client/browsers should connect to the CF Servers which will then fetch pages from the actual server). The Drupal Server (apache 2.4 on centos) also use SSL to encrypt the connection between CF and the server (might as well keep everything out of plain text )

While the above looks and feels like a great solution to insuring all connections are encrypted we encountered a problem with some pages that have IFRAMES that load encrypted content. (web browsers throw an error when this occurs and often refuse to load the content without user intervention).

Options included 1) setting up a proxy and encrypting the insecure content. While technically possible it gives the user the impression the session is secure while some of the content is in plain text (though not to/from the client). 2) drop the content until it's available via a secure connection (client/customer did not like this option) 3) force pages that contain this content to be unencrypted (http) connections while the rest of the site is encrypted.

We chose option 3.

The sites had been previously configured to redirect connections to https using a rewrite rule in the .htaccess file (will probably move these into the vhost config files for performance reasons but only if we can agree on disabling the .htaccess files) As such every http connection becomes an https connection.

Normally a rewriterule could be created in the form:

RewriteCond %{REQUEST_URI} ^Streaming-Page.* [NC]
ReWriteRule ^/?(.*) http://%SERVER_NAME}$1 [R,L]
ReWriteRule ^/?(.*) https://%SERVER_NAME}$1 [R,L]

to catch connections to the page with the insecure iframe. (rewrite matching to http and non-matching to https)

try this with clean url's enabled and you never get the unencrypted page because every page request submitted to drupal does a final pass through the rewrite engine on /index.php.

I'm unsure of the exact reason but secure_pages were not considered a viable option.

The end result solution is a series of 13 rewriterule/rewritecond lines that can effectively replace the secure_pages module for forcing all but a select few (1 or more) pages to https connections.

RewriteCond %{REQUEST_URI} /index.php
RewriteRule ^ - [S=6]
RewriteCond %{REQUEST_URI} !^/Streaming-Page.* [NC]
RewriteCond %{REQUEST_URI} !^/$ [NC]
RewriteRule ^ - [S=4]
RewriteCond %{HTTPS} on
RewriteRule ^/?(.*) http://%{SERVER_NAME}/$1 [R,L]
RewriteRule ^ - [S=3]
RewriteCond %{HTTPS} on
RewriteRule ^ - [S=1]
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
RewriteCond %{HTTPS} !on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

/Streaming-Page and the root page of the site are HTTP the rest of the site is HTTPS. Additional pages can be excluded from HTTPS by adding additional likes under the /Streaming-Page line following it's format.

The only known side affect of this code is that editing unencrypted pages is more complicated as the admin_menu drops on the unencrypted pages. Version 1.1 will include a method of disabling the http side from a clients browser (resulting in the browser errors that developers will deal with as needed while editing the pages) I'll also look an more detailed instructions on putting this into .htaccess files and removing unwanted/unneeded code for things like www. stripping (or pre-pending) etc