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.
Related
Just updated our website, and migrated our DNS routing to the new server. The issue we are having now, is sometimes when a user types in our website 'example.com', it will sometimes route them to an HTTPS://example.com which isn't currently enabled.
Is there a way to have users routed to our HTTP://example.com instead of HTTPS://example.com, while we are waiting for SSL to be enabled on the new site?
No.
DNS is for resolving the hostname (example.com) to an IP address. You can't tell the browser to use HTTPS or HTTP via DNS.
I'm assuming that in the past, you've supported HTTPS. Once you've done that, the browsers often remember. The best thing to do is get your certificate place ASAP. You can use Lets Encrypt and Certbot and be done in a couple minutes in most cases.
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'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.
I recently moved servers and redeveloped the website at the same time. Previously all pages were served via https and I wanted to change this so only cart pages were via https. Also I wanted to clean up the url a bit. Old urls were:
https://secure.mydomain.com/onlinestore/index.php
and I removed the secure prefix and the subfolder so it is now:
http://www.mydomain.com/index.php
Problem is I wanted people who clicked on old links or bookmarks to be redirected to the new page. I got this working with htaccess. However the new SSL only covers the root domain and not the secure subdomain. So if someone clicks an old link it brings up "This Connection is Untrusted" before it can redirect. Works fine if i change https to http.
So what I want to know is if there is anyway I can force http instead of https before it checks the SSL cert.
Hope that makes sense!
The short answer is no. With conventional SSL, your web server doesn't even get to see the URL before certificate negotiation happens. It just sees a connection on port 443 and starts doing SSL negotiation. The browser then sees the mismatched cert and throws an exception.
However, more modern browsers and web servers (see Wikipedia for the list) support a TLS extension called Server Name Identification (SNI), which allows the client to send the hostname it's requesting before the server has to respond with a certificate. At that point you'll need to have certificates for both secure.mydomain.com and www.mydomain.com on that server, and it'll need to be configured to respond with the proper certificate.
I'm a beginner in .htaccess and I need help. We have this website with its store module in https. We also have a parked domain pointing to this website. The problem is, when I type "https://www.parked_domain_name.com/store/" in the address bar, I get an SSL error. However, when I type "http://www.parked_domain_name.com/store/" on the address bar, it redirects to "https://www.parked_domain_name.com/store/" without getting any SSL errors. How can I view the store w/o SSL errors when I type "https://www.parked_domain_name.com/store/" in the address bar?
In general, you can only have HTTPS running on a single domain name for a site.
There are exceptions, for example a certificate for *.example.org would let you run HTTPS on both www.example.org and web.example.org subdomains. Also, some certificate providers will issue certificates for a fixed list of several domain names.
But in common usage, one IP address can have only one certificate, and one certificate can have only one domain name.
The behaviour you describe of the http URL redirecting the the https URL without warnings does not sound like it is possible. Perhaps try a few different browsers - they all act a bit differently on this front. How you reached the URL is not relevant. If you access example.org over HTTP and the certificate says anotherdomain.com then you will get SSL warnings.
You're best off running the site only on e.g. https://example.org/ and redirecting any other domains to that one, rather than hosting the site from multiple domains.
I hope this helps.