I just installed an SSL Certificate on my server.

It then set up a redirect for all traffic on my domain on Port 80 to redirect it to Port 443.

In other words, all my http://example.com traffic is now redirected to the appropriate https://example.com version of the page.

The redirect is done in my Apache Virtual Hosts file with something like this...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

My question is, are there any drawbacks to using SSL?

Since this is not a 301 Redirect, will I lose link juice/ranking in search engines by switching to https?

I appreciate the help. I have always wanted to set up SSL on a server, just for the practice of doing it, and I finally decided to do it tonight. It seems to be working well so far, but I am not sure if it's a good idea to use this on every page. My site is not eCommerce and doesn't handle sensitive data; it's mainly for looks and the thrill of installing it for learning.


Strangely Bing creates this screenshot from my site now that it is using HTTPS everywhere...

enter image description here

  • 14
    [WTF - I can't add answer (though seems I have enough rep).] My answer would (in part) be that SOMETIMES IT IS BAD. Consider passing a COOKIE or API Key in a GET over HTTP. If your site redirects HTTP requests to HTTPS requests, these calls would work, but the COOKIE or API Key would be transmitted in the clear - exposed. Some APIs turn HTTP off, a more robust approach - no HTTP at all so you can't even get it working unless you use HTTPS. Example: "All API requests must be made over HTTPS. Calls made over plain HTTP will fail" from stripe.com/docs/api?lang=php#authentication Commented Jan 28, 2014 at 20:06
  • 9
    @codingoutloud - the alternative is that the whole thing happens over HTTP with no HTTPS at all. How is that any better? Commented Jan 28, 2014 at 20:42
  • 3
    @BenCrowell, that's because a captive portal looks an awful lot like an sslstrip-style redirect attack (they're both man-in-the-middle request hijacks) so HSTS-aware browsers will block them both. Commented Jan 29, 2014 at 3:17
  • 3
    be aware that using https means everything you include should also be https or it might not load - eg load jquery using src="://example.com/jquery.js" - note the lack of http or https so the browser loads the appropriate one. I had a nightmare trying to get some embedded Amazon stuff to load properly as the API (loaded via https) produced http links - meaning they didn't work properly until I found the undocumented parameter to toggle https links
    – Basic
    Commented Jan 29, 2014 at 18:44
  • 3
    Jason; your update should be a new question, probably on Webmasters as it's unrelated (technically) to your original question. But it's probably that your style sheets are coming from an insecure domain. Commented Jan 29, 2014 at 20:09

11 Answers 11


The [R] flag on its own is a 302 redirection (Moved Temporarily). If you really want people using the HTTPS version of your site (hint: you do), then you should be using [R=301] for a permanent redirect:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A 301 keeps all your google-fu and hard-earned pageranks intact. Make sure mod_rewrite is enabled:

a2enmod rewrite

To answer your exact question:

Is it bad to redirect http to https?

Hell no. It's very good.

  • 3
    Thanks for the information, my boss is telling me the reason he only runs https on certain pages of his site, is that it uses a lot more server resources to run it on every page. Do you know anything about that or if that's true?
    – JasonDavis
    Commented Jan 28, 2014 at 2:00
  • 9
    @jasondavis Only if you don't spend a few minutes to optimize it. Commented Jan 28, 2014 at 2:03
  • 10
    "it uses a lot more server resources to run it on every page." Modern CPUs have encryption acceleration features that make SSL nearly free. Don't worry about overhead.
    – Adam Davis
    Commented Jan 28, 2014 at 4:24
  • 42
    @AdamDavis The crypto algorithm may be lightweight, but the handshake overhead still exists. Also, HTTPS prevents HTTP proxies from caching your content. In most cases, the overhead of HTTPS is minimal and worthwhile, but be careful about over-generalizing. Commented Jan 28, 2014 at 7:22
  • 6
    It kills shared caching, which is useful for some site's usage patterns, and often protects little (is it important that people can know you visited the site, but not the details of what you did? That's the only situation where SSL is useful). The main advantage of SSL on every resource isn't that you need to "secure" e.g. people looking at "about us", but that you can't slip up and fail to use it in a case where you should.
    – Jon Hanna
    Commented Jan 28, 2014 at 11:02

Whilst I support the idea of SSL only sites, I would say one drawback is overheads depending on your site design. I mean for example if you are serving lots of individual images in img tags, this could cause your site to run a lot slower. I would advise anyone using SSL only servers to make sure they work on the following.

  1. Check the entire site for internal links and ensure they are all using HTTPS if you specific your own domain name in links, so you are not causing your own redirects.
  2. Update your <meta property="og:url" to using the https version of your domain.
  3. If you use <base href= again update to use HTTPS.
  4. Install SPDY protocol if possible
  5. Make sure to use CSS Image sprites where possible, to reduce numbers of request.
  6. Update your sitemaps to indicate https status, so spiders over time learn this change.
  7. Change Search Engine preferences like Google Webmaster Tools to prefer HTTPS
  8. Where possible off-load any stactic media to HTTPS CDN servers.

If the above is addressed, then I doubt you will have many issues.

  • SPDY is a good suggestion; there even appears to be a module adding SPDY support to Apache 2.x.
    – Calrion
    Commented Jan 28, 2014 at 2:25
  • 19
    Using "//yourserver.com/some-uri" instead of "yourserver.com/some-uri" resolves issue (1) because the browser will pick the appropriate schema (http or https) depending on the schema the page was loaded with.
    – MauganRa
    Commented Jan 28, 2014 at 8:21
  • 1
    @MauganRa Unless, of course, it's a link from http article page to https login page, for example.
    – Mołot
    Commented Jan 28, 2014 at 11:01
  • 4
    Google sees the URL someone is visiting via the Referer header. For example this site uses jQuery from Google's CDN and my browser sends a request to Google every time I reload the site. Thereby a Referer header is also send to Google which is set to the URL of this site. So Google can track the sites I visit during the time my IP address does not change (and if I use a Google service during this time, Google can also connect this information with my Google account). Commented Jan 28, 2014 at 16:31
  • 1
    For 1) I just did a search and replace in my MySQL database http to https...i'm using WordPress so it made it real easy to update hundreds of links
    – JasonDavis
    Commented Jan 29, 2014 at 18:13

I you've set up https then you should use it everywhere on the site. You will avoid the risk of mixed content issues and if you have the required tools in place, why not make the entire site secure?

Regarding redirection from http to https the answer is not that simple.

Redirecting will make it a lot easier for your users, they just type in whateversite.com and gets redirected to https.

But. What if the user is sometimes on an unsecure network (or is close to Troy Hunt and his Pineapple)? Then the user will request http://whateversite.com out of old habit. That is http. That can be compromised. The redirect could point to https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. To an ordinary user it would look quite legit. But the traffic can be intercepted.

So we have two competing requirements here: To be user friendly and be secure. Fortunately, there is a remedy called the HSTS header. With it you can enable the redirect. The browser will move over to the secure site, but thanks to the HSTS header also remember it. When the user types in whateversite.com sitting on that unsecure network, the browser will go to https right away, without jumping through the redirect over http. Unless you deal with very sensitive data, I think that's a fair tradeoff between security and usability for most sites. (When I recently set up an application handling medical records I went all https without a redirect). Unfortunately Internet Explorer has no support for HSTS (source), so if your target audience is mostly using IE and the data is sensitive you might want to disable redirects.

So if you're not targetting IE users, go ahead and use redirect, but enable the HSTS header as well.

  • More people need to pay attention to this as well. Another thing is that people assume they are secure because the end point is HTTPS, ignoring the fact that all the information sent to the page in GETs or POSTs is in plain text.
    – Velox
    Commented Jan 28, 2014 at 12:07
  • 3
    @Velox - I don't think the implication of "people assume they are secure because the end point is HTTPS, ignoring the fact that all the information sent to the page in GETs or POSTs is in plain text" is quite accurate. While there are some gotchas, GET query params don't travel in the clear during transport over HTTPS. See for example: stackoverflow.com/questions/323200/… POST payloads are also protected, while also not vulnerable to logging and referrer headers. Commented Jan 28, 2014 at 19:53
  • @codingoutloud That's my point. Over HTTPS they are encrypted, but in the initial request to the HTTP page they were not.
    – Velox
    Commented Jan 28, 2014 at 20:24
  • 1
    @Velox - If the whole site is redirecting to HTTPS, then it's unlikely that any GET parameters will get sent before HTTPS has kicked in (and everything will stay HTTPS after that point). There's still the one initial request where cookies will be sent, which can be remedied with HSTS... and a small attack window for SSLStrip, which could possibly be defeated by JavaScript, but that's an arms race of its own.
    – Brilliand
    Commented Jan 29, 2014 at 2:21
  • @Brilliand Fair point, but a weak point in security makes the entire thing weak. Always worth considering.
    – Velox
    Commented Jan 29, 2014 at 8:32

There's nothing wrong with this, and in fact it's best practice (for sites that should be served over a secure connection). In fact, what you're doing is pretty similar to the configuration I'm using:

  ServerAdmin [email protected]
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1

# Insert virtual host here :)

The 301 status code indicates a permanent redirect, instructing capable clients to use the secure URL for future connections (e.g. update the bookmark).

If you'll only be serving the site over TLS/SSL, I'd recommend a further directive to enable HTTP Strict Transport Security (HSTS) in your secure virtual host:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"

This header instructs capable clients (most of them these days, I believe) that they should only use HTTPS with the provided domain (secure.example.com, in this case) for the next 1234 seconds. The ; includeSubdomains portion is optional and indicates that the directive applies not just to the current domain, but any under it (e.g. alpha.secure.example.com). Note that the HSTS header is only accepted by browsers when served over an SSL/TLS connection!

To test your server configuration against current best practice, a good free resource is Qualys' SSL Server Test service; I'd be aiming to score at least an A- (you can't get more than that with Apache 2.2 due to the lack of support for elliptic curve cryptography).

  • I should add, sending the header Strict-Transport-Security: max-age=0 will negate any previous directive; as always, this must be sent over HTTPS to be accepted, but it's a handy way of cancelling things if you decide you also need to use HTTP on the domain.
    – Calrion
    Commented Jan 28, 2014 at 6:20

Wow ! redirect HTTP to HTTPS is a very good thing and i cannot see any drawbacks for that.

Just make sure your clients have the right CA to avoid non user-friendly warnings about certificate in browser.

In addition, the way you have setup Apache to redirect to HTTPS seems ok.


Is it bad to redirect http to https?

No, not at all. Actually, it is a good thing to do!

On redirects:

It could be more efficient, by completely eliminating the rewrites. Here's my config on a similar situation...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/

HTTPS is not exactly foolproof. Of course, normally forcing HTTPS is a good thing. It prevents normal criminals from doing anything bad to your users.

But please remember to check you SSL Settings like the SSLCiphers setting. Disable things like RC4 crypto, the SSLv2 and SSLv3 protocol. Also, you should find out, whether the crypto-system libarys of your system support TLS1.2 (which is the thing you want to have ;) )

Turn on SSL, its a good thing.

  • Entropy doesn't get used up (at least if you're defending against Earth-based attackers rather than doing voodoo). Either you start with insufficient entropy, and you can't do anything that requires randomness, or you start with sufficient entropy, and you keep having sufficient entropy no matter how much randomness you generate. Commented Jan 28, 2014 at 11:23
  • Sorry, what? There are a number of operations on Linux that insist on hardware-derived strong entropy rather than PRNG-based probably-good-enough entropy, and those can indeed block if the pool depth is low. It is most certainly possible to start with sufficient entropy on a Linux system, but by overuse to drain the pool, causing some operations to block.
    – MadHatter
    Commented Apr 19, 2014 at 10:48

Personally I am all for the use of SSL to secure connections on the web, however I feel a point that all the other answers here have missed is that not every device and piece of software capable of an HTTP connection will be able to use SSL, thus I would consider providing some way for users to avoid it if it is not supported for them. It is also possible that people in some Countries where encryption tech is illegal will then not be allowed to access your site. I would consider adding an unencrypted landing page with a link to force the insecure version of the site but unless a user specifically selects such to do as you said and just forward them to the HTTPS version.

  • A problem with solutions like having a plain HTTP landing page, even if properly separated, is that this page is left open to manipulation. Ie, there's no actual guarantee that the link for the HTTPS version of the site is delivered intact to visitors. Commented Feb 24, 2016 at 7:27

Here are some of the broad brushstroke issues:

  • MITM/SSLSTRIP: This is a huge caveat. If you're going to serve your site over HTTPS, then disable HTTP on the site. Otherwise, you leave your users open to various man-in-the-middle attacks including SSLSTRIP, which will intercept requests and quietly serve them over HTTP, inserting their own malware script into the stream. If the user doesn't notice, then they'll think their session is secure when it actually isn't.

    • The issue with this, though, is that if your site is a public site and you just unceremoniously disable HTTP, you might lose a lot of visitors. It probably won't even occur to them to try HTTPS if the site won't load with HTTP.
  • If your site requires a secure login, then the entire user session should be secured. Don't authenticate over HTTPS, then redirect the user back to HTTP. If you do, again, you're leaving your users vulnerable to MITM attacks. The standard approach to authentication these days is to authenticate once, then pass an authentication token back and forth (in a cookie). But if you authenticate over HTTPS then redirect to HTTP then a man-in-the-middle can intercept that cookie and use the site as if they are your authenticated user, bypassing your security.

  • The "performance" issues with HTTPS are for all practical purposes limited to the handshake involved in creating a new connection. Do what you can to minimize the need for multiple HTTPS connections from a URL and you'll be miles ahead. And that's frankly true even if you're serving your content over HTTP. If you read up on SPDY, you'll realize that everything it does is oriented toward trying to serve all the content from a single URL over a single connection. Yes, using HTTPS affects caching. But how many web sites are just static, cacheable content these days, anyway? You're likely to get more bang for your buck using caching on your web server to minimize redundant database queries retrieving unchanged data over and over again, and preventing expensive code paths from executing more often than necessary.

  • The thing you can do to actually address sslstrip is to use HSTS (preferrably get your HSTS settings preloaded). Whether you accept requests over plain HTTP or not doesn't actually matter in this regard, a MITM can answer over plain HTTP (possibly proxying to your HTTPS site) even if you only accept HTTPS requests. Commented Feb 24, 2016 at 7:10
  • @HåkanLindqvist I really earned a downvote from you? Did I give bad advice or good advice with regard to not authenticating over HTTPS then switching to HTTP for the rest of the session? Did I provide bad counsel with regard to HTTPS performance myths? Also, if the client initially attempts to connect using HTTPS, the MITM cannot intercept and respond without triggering an alert in the browser, because their cert won't match unless they have a stolen or successfully forged cert. On the other hand, if the site accepts an HTTP connection, interception is easier. Either way, HTTPS raises the bar. Commented Feb 25, 2016 at 1:40
  • ..and of course I agree wholeheartedly with using HSTS. Commented Feb 25, 2016 at 1:40
  • My problem with the answer is the first item in the list claiming to address sslstrip while it actually doesn't (speaking of myths). What I was trying to get at in my initial comment is that if you have an active MITM (which is what you need for sslstrip in the first place), the attacker can essentially be "the site" from the perspective of the client; it's the attacker that decides if they want to accept plain HTTP connections from the client, how your actual web server behaves in that regard doesn't affect what the attacker can or will do. Commented Feb 25, 2016 at 7:44
  • @HåkanLindqvist Except that if the visitor is intentionally trying to connect with HTTPS, the attacker can't satisfy that request without throwing flags in the browser, unless they have managed to steal a server certificate or somehow successfully forge one, which they would have to do in order to switch the connection to HTTP. HTTPS still raises the bar. Of course if the visitor makes the initial connection attempt over HTTP, all bets are completely off. Commented Feb 25, 2016 at 15:41

It is very good to redirect to HTTPS, but I read it also depends on how you organize the redirecting.

Making a dedicated virtual host for redirecting the incoming HTTP requests to your HTTPS connection as suggested in this answer on security.stackexchange.com - sounds very smart and will close some additional security threats. A configuration in Apache would look something like this:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...


the only technical draw back to HTTPS over HTTP is that it is computationally more expensive to process HTTPS requests than plain HTTP

However given that most modern servers have high powered CPU's this impact is usually negligible unless you are at extremely high levels of traffic at which point you are more than likely using load balancers anyway

With the advent of protocols like SPDY which require SSL/TLS to work, this actually counteracts the aforementioned computational overhead by giving significant performance improvements with regards to multiple requests and getting assets to the client faster overall.

  • The issue with HTTPS performance is that establishing a new connection is more expensive because there are more round-trips involved and because asymmetrical encryption/decryption is a lot more expensive than symmetrical encryption/decryption. Once the connection handshake establishes a shared symmetrical encryption key, the ongoing overhead is virtually irrelevant (very small). If you read up on SPDY, you'll see that the goal of all the fancy stuff it does is essentially to serve all the content from a URL over a single connection, mitigating the connection handshake overhead. Commented Apr 19, 2014 at 10:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .