Amazon AWS and SSL certificates

[Oko]

We are moving one of our production environments to Amazon AWS for legal reasons. I got couple of hours to play with AWS. I set up nginx, postgresql, django and our application works like a champ. EasyDNS was playing well with AWS and our customers on the another continent can see the things.

Final thing is setting SSL certificate. Amazon is giving me two IP addresses. One is public
which I can see with dig and the second one is private. It looks like Amazon is doing some kind NAT-ing from my public to private IP. I need to upload SSL certificate on the instance with public IP. It seems to me that that can't be done without purchasing Elastic Load Balancer.

Anybody has experience with enabling HTTPS on AWS? I need things running pronto.

Thanks,
Oko

P.S. The only way to talk to Amazon customer service is to purchase support plan. They are hitting us with hidden costs on every corner.

[rocket357]

AWS does indeed do static NAT.

That said, as long as you have a virtual host listening for the host/domainname in the certificate, shouldn't configuration be pretty straightforward? What issue are you running into?

Also, are you using an Elastic IP? If not, be warned that your IP will change when the instance is put through a stop/start cycle (reboots take place on the same underlying hardware, but a full stop/start will migrate to new underlying hardware, so you should use an EIP for any DNS-dependent IPs).

[Oko]

Originally Posted by rocket357

AWS does indeed do static NAT.
That said, as long as you have a virtual host listening for the host/domainname in the certificate, shouldn't configuration be pretty straightforward? What issue are you running into?

Can you be little bit more specific? I have experience with virtual hosts and Nginx as a proxy server. I run Nginx on my firewall with the public address with uploaded SSL certificate. And Nginx points back to a "virtual host" one of my machines behind. My EasyDNS points A record of the HTTPS server to the firewall even though content is served by the "virtual host"

Now I don't control firewall and everything I see on the internet talks about purchasing load balancer from Amazon and uploading certificate there. To make things more complicated I am not using Amazon DNS. So basically the way things work without SSL is that point CNAME which I want to use for my web server to something like

ec2-54-69-99-199.us-west-2.compute.amazonaws.com

So do I generate SSL certificate for

ec2-54-69-99-199.us-west-2.compute.amazonaws.com

or for the name I want my web server to have

www.oko.com

Originally Posted by rocket357

Also, are you using an Elastic IP? If not, be warned that your IP will change when the instance is put through a stop/start cycle (reboots take place on the same underlying hardware, but a full stop/start will migrate to new underlying hardware, so you should use an EIP for any DNS-dependent IPs).

No we are not using Elastic IP for now and I noticed that shit. Thanks for confirming this to me. We need to migrate one of the machines out of CMU for legal reasons and I am not sure that Amazon is good idea but I was overruled.

[rocket357]

Originally Posted by Oko

Can you be little bit more specific? I have experience with virtual hosts and Nginx as a proxy server. I run Nginx on my firewall with the public address with uploaded SSL certificate. And Nginx points back to a "virtual host" one of my machines behind. My EasyDNS points A record of the HTTPS server to the firewall even though content is served by the "virtual host"

Now I don't control firewall and everything I see on the internet talks about purchasing load balancer from Amazon and uploading certificate there. To make things more complicated I am not using Amazon DNS. So basically the way things work without SSL is that point CNAME which I want to use for my web server to something like

ec2-54-69-99-199.us-west-2.compute.amazonaws.com

So do I generate SSL certificate for

ec2-54-69-99-199.us-west-2.compute.amazonaws.com

or for the name I want my web server to have

www.oko.com

Static NAT is a 1:1. A packet comes in on, say 54.166.123.245, it is translated to the private IP, say, 172.30.234.65, and forwarded to the instance with that private IP. Outgoing packets are treated exactly the same, albeit in reverse. The only protocols that operate problematically that I've seen are protocols such as certain VoIP protocols that, for whatever reason the authors of said protocols decided to embed the *private* ip as the connect-back ip into the packet payloads, which isn't altered by SNAT.

You should use the url you want the web server to have, then configure nginx to proxy from one instance to another on the private IPs. (If you do point to that ec2-* hostname, and you have to stop/start the instance for maintenance or due to underlying hardware issues, your cert will be useless as the odds of you getting that exact IP/attached DNS record back are *incredibly* slim...hence the Elastic IP suggestion. You would want www.oko.com to resolve to the Elastic IP, which stays with your account and can be moved between instances, if necessary).

The details of how the private ips work together depend heavily on whether you are running in an EC2 Classic environment or a VPC environment. If VPC (default for all new accounts...so you're using this unless this account is an older account), then you could setup a public subnet and private subnet within the VPC CIDR, then put the nginx proxy in the public subnet (and attach an Elastic IP to it...trust me, you want to do this!), and put the backend web server in the private subnet. You can configure your security groups (stateful firewall rules, basically) to control what traffic can hit your instances, and you can apply more than one security group to each instance. You might setup a management security group for ssh access from your IPs, a public web security group for your nginx proxy, and a restricted "direct access" security group for your backend web server. You would then apply both the management and appropriate web access security groups to your instances.

Also, if you plan on wiring up OpenBSD to a VGW for VPN access to your VPC (yes, talking like this gets incredibly old on a daily basis), I can point you to a few howto's I've written up expressly for that purpose. Static is easier but I've found the BGP-based configuration to be a bit more stable in the long-run.

Originally Posted by Oko

No we are not using Elastic IP for now and I noticed that shit. Thanks for confirming this to me. We need to migrate one of the machines out of CMU for legal reasons and I am not sure that Amazon is good idea but I was overruled.

Amazon is a great way to supplement existing compute capacity or run incredibly low cost web sites (that give you more control than, say, HostGator). It isn't a perfect "one-size-fits-all" solution, to be certain (though it is, in my biased opinion, quite nice for very many tasks as long as those tasks don't involve running OpenBSD instances =\ ).

[Oko]

@rocket357
You are the best!!! We have now all the info to make right technical and more importantly business decisions. We will not be running OpenBSD on AWS (even though I think getting PV Xen support to OpenBSD is one of GSoC proposed project due to the popularity of Amazon cloud hosting). I run today Red Hat 7.1 on AWS which was given for free. I didn't bother to check but I think it is free for only 30 days.

BTW people systemd sucks!!! I am keeping 6.xxx on the machines which have to run Linux.

[rocket357]

Originally Posted by Oko

I think getting PV Xen support to OpenBSD is one of GSoC proposed project

I was reading up on Bitrig's proposed Virtualization changes earlier. It would be nice if PV drivers could be written at least for ethernet, disk, and such. At that point at least we'd be able to boot up an HVM Xen instance with OpenBSD and have a hope of being able to interact with it heh.

Originally Posted by Oko

BTW people systemd sucks!!! I am keeping 6.xxx on the machines which have to run Linux.

This is a big part of the reason I'm studying to transfer to the networking side of AWS.

Originally Posted by Oko

@rocket357
You are the best!!! We have now all the info to make right technical and more importantly business decisions.

Hit me up via PM if you need any additional assistance, I'm more than happy to help =)

[bsd-keith]

Originally Posted by Oko

BTW people systemd sucks!!!

That is why a lot of Linux users are investigating the *BSD's.

[Oko]

I am working on this tonight and I need little bit hand holding. I requested and obtained elastic IP (55.4.55.0 for the purposes of this message) for my VPC. My understanding is that this IP is a public and assigned for me for the duration of the account.
When I drill/dig that IP address I got bunch of amazon A DNS records. I logged into my EasyDNS account and I pointed I mapped www.oko.com via A record to that public IP 55.4.55.0. That is not quite right since until Amazon DNS releases A record in reality that is CN record. How do I mange for Amazon to release 55.4.55.0 from its DNS server?

I mapped that public 55.4.55.0 to my private address 172.31.33.7. Sure enough I can see my web server on 55.4.55.0. However point www.oko.com goes into infinite search because I am guessing in reality my EasyDNS record for www.oko.com is not really A record but CN.


@rocket357
I was not quite following your post public subnet and private subnet within the VPC CIDR.

Could you please point me to some documentation?

[rocket357]

Hey Oko,

The EIP is yours until you release it. Be advised, if it is important, *do not release it*, as EIPs have a very short "free" lifetime at AWS and you may not get it back (though I have seen it happen if the customer opens a case very, very quickly after releasing it).

I assume you are talking about reverse dns? There's a form for reverse dns requests:

https://console.aws.amazon.com/suppo...code-ec2-email

Please note that you should have an A record *within your domain* that points to the EIP so our automation tools can verify the request easily. The A record that Amazon maintains won't play a role in the EIP's usefulness, honestly. You can have numerous A records that all point to the same IP (though typically the actual hostname is the A record and the remainder are CNAMEs...but for rDNS purposes you need to have an A within your domain for verification).

As for public/private subnets, see the following:

http://docs.aws.amazon.com/AmazonVPC...Scenario2.html

There's also a Scenario3, which covers VPN-only private subnets, which may or may not fit your requirements:

http://docs.aws.amazon.com/AmazonVPC...Scenario3.html

PM me if you want to discuss further.