Make Drupal More Secure With SSL Logins

One of the things that has always bothered me about Drupal is the way that it sends it’s logins in clear text. It really bothers me when I’m on vacation, and I’m logging into the site from dirty WiFi hotspots and even dirtier hotel room internet connections. I don’t usually log in as user#1, but there isn’t really a good way to log in as a non-admin account when you need to admin the site! And of course there is the issue of moderators and power-users logging into their accounts from Lord-knows-where, leaving them prone to “Starbucks Sniffing”. So now that vacation time is rolling around I made it a goal of mine to setup secure logins at the site.. How hard could it be, right?  Shouldn’t take more than 30 minutes.

The basic steps are pretty easy: Configure your server with an SSL Cert and re-write all the pages that you want encrypted from HTTP to HTTPS. Again, how hard could that be?!

When I first started on this mission, I figured I could save a few dollars and generate my own self-signed SSL Cert. Since I only wanted the cert for enabling encrypted pages, I didnt really care about proving the identity of the site. But as I was testing, I quickly realized that if I used a self-signed SSL Cert some browsers would generate warnings and even pop-up messages about not being able to confirm the identity of the website. Because I didn’t want to scare away any of my visitors I decided I should invest a few bucks into a “real” SSL Cert and purchased one online.

Once you have your SSL cert you have to configure it on your server. If you use cPanel/WHM this isnt too difficult, but you will need to have a dedicated IP for the site/domain. Even though I have a dedicated server with several IP’s, the server was sharing a few sites all on the same IP. Because I’m not really too keen on breaking things I let my hosting company change the IP and configure the new SSL cert for me (Tip: always take the easy way out when possible). If you are on a shared/virtual host the whole shared IP thing may be an issue so you might have to purchase a dedicated IP address for your domain. There also seems to be issues with using “shared” SSL certificates in Drupal so you may want to avoid that and invest in your own cert. Check with your hosting company first to see if they support dedicated IP address and individual certificates before you spend any money.

Once your SSL certificate is setup on your server you should be able to view any page as either HTTP or HTTPS without any errors or warnings (or very few warnings – I’ll get to that below). Assuming you’ve made it this far you can use the Drupal SecurePages module to handle the switching (re-writing) between secure (HTTPS) and non-secure (HTTP) pages. I suppose you could just encrypt all your pages and display them all as HTTPS but that is a bit of overkill and you’ll pay a large performance penalty, especially if you get a lot of pageviews. In my infinite wisdom I decided that only the login page, change password page, new account page and all member info pages needed to be encrypted. Some Drupal experts also think that encrypting all admin pages (ADMIN/*) is also necessary, but I’m just not seeing the need. One warning: be sure that you can access your pages via HTTP and HTTPS before trying to use the SecurePages module! Failure to heed this warning, which is also in big, bold letters on the SecurePages project page WILL result in borking your site.. and we all know that a borked site is no fun, especially on a Tuesday.

Installing SecurePages is easy: just copy it to your sites/all/modules directory and enable it in the modules page – but since there is NO documentation, configuring the module can be tricky, especially if you don’t really understand WTF is going on (like me). The basic settings are to enter your non-secure base URL ( and your secure base URL (httpS:// You probably will also want to put a checkbox in the “Switch back to http pages when there are no matches” option so that pages that you don’t specify that you want encrypted are automatically switched from HTTPS back to HTTP.  Finally, click the “Make secure only the listed pages” radio button, and enter the pages that you want to be encrypted. For me this was “user/*” (without the quotations) which will include the login page, forgot password page and ‘create new account’ page (all start with “user”) as well as all the member’s profile pages. Press SAVE and you’re ready to start testing.

The first thing I noticed while checking that everything was working properly is that once I hit an encrypted HTTPS page, every page I visited after that stayed encrypted – they weren’t switching back to standard HTTP. After a few hours of hair-pulling I found a post at that mentioned leaving an extra blank-line in the “pages” list will result in switching between HTTPS and HTTP not working properly – so be sure you backspace-out any extra/blank lines!

The next problem that I ran into is that none of my encrypted pages were “fully” encrypted. In Firefox this resulted in the security padlock with the line through it and a message that read “parts of the page you are viewing were not encrypted before being transmitted over the internet“, and on Internet Explorer a message would pop up about “not all items on this page are secure” (or something like that) – knowing that the majority of my visitors use Internet Explorer, and knowing that this may scare them away, this was a big problem.

Using the “net” tab in Firebug I was able to quickly (ok, it took me half a day to figure out that I even needed to use Firebug and what to look for) pinpoint the problem on the login pages. It seems that the Kontera scripts that I use are not encrypted. So even though my Drupal data was encrypted, the Kontera portions of the page were not, resulting in the warnings. A few more hours of tinkering with the Kontera module and I was able to exclude Kontera from the login pages – now, when someone accesses the login, password reset or create new account pages, they get the full, “Secured page” padlock – yayyy! (only took me a fucking day).

Next, I was finding the same “parts of the page you are viewing were not encrypted before being transmitted over the internet” messages when viewing or editing member’s profile pages. After more tinkering with Firebug, I found that the avatar images on the pages were failing to load as HTTPS. To get around this all i needed to do was add the avatar image paths to the “pages” list to force them to load as HTTPS. I use the Avatar Selection module so the images come from a few different locations, but adding these entries did the trick:

NOW, when viewing a member’s profile page it was also coming up as fully encrypted, little padlock and all.

But now I ran into another issue. By adding the image locations to the “pages” list, now the avatars were being encrypted, no matter where they were located – for example, in every forum post. This was causing slow page-load times and simply would not do. To overcome this, all I had to do was add the same image locations (above) into the “ignore pages:” list. That would make them display as either HTTPS or HTTP, depending on the parent page. w00t!

Finally, the last little issue was that SecurePages will not encrypt logins via the login or Logintoboggan blocks unless you encrypt every page (which we already decided is a bad thing). So to get around that I created custom “Login” blocks, that direct logins to the /login page which is configured for HTTPS.

So my 30 minute job to enable secure SSL logins ended up taking about 26 hours, but it was fun.. sorta.. Hopefully you can learn from my mistakes and only waste half the time I did. Worst part is, I doubt that most members will even notice or appreciate the lengths I’ve gone to or the hair I’ve pulled out to protect their passwords.  But.. I suppose I will sleep better when I’m on vacation.

Closing Thought: Encrypting your login pages is not going to make your site or your member’s accounts hack-proof – but much in the same way that one of those steering-wheel lock-bars on your car wont prevent it from being stolen, it will make it just a bit more difficult, and in this case, 256 bits more.

18 thoughts on “Make Drupal More Secure With SSL Logins

  1. Hi, I tried to follow this post and got till the end, but would love to have more clarification on how to create custom login block which redirects to “/xyz” page and then configure this “/xyz” into the secure pages modules.

    I would appreciate any help regarding this.

  2. Randy,

    You can use SSL for your entire site without getting a significant performace hit. According to Steve Gibson,, “The belief that switching to using pure SSL/TLS is any burden was obsoleted years ago with the addition of SSL/TLS Session Resume. Session Resume allows a particular client and server to perform the high-overhead public key negotiation just once (which they always need to do during the secure SSL/TLS logon anyway) and to then reuse those negotiated credentials for all future SSL/TLS connections being made. Since the credential reuse duration is typically 24 hours, very little additional burden is placed upon either the client or the server as a consequence of using SSL/TLS pervasively across a web site … always and for everything.”

    Thanks for the post.

  3. Hi Randy,

    Thanks for posting your experience getting this stuff to work…

    I am in the same process, but I am exploring using the 443 session module that will switch the site to https if the user is logged-in. Have you looked into this module? What do you think?


  4. You just saved my last few hairs from being pulled out! As soon as I read about the extra line in the “Pages” field I went to mine and sure enough, one extra line. Once deleted, the switching from HTTP to HTTPS and back worked again. Thanks!

  5. Hey Randy,

    I stumbled upon some security vunerabilities related to something you mentioned in your article that i thought i’d bring to your attention.

    “In my infinite wisdom I decided that only the login page, change password page, new account page and all member info pages needed to be encrypted. Some Drupal experts also think that encrypting all admin pages (ADMIN/*) is also necessary, but I’m just not seeing the need.”

    SSL logins aren’t enough anymore. There have always been vunerabilties, but now even non-tech savvy users can click-jack your sessions. They might not know your password, but they can still get access. Check these linsk out for more info:

  6. @Dave – yah, these are new developments since i made this post back in 2009. Now anytime I am accessing my site from any non-trusted network I do it all via HTTPS..but, i do all i can to avoid access from anything untrusted..

  7. Hi Hey Randy,

    Very nice tutorial. I have a question before I go ahead and install SecurePages module, do I need to make changes to htaccess file which is available by default in root?

    I have installed ssl certificate and can access my site both with http and https. All I want is to redirect AND to Do I need to make changes in htaccess file? And what will SecurePages module will do for me?

    Please help,

  8. I too thought this would be a walk in the park. This really needs to be posted on the Secure Pages/Secure Login project pages. Thanks for taking the time to write it up!

  9. I started out by making my site 100% ssl. To make sure I redirect all http traffic to https in by Apache config.

    However most new caching schemes that take over your DNS hosting and Google’s Apache mod_pagespeed do not work with https objects. Drupal is fairly good about performance but AFAIK it does not compress JPGs (yes you can save a fair bit of speed doing this using pagespeed) and other images. Also if you have lengthy queries through no fault of your own, the caching of pagespeed brings noticeable goodness. I know there are other ways to cache DBs but how simple is pagespeed?

    Anyway, I have a test site running with all pages and objects available with http and https and am now going back following your posts to resecure the important bits (I use ubercart too so really need these secured).
    Your two posts cover most of what I need to do but I’m worried about the secure session stuff. I have seen nothing posted about this but maybe my Google-fu is failing me.

    The admin session is the scary one. If I go to the https version of the site I should be OK (because I’ll never forget the https://, right 😉 but I have privileged users too that are like mini-admins. If someone steals their session they can only mess up that user’s content still it smells like a security vulnerability.

    Anything new on secure sessions?

  10. Dear Rand B. Wilson,

    Thanks for this post. This is nice one. I am also facing same problem with SSL. I have my SSL cert. So i install SecurePages module in my site, the result is that my complete site is now encrypted. So i uninstall it because i need some pages encrypted. But now what i see that after uninstall SecurePage still my pages are encrypted and my url is I can’t understand how to change my URL in After that i have to encrypt only login pages in it. Can you please tell me whats a problem in it.

    thanks in advance.

  11. Drupal 7 – https with shared ssl
    Here is the D7 setup that works for me on A2 shared hosting, with a shared certificate.

    1. /sites/default/settings.php – for the $base_url and $cookie_domain
    2. /.htaccess – https and remove www, because shared url can’t have www
    3. pathologic module – do // protocol for the image paths
    4. securepages module – via shared https url, so you can turn it on

    // (/sites/default/settings.php)
    $request_is_ssl = (getenv('HTTPS') == '1' || getenv('HTTPS') == 'on' || !empty($_SERVER['HTTP_X_FORWARDED_HOST'])) ? TRUE : FALSE;
    if ($request_is_ssl) {
    $base_url = '';
    $cookie_domain = '';
    $_SERVER['HTTPS'] = 'on';
    $conf = array('reverse_proxy' => TRUE, 'reverse_proxy_addresses' => array($_SERVER['REMOTE_ADDR']));
    //$_SERVER['REQUEST_URI'] = '' . $_SERVER['REQUEST_URI']; // Only the DNS name of the site needed here!
    } else {
    $base_url = ''; // NO trailing slash!
    $cookie_domain = '';
    $_SERVER['HTTPS'] = '';

    # (/.htaccess)
    RewriteRule ^ - [E=protossl]
    RewriteCond %{HTTPS} on
    RewriteRule ^ - [E=protossl:s]
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

    /* pathologic module: (/admin/config/content/formats) > each text format > Correct URLs with Pathologic > Protocol relative URL (Save configuration) */

    /* securepages module: ( > Enabled, Switch back to http pages when there are no matches,,, Make secure only the listed pages (Save configuration) */

  12. I have a query, how can we achieve this functionality without using ssl/https, because drupal sends login details as plain text from the client side, so how can I solve this issue?

    I have used encrypt_submissions module using jcryption library but now jcryption is not maintained by its owner, How can send encrypted login details without ssl in drupal?

    please help me

Leave a Reply

Your email address will not be published.