I set up cloudflare with ssl and a 301 redirect to ssl this morning. Everything seemed to work, but now, i'm back on http and the redirect is not working. I'm trying to figure out why and the DNS-system is sometimes a bit hard to decipher. I'm using a swedish registrar, Loopia. Loopia in turn passes the DNS-records to cloudflare.
Is there some way to figure out if I even go through cloudflare any more?
To determine which names servers you have set:
dig NS DOMAIN
This should only return Cloudflare name servers (unless you enabled Cloudflare via your hosting provider's integration). If you see other name servers in addition to the Cloudflare name servers that indicates you left your other names servers in place at the time you setup Cloudflare. To use Cloudflare you'd need to remove all other name servers other than the ones they provide. Other name servers being in place would return non-Cloudflare IPs which would explain the behavior you're seeing.
Related
I see that in CloudFlare’s DNS FAQs they say this about wildcard DNS entries:
Non-enterprise customers can create but not proxy wildcard records.
If you create wildcard records, these wildcard subdomains are served directly without any Cloudflare performance, security, or apps. As a result, Wildcard domains get no cloud (orange or grey) in the Cloudflare DNS app. If you are adding a * CNAME or A Record, make sure the record is grey clouded in order for the record to be created.
What I’m wondering is if one would still get the benefits of CloudFlares infrastructure of the target of the wildcard CNAME record IS a Cloudflare Worker, like my-app.my-zone.workers.dev? I imagine that since this is a Cloudflare controlled resource, it would still be protected for DDoS for example. Or is it that much of the Cloudflare security and performance happening at this initial DNS stage that will be lost even if the target is a Cloudflare worker?
Also posted to CloudFlare support: https://community.cloudflare.com/t/wildcard-dns-entry-protection-if-target-is-cloudflare-worker/359763
I believe you are correct that there will be some basic level of Cloudflare services in front of workers, but I don't think you'll be able to configure them at all if accessing the worker directly (e.g. a grey-cloud CNAME record pointed at it). Documentation here is a little fuzzy on the Cloudflare side of things however.
They did add functionality a little while back to show the order of operations of their services, and Workers seem to be towards the end (meaning everything sits in front). However, I would think this only applies if you bind it to a route that is covered under a Cloudflare-enabled DNS entry.
https://blog.cloudflare.com/traffic-sequence-which-product-runs-first/
The good news is you should be able to test this fairly easily. For example, you can:
Setup a worker with a test route
Point a DNS-only (grey cloud)
record at it
Confirm you can make a request to worker
Add a firewall rule to block the rest route
See if you can still make the request to worker
This will at least give you an answer on whether your zone settings apply when accessing a worker (even through a grey cloud / wildcard DNS entry). Although it will not answer what kind of built-in / non-configurable services there are in front of workers.
I have a website, example.com, that has a subdomain called play.example.com which hosts a multiplayer game on it.
Separately, I have an Elastic Beanstalk environment that hosts the game server (NodeJs backend), separate from the client build itself.
play.example.com connects to the game server over https, but is met with the error: ERR_CERT_COMMON_NAME_INVALID.
Steps I have taken:
1) Created an SSL certificate for *.example.com using AWS Certificate Manager
2) Added a listener to my load balancer that listens on port 443
3) Created an alias, type A IPv4 with the name play.example.com to the EB url
I understand the the error means that there is a name mismatch between the URL and the certificate, but isn't that what the alias is supposed to fix?
Thanks for any suggestions.
Okay, I've spent about a week now trying to fix these issues myself, and unfortunately Stackoverflow is full of people asking this question and nobody's giving answers.
Here's how I solved it, some of this might work for you too. It ended up being primarily configuration issues.
Your SSL cert is appropriate - I ended up hardcoding my subdomain ops.example.com but your wildcard shouldn't be an issue.
I read somewhere that AWS requires any DNS records to be of type CNAME, so I set up a basic CNAME record to redirect ops to my-site.my-aws-region-1.elasticbeanstalk.com
Then, what ended up being the linchpin to the whole thing was that in order to make HTTPS work, your load balancer has to be Listening for HTTPS on 443 and route to the instance via HTTP on 80.
Amazon was trying to tell me this, but because I was a noob and because their tutorials are some of the worst tutorials I've read in my entire career, they actually don't expose any of your secure ports to the internet. Which is actually fine because your traffic is encrypted all the way up to the load balancer, and then after that, even though it's not HTTPS anymore, it's all already on amazon's servers anyway so it's not any less secure.
Hope something in here helps!
I have recently acquired a domain name from GoDaddy. At home i am trying to setup a nextcloud server. Since my ISP serves me a dynamic IP addresse i had to create another domain name on no-ip website. Furthermore, i want to forward http requests to https. The following questions rises:
Do i create the ssl certificate (with let’s encrypt) for the godaddy domain or the no-ip domain?
What is the correct forwarding sequence here? Assume godaddy is foo.com and no-ip bar.dyndns.me and the user types foo.com, my server apache settings would forward foo.com:80 to :443 but this i guess should be corrected to my dyndns. I am confused.
I would appreciate any help - thank you.
you are making it too complicated. Instead of using a redirect you should request a static ip from you isp. this costs money varying by your provider but then you only need one domain. you then apply the ssl certificate to that domain and enforce ssl only with your hosting server (i.e apache, iis).
You can write a simple app/script to manage the Dynamic DNS from your server using the GoDaddy Api, thats what i have been doing for ~3 years now as my ISP want a stupid amount for a static IP. I have mine pinging out every 10 mins to check if my IP changed (ISP sucked for a while and mine would change several times a day)
Here are some links to various implementations of the GoDaddy API
BASH
Python
Powershell
So I think I have a fix for this, before I give you my answer I will outline problems with other solutions.
Static IP from your ISP. The problem with this is it may cost too much. (However if it’s cheap I’d probably do this solution)
Script and update godaddy DNS. This is okay however only if you can allow for some outage time between changes. (The DNS will take time to Propagate up to 24 hours)
Upgrade your noip account to a plus managed DNS it costs $29.95 a year. However it will allow you to bring your own domain name from another provider like go daddy. Depending how often your noip client is running there could be a very small outage between changes.
https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
I've run into a strange problem. If I put a site name in the site bindings, the Default Web Site on ISS is not recognizing it. Suppose I leave it blank, then I'm able to get the pages but they show up with the server IP address.
This is a problem because with SSL, it will either not serve pages or it will give me a site warning.
Note that I have the DNS working of GoDaddy with forwarding and masking to the public IP of my EC2 instance on AWS.
All of this started overnight when the SSL cert expired. I have since put a new certificate that's valid but I cannot get the site working again.
I've done a lot of debugging including diffing the old configuration that was working with the new one and I'm not able to understand why this happens.
Setting the site name causes both http and https to not work.
Much appreciate any help in solving this - Thanks in advance!
This appears to be a problem with masking with forwarding provided by the domain host Go-Daddy. For some reason, with masking with forwarding, the response is enclosed in a frame and that frame says the src is the public IP address of the server rather than the domain name.
I also think that there is a problem with https forwarding with masking. While the reason this problem happened is not clear, for now, the fix has been to change the domain from masking with forwarding for http requests alone to point at the http server public IP address.
This is not the ideal solution but at least has the website back up and running. I'll post an update once I know more about masking with forwarding and why that suddenly stopped working.
I set up DNS server using CloudFlare few days ago. After then I found that CloudFlare provides reverse proxy. In "off-the-orange" state, I can connect server through ssh but In "orange" state, it's not.
Now I know that I have to register other A-Record like "ssh.domain.com" In "off-the-orange" then I can get what I want. However I can't sure it's right.
Is there other way to connect server through other protocol?
No, there is no other way, that's exactly what Cloudflare expects you to do, see: How do I SSH? and DDoS Prevention: Protecting The Origin. Cloudflare doesn't offer reverse proxy without DDoS protection.
If you have only one domain, you add subdomain A record for actual server, pointing to the server IP. Then you add CNAME for protected website. Cloudflare uses CNAME flattening so it's possible to have CNAME like my-domain.com -> actual.my-domain.com.
That setup has security implications: If someone finds out the subdomain, it exposes the real IP address and attacker can bypass Cloudflare protection.
Cloudflare DNS is very strict on how they respond. They don't leak anything, you have to explicitly know domain and record type to get the answer. Ie. digmy-domain.com ANY does not give away anything, you have to ask for a record type: dig my-domain.com A which returns Cloudflare proxy IP. And obviously, they don't respond to AXFR request either so only way to get actual IP from Cloudflare DNS is brute-force. I have feeling Cloudflare might detect and block such attempt.
Of course, you don't want to rely on obscurity only. Some things you could do to protect your server in case IP/subdomain is exposed:
throttle ssh connections (ufw tutorial)
configure your HTTP server to respond only desired host names ie. my-domain.com and maybe www.my-domain.com (nginx example)
also, you could deny HTTP(s) connections coming outside of Cloudflare Network.
The "Orange Cloud" icon on the DNS tab of your CloudFlare Dashboard indicates that all HTTP/HTTPs requests sent to that address are going to be forwarded through CloudFlare's reverse proxy system. This means that all connections will actually hit CloudFlare's server, then CloudFlare will "proxy" the connection and pull the page from your webserver.
When you proxy connection through CloudFlare, no direct connections are created between the client and your actual web server. If you have an "A Record" in place for a purpose other than HTTP requests, you will need to create a new record without the "Orange Cloud" icon.
How to create a new record:
Select the website you would like to create a new record for.
Select the "DNS" tab.
Select the record type you would like to create.
Enter the subdomain or record name you would like to create.
Enter in the details or IP you would like to point this record to.
Example:
If you create a new record (Like sshdirect.example.com) and point it to your server's IP, and ensure that the cloud icon is grey. You can then attempt to connect to that hostname instead of your standard one.