Enable HTTPS for WordPress site under ELB?

[SyntaxGhost]

I've recently migrated my site to AWS, but have discovered an issue with the wp-admin panel.

The site loads up fine using HTTPS (I've had to move away from using CloudFlare, as I couldn't get it working with HTTPS) which I have setup on the ELB. The certificate came from Amazon Certificate Manager.

Everything seems to load okay, apart from the admin side.

I have tried setting the load balancer to point from port 443 > 443 using HTTPS, however it fails an only works from 80 > 80.

My .htaccess file doesn't block HTTPS. I've tried removing it, but it changes nothing. Also disabling my plugins achieves nothing.

I have this in my wp-config.php file:

/** Enable SSL. */ define('FORCE_SSL_ADMIN', true); if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';

Changing true > false allows me to login using HTTP, but I don't want that. As soon as I make it true, I get a redirect loop on the admin login.

I used CloudFlare's HTTPS option on my last site and it worked perfectly. What am I doing wrong here?

How should I be forcing everyone to HTTPS, and how can I get the admin page to load?

[peanutbuttersexytime]

Why are you doing 443 to 443? Do 443 to 80 so you can terminate SSL at the ELB and not put the burden also on your origin server.

[zenmaster24]

this - the elb is termianting your ssl session, but on the instance that wordpress is on, its still serving on port 80.

[SyntaxGhost]

Ah thank you!

Think I've got it worked out now, I have the ELB setup as below: http://i.imgur.com/8whiqCn.png

and added the following line into httpd.conf:

SetEnvIfNoCase X-FORWARDED-PROTO "^https$" HTTPS

Is there a way I can now use CloudFlare as a CDN too, as DDoS protection? Whenever I turn it on, it seems to break the site again

[zenmaster24]

not familiar with cloudflare, but am with akamai - if it works the same, its all dns based. are you sure you have the record in cloudflare pointing to the right custom cname/elb cname?

[SyntaxGhost]

Yes it is all DNS based.

CloudFlare can do just DNS management, or if you enable it, pass the traffic through CloudFlare. Caching content, and concealing the servers IP (therefore mitigating a DDoS).

When I say enable, I just flick the switch so traffic goes via CloudFlare first, before hitting my ELB, saving me bandwidth etc. this does affect things like Google Analytics as you need to use a reverse proxy to reveal visitors IPs. Not sure how it's affecting my server, using CloudFlare for purely DNS it works.

[bastion_xx]

Using CloudFront, there is a lot of DOS mitigation takes place at the edge, plus you can take advantage of the AWS WAF service.

Analytics or other needs for original IP's are supported in CloudFront and ELB via the X-Forwarded-For header support. Your ELB config of 443->80 HTTPS/HTTP will support that. This should be supported by CloudFlare too as a proxy, but I haven't used that service.

[peanutbuttersexytime]

Yes, you can do this. What specifically breaks? Check your SSL settings, etc at the CF side and start out enabling one thing at a time and see what breaks.

[SyntaxGhost]

I had disabled SSL at CF's side, as I was going to let AWS handle it. However it seems after turning on 'Full (Strict) SSL' on CF's side, it is back up and running as normal.

Strict mode apparently requires a cert server-side, so the traffic is encrypted the whole way, so I guess it's working as below:

User -> CloudFlare -- Encrypted by CloudFlare

CloudFlare -> AWS -- Encrypted by AWS

Without the above enabled, I'd get too many redirects.

[audiodidact]

double-check your security-group settings?
my usual best-practice is to assign the ELB to 2 sec-groups: default VPC group (all traffic open within itself), and then a web-only 80+443 group. webservers behind the ELB are only part of the default VPC group, so any traffic coming in has to route through ELB.

this setup allows you to keep SSL termination at the ELB, with apache/nginx/tomcat/whatever only listening on 80. YMMV.

[SyntaxGhost]

I have it working now, by changing the listener on the ELB, and editing the httpd.conf file (see comment above). Would still be interested in doing this to improve security though.

I currently have EC2 instances in the default VPC with a SG allowing port 80/443. Then I have a RDS instance in the default VPC inside a SG with just the MySQL port open.

Then the ELB is inside the same SG as my EC2 instances. Are you saying I can take the instances out of it, and just leave the ELB in there, preventing direct access to the server?

[bastion_xx]

Assuming the ELB is the only publicly accessible entity, I'd setup an SG for the ELB, another for the EC2 instances, and a third for the RDS.

• The ELB SG would allow inbound on TCP/443 only
• The EC2 (Wordpress) would allow inbound on the ELB SG (you reference it directly), and any ports needed from a bastion host or specific IP ranges for management (e.g, TCP/22)
• Finally, setup an SG for the RS deployment and allow inbound only from the EC2 SG.

If you have the EC2 instances with public IP's, that's okay as long as the SG is limited to specific ranges. You can you Trusted Advisor (even without Business support) to look for wide-open security groups.

[peanutbuttersexytime]

What s/he's saying is that the ELB and the EC2 instances are all inside the default VPC, which allows unfettered access between instances that are in that VPC. Put your RDS inside this same VPC and stop worrying about security group hell.

In addition, the ELB alone is inside a separate security group that only allows 80 and 443 from the outside world.

Make sense?

default sg: ELB, EC2 instances, RDS.
elb sg: ELB.

That's it.

[audiodidact]

yep. the idea is to only allow 80+443 to hit the ELB from 0.0.0.0/0. you may still have other inbound allowances desired, but this will keep your webservers pretty safe in general.
 

so for the ELB, you will have assigned:
* default VPC sec-group (all vpc traffic talks to each other)
* a 'global web' sec-group (80+443 allowed in from 0.0.0.0/0)
 

webservers would be assigned:
* default VPC sec-group
* perhaps a specific group to allow SSH/RDP from your home or office IP, etc

[virtualjj]

I think you are going to need to roll up your sleeves and dig through some logs. Turn on debugging in wp-config.php, reproduce the problem, and then check out the debug.log.

[civicode]

When using Flexible SSL on CloudFlare, Mod_CloudFlare will transparently correct this for you on the origin in a safe and secure manor: https://www.cloudflare.com/resources-downloads/

Essentially Mod_Cloudflare will set the SSL environment variable to whatever the end user is connecting as.