I've got a fairly simple app deployed on OpenShift that uses CloudFlare as a DNS provider, since they support CNAME records for the root domain, which our current domain provider does not.
The issue with this setup is somewhere along the line https is not working. I believe this is an OpenShift issue because it's the same kind of issue you get when you've mapped the domain name to your app but haven't added the proper aliases yet - you get a timeout essentially.
We've got two aliases - with www and without. There's no option to specify https or anything with OpenShift aliases from what I can see. There aren't any SSL certificates assigned to these aliases as we do not need or use https - we're on the Free plan.
The main URL to access the site is http://www.jcuri.com - notice this works as expected, however https://www.jcuri.com times out.
Initially we were thinking of using CloudFlare page rules to auto-redirect to a non-https URL however this is locked down behind a paywall which we're hoping to avoid, as we don't need any of the Pro features.
Is there something I'm missing here? It seems that OpenShift is just denying any https connections purely because we don't have certificates assigned to the aliases. I wouldn't even mind if there were certificate errors, at least that would give us a chance to do a redirect on the actual NodeJS application, but we don't even reach that point.
Can anyone offer some advice on this?
Since those domains are not pointed directly at openshift via CNAME, but are seemingly redirected via another service (from what i can tell from the dns) it is hard to say whether it is OpenShift that is causing the https issues. If you do not have a custom ssl certificate installed on openshift, you will just get an invalid certificate error, but since you are using a redirect service, maybe it is possible that the service is checking the certificate first, seeing an error, and then not working?
Since the https page rules you stated above are behind a paywall, this actually makes a lot of sense that they are blocking it, not OpenShift. Godaddy provided a forwarding service that would allow you to point both www and naked domain to openshift correctly using cnames, i have used it before.
Related
I have a Meteor app that mysteriously redirects to the registered root url, when a new custom domain with different tld is registered and tried to be accessed. This happens only with custom domains… Please note that it is the root url that it’s redirected to, not the …herokuapp.com url…
Some other, perhaps important, detail is that this happens quite intermittently; meaning it doesn't always happen and mostly happens if the client has previously loaded the root url or another custom url pointing to the same app.
What could be the reason and how to overcome that?
I can verify that the reason was not at my DNS configuration level, nor at any Heroku configuration I have done. But perhaps I need to do further?
I do know that this has to do with different top-level domains and how servers act toward that... Some of them like .app require SSL to work and so on, and that can be weird sometimes... But some others like .com and .market also redirect to the root url when registered as custom url and tried to be loaded in the browser...
So how to overcome the issue and have the same app running in different domains without mysterious/unwanted redirects??
The reason was indeed due to the force-ssl package from the core Meteor.
The package redirects to the Meteor.absoluteUrl() if the connection isn't registered securely (HTTPS/SSL). Therefore the problem have appeared.
I'm trying to find a current, up to date answer for setting up naked domain with Godaddy and Heroku SSL. My goal is for all pages to land on a secure page at https://www.example.com
https://www.example.com does go to a secure page.
example.com goes to an insecure page.
https://example.com does not work.
My current set up is as follows:
In heroku settings:
Domain Name | DNS Target
example.com | example.com.herokudns.com
www.example.com | www.my-domain.herokudns.com
Go Daddy Settings:
CNAME | www | www.example.com.herokudns.com
Forwarding settings:
Forward to: https:// | www.example.com
Yeah, it's a pretty stupid issue that some of the big DNS manager providers out there still have. The way to solve it is to have a server with an SSL certificate installed, and then point your naked domain to that static IP. The server then will redirect to the "www" version of your domain, which is now served under SSL by Heroku. Tedious.
If you don't want to do all that, just use https://www.nakedssl.com, which does exactly that – but automated (and for free for one domain).
Disclaimer: I'm part of the team that created NakedSSL, but I hope you take this as help and not as self-promotion. As explained above, the problem is as easy as tedious to solve, and I think NakedSSL is a pretty straight forward workaround.
Root domains on Heroku require the use of ALIAS ANAME or FLATTENING records.
Unfortunately, a number of popular DNS hosts such as GoDaddy, Bluehost, Google Domains, OVH, Hostinger and others do not support these types of records. Many of these Providers will tell you there is no such thing as ALIAS, ANAME or FLATTENING Records and many of these providers will tell you to set an A Record instead, however;
A Records do not work with Heroku for routing
A Records require static IP Addresses and static IP Addresses do not work with Heroku for routing, because Heroku (and many other cloud platforms) use dynamic IP's.
Instead, you can either:
Not use a naked domain and just use your www sub domain
Redirect/ Forward your HTTP root domain to your www sub domain. This won't work for your HTTPS root domain though
Use an Alternate DNS Provider. Heroku recommends the following: https://help.heroku.com/NH44MODG/my-root-domain-isn-t-working-what-s-wrong
Solved it.
Best way to get SSL set up is to use this package which automatically makes every page on your app SSL. Fantastic package. https://www.npmjs.com/package/force-ssl-heroku
Getting the naked domain set up with Godaddy easily: Set forwarding to your domain: https://www.my-domain.com. This will redirect non www to the correct place. :)
I believe naked subdomain or wildcards are not supported by heroku automated certs because of the let's encryption restrictions. So you need to set up a subdomain everytime you want to use Heroku's automatic certs.
ALSO VERY IMPORTANT! Don't forget to remove or edit any unsercured links to external assets. Otherwise browsers will jugde the page with those links unsecured as described in the Modzilla support page about mixed content.
I am using CentOS Linux 7.3.1611 with Plesk Onyx 17.0.17 to forward (301) myolddomain.com to mynewdomain.com. mynewdomain.com has a valid SSL certificate.
However, if I go to https://myolddomain.com, then I get a certificate error and the domain does not get forwarded. How do I make https://myolddomain.com forward too. Do I need to host my old domain and use .htaccess to make the redirect? I don´t want to leave it as it is because that means having duplicate content and that´s obviously bad for SEO.
EDIT
The forwarding works fine for all non https requests.
This free service will forward the old domain to the new one...
https://redirect.pizza/
Once you set up the account there, you then need to update your A record and CNAME record in the DNS for the old domain to point to the redirect.pizza servers.
They use LetsEncrypt to generate the certificate for the old domain. I have been using it and it works perfectly.
Note that doing this could potentially let redirect.pizza put up anything they wanted on your old domain rather than forwarding to new domain, so you have to trust them. If you are worried about this, you could monitor the old domain and if they ever stop forwarding, then you could defensively update you DNS to no longer point to them.
You need to have a server at the old domain, and it has to have a valid certificate for the old domain name, in order to provide a redirect under https.
This is because of how https works. First the secure connection must be established, which requires the certificate. Only then can the http request and the redirect response be made.
I have my domain pointed in Cloudflare with SSL. My website runs with HTTPS protocol. The reason i mention them running is this.
I have my blog at blogspot and want to give it custom domain name which google allows. Unfortunately google wont allow HTTPS there. I had created my blog like this in DNS as blog.domain.com which runs as https://blog.domain.com and if i host this subdomain via Github, it opens correctly. The problem is when i use this subdomain in blogger, then there arises conflict and my site goes offline. Where am i mistaking in setting up all this?
Don't enable full or restricted SSL option in cloudflare. Use flexible SSL instead. This will setup things correctly.
I am having a bit of a struggle grasping how to use custom domains with my app. Its the common case of having an app that assigns users to subdomains, ex. user.theapp.com and they want to use a CNAME so m.theirsite.com resolves to the application. It seems that most services that do this require you to tell them what your custom domain is, and that just adding a CNAME record doesn't work. Steps:
User creates an account.
We tell them they can make a CNAME entry to yourstuff.theapp.com (which is the current location).
This is my confusion. After 1&2 my custom domain still isnt working.. so once the client makes that CNAME record and provides us with "m.theirsite.com", what special magic do we do with it to make those sites "the same"?
Thank you in advance.
Our solution was to use PHP/MySQL to solve this. As normal, you should have the external domain/subdomain CNAME'd to your app, however as you will see, the CNAME entry doesn't need to be to the exact subdomain on the app. Next, you will build an area into your database where a user can tell you what external site they have CNAME'd from. At this point, you will perform most of your authentication on the website based on the HTTP host, either grabbing the subdomain and using it as a client, or checking if the HTTP host is in your list of CNAME's and then referencing the client from there.
What the CNAME does is just point to a server location, so if you are using wildcards in your apache configuration, foo.myapp.com resolves to the same location as bar.myapp.com, but in the app can use the host to pull out the subdomain and find the client ("foo" and "bar"). When using a CNAME, like m.mywebsite.com --cnamed--> foo.myapp.com, the application no longer has that client information in the HTTP host, and as we mentioned, the apache wildcard setup (*.myapp.com) just tosses out the subdomain.. so because of this the client must tell us "I will be visiting from m.mywebsite.com, so make that a valid host name for my authentication as well."