![]() |
|
General software and network General OS-independent software and network questions, X11, MTA, routing, etc. |
![]() |
|
Thread Tools | Display Modes |
|
||||
![]()
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).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
||||
![]() Quote:
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 Quote:
|
|
||||
![]() Quote:
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. 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 =\ ).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. Last edited by rocket357; 23rd March 2015 at 11:43 PM. |
|
||||
![]()
@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. |
|
||||
![]() Quote:
Quote:
Hit me up via PM if you need any additional assistance, I'm more than happy to help =)
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. Last edited by rocket357; 24th March 2015 at 12:10 AM. |
|
|||
![]()
That is why a lot of Linux users are investigating the *BSD's.
![]()
__________________
Linux since 1999, & also a BSD user. ![]() |
|
||||
![]()
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? Last edited by Oko; 18th April 2015 at 02:12 AM. |
|
||||
![]()
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.
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
![]() |
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Browser Security Certificates | shep | News | 0 | 10th July 2014 01:36 PM |
Security Mozilla takes action against CAs issuing man-in-the-middle certificates | J65nko | News | 0 | 20th February 2012 11:33 PM |
CA hack: more bogus certificates | J65nko | News | 3 | 5th September 2011 10:02 PM |
NetBSD now available on Amazon EC2 | J65nko | News | 0 | 15th March 2011 12:11 AM |
New Research Suggests That Governments May Fake SSL Certificates | Carpetsmoker | News | 0 | 25th March 2010 09:28 PM |