I have an application in Cloud Foundry lets say http://something.cfapps.io. Also I purchased a custom domain lets say http://mynewapp.com. Currently, I am masking the custom domain to the domain from Cloud Foundry.
My question is, if I want to enable SSL in Cloud Flare which domain should I put as secured ? Is it the first one or second one ?
You can actually do both through our SSL options. I assume you're looking at something like Flexible SSL?
Step-by-step instructions for setting up SSL on a custom domain can be found here.
http://docs.run.pivotal.io/marketplace/integrations/cloudflare/index.html
Basically this results in requests going to CloudFlare over HTTPS and being sent to your application over SSL via https://.cfapps.io. This is the "Full SSL" option and it gives you end to end encryption. What it doesn't give you is certificate checks and so despite it being very unlikely, it is technically susceptible to a man-in-the-middle attack.
The "Full SSL (strict)" option would eliminate the possibility of a man-in-the-middle style attack, however this doesn't work at the moment because the certificate check expects the incoming domain (i.e. your domain) to match the domain on the backend server's certificate, which it won't since your domain won't match ".cfapps.io".
Related
Please can someone advise if what I'm trying to do is possible - apologies I know a lot more about AWS than Azure, and I can't find any guidance online or bypass the issue by setting up services and 'giving it a go'.
I want to send SSL-secured subdomain traffic from AWS where our primary domain is hosted to Azure where some dependent services and resources are hosted. We want to use AWS ACM for SSL management/renewals, removing any dependency on third parties or Azure for this if at all possible.
I am able to set up a CloudFront distribution with an origin of an Azure Storage Account endpoint:
xxx.blob.core.windows.net
With an alternate domain name of a subdomain of the desired URL:
xxx.xxx.co.uk
I can secure this with a wildcard ACM SSL, and the resultant images are all secure.
I have also set up a static web app, applied a custom domain to it of:
xxx.xxx.co.uk
And with the appropriate DNS/CF I can make traffic to that Azure SWA secure.
Is it possible to do the same with Azure App Gateway? All the things that I've tried or the developers working in Azure (a third party) have tried do not work, we end up with mostly 502 errors depending on the configuration. Depending on the CF/DNS configuration, I can get through to the correct resources/services by bypassing an SSL warning.
Would adding a port 80/non-https listener for our subdomain on the App Gateway work?
I'm following the serverless-stack guide and have a website hosted in an Amazon S3 bucket. I purchased a domain using GoDaddy and I have set up cloudfront to work with this bucket, then have used AWS certificate manager to generate SSL certificates for my domain (both www.my_domain.com and my_domain.com).
In GoDaddy I then configured DNS forwarding to point to my cloudfront resource.
This all works nicely, and if I go to my_domain.com in a browser then I see my website.
However, I can't get SSL working. If I go to the https:// version of my website then I see a not secure error in the chrome address bar which shows a certificate pointing to shortener.secureserver.net rather than my own website.
Could someone point me at a way around this? Looking through S.E. and using google it seems that Amazon's route53 might be able to help, but I can't figure out how to do this.
Thanks!
(edit) To make things more clear, this is what I see in Chrome if I connect to https://my_website.com or to https://www.my_website.com
The warning message:
The certificate details:
What I do not understand is why, after configuring an AWS certificate for my domain, I see a certificate for shortner.secureserver.com rather than a certificate for my_website.com.
Go daddy has problems and does not redirect to https, There are two ways, the first is to change domain registrar and the second is the easiest, which is: Create a hosted zone on AWS router 53 with your domain name
Create 2 type A records, one for the root (of your domain) and one for www that point to your cloudfront. Router 53 allows you to create a type A record without having an IP, because it directly points to a cloudfront instance that you indicate, that's the best
Then in go daddy it gives you the option to change name servers and puts the ones assigned by aws in hosted zone with the record that says NS and you put those 4 in Godaddy, replacing the ones that had
Note: SAVE THE NAME SERVERS THAT YOU HAVE IN GO DADDY BEFORE REPLACING THEM, IN CASE YOU HAVE ANY PROBLEM, YOU CAN REPLACE THEM AGAIN
You have to wait at least a few hours until all the name servers are updated, you can use the who.is page to see if the DNS have already been updated with those of aws.
It turns out that this is not possible with GoDaddy. If anyone else reading this has a similar problem, only current solution is to cancel your domain registration and register with someone else.
(edit) As #aavrug mentions in their comment, Amazon now have a guide for this.
When you defined your CloudFront you can defined whether you want to use, and you can choose HTTPS only. In this case HTTP requests will be automatically redirected to HTTPS. Have in mind CloudFront changes may take a while to be replicated and your browser cache it as well, so the best way is to make a change, wait for the deployment and then check it in a new cognito browser.
It goes without saying that your certificate must be valid and verified as well.
It might be something wrong with your certificate or with your domain.
If you serving your content over HTTPS you must provide a SSL Certificate in Cloudfront. Have you done that?
Have you added your domain on Alternative Domain Names (CNAMEs)?
Please have a look on the image below:
-> AWS provides Free SSL Certificates to be used with Cloudfront, so you might want to use it (easier than you import your SSL from go daddy).
You can create a free SSL certificate on AWS and easily attach it to your cloudfront distribution.
-> You can also transfer your domains to AWS Route53. It is easy to integrate with any AWS Service and easy to use/maintain :)
I wrote a complete guide on my blog telling how you can add Custom SSL and attach custom domain to Cloudfront distribution, it might be useful :)
https://lucasfsantos.com/posts/deploy-react-angular-cloudfront/
I know that you can add your own certificate to the domain and point that domain to the AWS Elastic Load Balancer. In my case I don't have domain, but would like still use secure HTTPS/SSL connection when talking client <-> backend. Is it possible to enable HTTPS connection directly to ELB, i.e instead of using http://some-random-url-here.eu-west-1.elb.amazonaws.com I would like to use https://some-random-url-here.eu-west-1.elb.amazonaws.com
That would mean, that AWS would need to provide the cert for the *.elb.amazonaws.com domain. I remember at least long time ago this was possible, but maybe my memory does not serve me right?
Memory does not serve you right. This is not possible now and would not have been possible in the past. ELBs don't have, and it is not possible to obtain, a certificate like this (including from Amazon Certificate Manager).
In fact, 3rd party providers like Let's Encrypt also have protections to prevent you from obtaining certificates like this, since amazonaws.com is not your domain.
You will need a domain that you control.
I have domain with aws example.com, currently I have record set so that when user goes to example.com, it serves static website from S3 (done with angular). Now, I have backend api (Lambda and API gate way), which is has url something like,
https://randomid.execute-api.region.amazonaws.com/Prod/api/getSomething?id=1
so, what I am trying to do is if front end makes a http call to example.com /api/getSomething?id=1, it should return me data (since I am using relative urls).
I was reading aws documentation, it seems i cannot use root domain, I have to use subdomain (api.example.com), I am ok with it. But, I am not sure how can i do that, any help would be appreciated.
Also, I may move my front end to subdomain (web.example.com), if I do that, with my backend at (api.example.com, hope fully I will figure this part), will I run into CORS issue?
Go through this AWS developer guide to change the domain name.
Apart from DNS configurations, it also requires to have a SSL certificate for the custom domain (Which could be taken from AWS Certificate Manager for free).
Also note that an API's custom domain name can be the name of a subdomain or the root domain (aka, zone apex) of a registered Internet domain.
If your Web and API have different subdomains, it will run into CORS. However you can setup a CloudFront distribution infront of both Web and API to avoid CORS.
(StackOverflow won't let me use "mydomain.com" as an example so I have to use the real domain--sorry all but I tried to not make this an ad)
So I've generated an SSL certificate for *.fantasyadsnetwork.com through AWS Certificate Manager and created a load balancer that can receive www.fantasyadsnetwork.com traffic (http & https) and that portion works great.
The issue I am running into is handling users who key in "https://fantasyadsnetwork.com" into the browser. Note the lack of www (naked domain.) As it stands they are presented with an error message like:
The exact messaging is browser dependant. If you add an exception, click ignore, etc then the user loads the site (which detects the lack of www & redirects the user to https://www.fantasyadsnetwork.com/) just fine but that is an ugly hurdle for a user to jump through.
Any suggestions on how to work around this? Preferably without having to buy a separate SSL certificate from GoDaddy or someone else.
I found my own answer:
When you are setting up the certificate in AWS Certificate Manager if you enter a single *.fantasyadsnetwork.com domain it will not support the naked domain. However they allow you to enter multiple domains so just include the naked domain as well. The bad news is you can't edit this after you've created the certificate so you'll need to create a new one.