just trying to lock down some information as I've asked several hosting providers and I'm not sure I've got a clear enough answer to satisfy. It's a two part question: how to have HTTPS to HTTPS redirects (any webserver, I'm just looking for concepts), and what would be a suggested way to implement.

Let's say I have a domain with several TLDs: example.ca, example.net, and example.com. I want my site to be served from https://example.com only, the .ca and .net are to be redirected over both http and https.

http(s)://example.ca -> https://example.com
http(s)://example.net -> https://example.com
http://example.com -> https://example.com
  1. For the https://example.ca/.net -> https://example.com redirect to work, do I need to have an SSL certificate for each of example.ca, example.net, and example.com, even if the .ca and .net are just for redirects and nothing is being hosted on them? Would a UCC/SAN SSL certificate be able to have all 3 domains covered?

  2. From what I have read, the simplest way to do this would be to: get a simple shared hosting plan, install the UCC SSL certificate, and update the web server config to make all HTTP and HTTPS traffic redirect to https://example.com. Is that correct?

I have seen some DNS registrars like GoDaddy offering 'Domain Forwarding', but from what I've read this is only over http. To get the https redirects working I'd need my own server where I'd install the certs myself.

EDIT: I'm not sure I can give an answer yet, as there's still some confusion as to if I need certs for all the domains. @Xzenor and @davidgo are saying I do need a cert for each, but @LTPCGO is saying I only need one for the final domain (but a wildcard one to include subdomains).

  • Redirects are just websites. They need to listen to the hostheader and then give the browser a 30x response with an url. So that means that the https versions also need a certificate. If all they do is redirect then Let's Encrypt should probably suffice for this. It doesn't matter if it's http to https, or https to https. Just make sure the server listens to both and that it redirects the browser to the correct https website – Xzenor Jan 11 '20 at 13:34

You can forward a fetch to an insecure domain onto a secure domain without issue. You would do this at the server level in your hosts file using redirects so all content is served from example.com. You will need an SSL certificate for this final domain, example.com, either with a wildcard (*.example.com) or for specific subdomains.

On the server hosting example.com, you will need to redirect all traffic to HTTPS, which does depend on your server. For Apache, you could use something like the following:

NameVirtualHost *:80
<VirtualHost *:80>
   ServerName www.yourdomain.com
   Redirect / https://www.yourdomain.com

<VirtualHost _default_:443>
   ServerName www.yourdomain.com
   DocumentRoot /usr/local/apache2/htdocs
   SSLEngine On
# etc...

Once everything is working you should look at implementing HSTS

  • Unfortunately I'm not sure this answers my question. I think what you've written is that, using my example, example.net -> example.com is fine (http -> https), but that doesn't handle https -> https redirects. – errorline1 Jan 9 '20 at 2:35
  • How do you do that? I'm basing my knowledge of this article, where it states the initial handshake to example.net would still need a valid SSL certificate even before the redirect happens. You're saying I could do it in the DNS record, do you have a resource I could read? – errorline1 Jan 9 '20 at 2:44
  • Ignore DNS stuff, I confused the first part of your question a bit, you should be able to do it all in your server configuration utilising 301 redirects, – LTPCGO Jan 9 '20 at 2:50

Conceptually http and https redirects are identical. In each case they are configured similarly. Typiy that implies the browser hitting the old site and getting a "300" series response along with the new URL.

Because both the old and new do.ains are involved, you need certs for each of these. They can be separate certs issued by the same or different providers, or a single cert covering all the names.

If all the domains are directed to the same virtualhost (which would be a bit unusual, but not extremely uncommon usage case) you would need a single cert covering all domains.

From a technical POV there is no such thing as domain forwarding. In most cases this is a construct where all URLs are rewritten, served by a "catchall" virtualhist which detects the domain name. This does not work well for https because the catchall server would need the https certs to not error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.