I have a domain purchased at 1and1 and set up at AWS EC2 with SSL and Apache server.
Even the domain pointing to the correct IP (using nslookup I can see it), it works from some places and not from others.
For example, here from my workplace, I see this page (the domain does not reach the EC2 server):
I launched a Windows EC2 at AWS to make a test and from there, everything is correct (the page loads and SSL is valid):
From my client's computer, it has another behavior. It reaches the EC2 server, but is says the SSL is invalid:
Has anyone faced the same problem?
The first thing you need to do is get an Elastic IP, the instance IP can change during reboot etc but elastic IP are static IP’s so you should make sure you create one of them and assign it your running instance.
Create Hosted Zone and Record Sets
Documentation is here - https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html
Create a recordset and add values
Add the Amazon NameSpaceServers in Control panel of Domain Provider
Import the SSl certificate to AWS Certificate manager (Optional). Documentation is here https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html#import-certificate-api
Self signed certificate will not work.
Deploy the SSl certificate into Apache server and configure the traffic for https.
Open the AWS in-bond traffic port documentation is here - https://aws.amazon.com/premiumsupport/knowledge-center/connect-http-https-ec2/
Here is my story
I have Amazon EC2 with Tomcat 7 hosted at an Elastic IP as
http://ec2-XX-XXX-XXX-XX.us-west-X.compute.amazonaws.com:8080/webAppX
http://ec2-XX-XXX-XXX-XX.us-west-X.compute.amazonaws.com:8080/webAppY
http://ec2-XX-XXX-XXX-XX.us-west-X.compute.amazonaws.com:8080/webAppZ
Then I bought a domain at 1&1 as domainXYZ.com
I bought SSL from sslmate.com for the domainXYZ.com
Now, my confusions come
We follow instructions from sslmate.com and do the same for httpd from Amazon EC2 but when I access https:// , the browser says errors as below
Your connection is not private
Attackers might be trying to steal your information from ec2-XX-XXX-XXX-XX.us-west-2.compute.amazonaws.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is ec2-XX-XX-XX-XX.us-west-2.compute.amazonaws.com; its security certificate is from www.domainXYZ This may be caused by a misconfiguration or an attacker intercepting your connection. Learn more.
Could you please advice me what things I missed or wrong.
Question #2: How come I re-direct from 1&1 to ec2-XX-XX-XX-XX.us-west-2.compute.amazonaws.com?
I do see we have options such as FramRedirect, or A record by changing DNS using IP
But I'm not sure which one I should use for HTTPS will be handled.
Thanks,
Nghia
You are making your life unnecessary difficult.
Just buy the domain using AWS Route 53 and link it to your Elastic IP.
As soon as your instance is reachable via the domain set up a certificate for free using LetsEncrypt and EFF's certbot.
Finally open HTTPS port via AWS console security settings.
I have a question which I hope somebody can answer for me.
My situation: I have an Ubuntu Server running Apache2 on a EC2 Amazon instance, which is serving an OwnCloud instance.
My goal: I want to deploy HTTPS on this instance. I already configured the security group to allow HTTPS traffic from anywhere (as the server should be accessible from anywhere on the internet). We already have a domain name bar.com registered at another domain hosting company. But we want to point foo.bar.com to this owncloud installation.
My questions:
1) Which IP-address do I use to configure the DNS at this domain hosting company. Because the public ip-address and public DNS of the EC2 instance is renewed every time the instance restarts.
2) How do I generate the SSL certificate for HTTPS configuration of Apache2? More specifically, which common name (CN) do I need to put in the certificate. Because the public dns of the EC2 instance is changing on every restart. I think if I put the foo.bar.com CN in the certificate that the browser will throw a certificate error once the user gets redirected from foo.bar.com -> .compute.amazonaws.com, am I right?
In short: how do I deploy https on a EC2 instance at Amazon AWS with a dns at a third party domain name service?
To deal with the changing public ip address you've got two options, first and (for simple situations, best) go to the Elastic Ip Page, get an eip and associate it with your instance, this association and hence public IP will hang around even after start/stop. You can even move the eip over to a different machine if you need to. This option is very cheap (you only get charged for an eip if its not attached to a started server). You're then safe to point your dns at the eip. The alternative option is much more powerful and that is to use elb (load balancing) but it also involves a fair amount more work to setup.
I assume if you're asking about cn's you dont really want a "how to" on creating an ssl cert (please correct me if I'm wrong). For the cn you just use the domain name - it doesn't matter what ip address the name resolves to the cert is for the domain. If you have your own domain to point at your eip you dont need to care about the machines public hostname. A user will never see it.
I use SSL certificate for a web site I set up in Amazon EC2 Machine Instance. The SSL certificate is for one domain name, which is not public DNS for the Amazon Machine Instance. The browser always complains the mismatch in the domain name because it compares the domain name of the SSL certificate to the Amazon public DNS.
How can I set up not to cause this problem?
I tried both domain name forwarding and A Record setting.
Maybe it's because I'm not so familiar with Amazon EC2 and I haven't configured domain name correctly.
Any help will be greatly appreciated.
The browser compares the domain name that you've typed in the address bar with the domain name in the certificate. If they're different then there's an error: that's by design.
The way to "fix" this is to buy a certificate for whatever domain name you type into the browser to get to the EC2 instance: mywebsite.com, not ec2-x-y-z.compute-1.amazonaws.com or whatever...
After that the instance has an IP you can setup a domain name with it if you want. The easiest way is you can use through a DNS service like EveryDNS. Just provide your domain name registrar with EveryDNS’s domain name servers, create an EveryDNS account, add your domain and create an A record with your newly associated EC2 instance IP address.
after that you have to get a certificate for that domain name.If you do these steps and still having problems pls let me know.
also you can read here for further details.
and i faced same problem before you can check the amazon forums for the exact answer
I'm setting up a webserver for a system that needs to be used only through HTTPS, on an internal network (no access from outside world)
Right now I got it setup with a self-signed certificate, and it works fine, except for a nasty warning that all browsers fire up, as the CA authority used to sign it is naturally not trusted.
Access is provided by a local DNS domain name resolved on local DNS server (example: https://myapp.local/), that maps that address to 192.168.x.y
Is there some provider that can issue me a proper certificate for use on an internal domain name (myapp.local)? Or is my only option to use a FQDN on a real domain, and later map it to a local IP address?
Note: I would like an option where it's not needed to mark the server public key as trusted on each browser, as I have not control over workstations.
You have two practical options:
Stand up your own CA. You can do it with OpenSSL and there's a lot of Google info out there.
Keep using your self-signed cert, but add the public key to your trusted certs in the browser. If you're in an Active Directory domain, this can be done automatically with group policy.
I did the following, which worked nicely for me:
I got a wildcard SSL cert for *.mydomain.com (Namecheap, for example, provide this cheaply)
I created a CNAME DNS record pointing "mybox.mydomain.com" at "mybox.local".
I hope that helps - unfortunately you'll have the expense of a wildcard cert for your domain name, but you may already have that.
You'd have to ask the typical cert people for that. For ease of use I'd get with the FQDN though, you might use a subdomain to your already registered one: https://mybox.example.com
Also you might want to look at wildcard certificates, providing a blanket cert for (e.g.) https://*.example.com/ - even usable for virtual hosting, should you need more than just this one cert.
Certifying sub- or sub-sub domains of FQDN should be standard business - maybe not for the point&click big guys that proud themselves to provide the certificates in just 2 minutes.
In short: To make the cert trusted by a workstation you'd have to either
change settings on the workstations (which you don't want) or
use an already trusted party to sign your key (which you're looking for a way around).
That's all your choices. Choose your poison.
I would have added this as a comment but it was a bit long..
This is not really an answer to your questions, but in practice I've found that it's not recommended to use a .local domain - even if it's on your "local" testing environment, with your own DNS Server.
I know that Active Directory uses the .local name by default when your install DNS, but even people at Microsoft say to avoid it.
If you have control over the DNS Server you can use a .com, .net, or .org domain - even if it's internal and private only. This way, you could actually buy the domain name that you are using internally and then buy a certificate for that domain name and apply it to your local domain.
I had a similar requirement, have our companys browsers trust our internal websites.
I didnt want our public DNS to issue public DNS for our internal sites, so the only way to make this work that I found was to use an internal CA.
Heres the writeup for this,
https://medium.com/#mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af
i think the answer is NO.
out-of-the-box, browsers won't trust certificates unless it's ultimately been verified by someone pre-programmed into the browser, e.g. verisign, register.com.
you can only get a verified certificate for a globally unique domain.
so i'd suggest instead of myapp.local you use myapp.local.yourcompany.com, for which you should be able to get a certificate, provided you own yourcompany.com. it'll cost you thought, several hundred per year.
also be warned wildcard certificates might only go down to one level -- so you could use it for a.yourcompany.com and local.yourcompany.com but maybe not b.a.yourcompany.com or myapp.local.yourcompany.com, unless you pay more.
(does anyone know, does it depend on the type of wildcard certificate? are sub-sub-domains trusted by the major browsers?)
Development purpose only
This docker image solves the problem (thanks to local-ip.co): https://github.com/medic/nginx-local-ip.
It launches a reverse proxy in the port 443 with a public cert that works with any *.my.local-ip.co domain. Eg. your local IP is 192.168.10.10 → 192-168-10-10.my.local-ip.co already points to it (it's a public domain)! Assuming the app is running in your computer at the port 8080, you only need to execute this to proxy pass your app and expose it at the URL https://192-168-10-10.my.local-ip.co:
$ APP_URL=http://192.168.10.10:8080 docker-compose up
The domain is resolved with any public DNS you have configured in the devices where you want to access the app, but your traffic keeps local between your app and the client (through the proxy), so you can even use it to connect with devices within the same LAN network, without any of the traffic going out to internet, all the traffic is local.
The reason that is mostly useful for development is that anybody can launch an application with this same certificate, so is not really secure, but helpful when you need to expose your app with HTTPS while developing or testing (e.g. HTML5 apps in Android that are loaded with Webview).