3

I am managing two domain names and want to redirect one to the other. I set up a domain forwarding with 301 permanent redirection from domain S (source) to domain T (target). The server on domain T redirects all HTTP to HTTPS. The browser is redirected if I visit http://<domain-S>.

If I visit https://<domain-S> (note the S for TLS), I see:

Firefox detected a potential security threat and did not continue to <domain-S>.  ...

Firefox does not trust this site because it uses a certificate that is not valid for <domain-S>. The certificate is only valid for the following names: shortener.secureserver.net, www.shortener.secureserver.net

Error code: SSL_ERROR_BAD_CERT_DOMAIN

Please note that the HTTPS configuration is working well for <domain-T>. I believe that the problem is that the SSL certificate for https://<domain-T> is being served for https://<domain-S>.

How can I redirect the domain before serving the certificate?

miguelmorin
  • 249
  • 1
  • 5
  • 13
  • 1
    It really depends on what web server(s) you use to serve the two domain names and how you configure certificate(s) for them, which you didn't reveal enough details on above. Redirection does not change the mandate that any HTTPS requests must be served with the proper certificates, but for example on Windows, people usually mess up certificate mappings. That's the typical source of such errors. – Lex Li Apr 30 '20 at 22:36

3 Answers3

6

You must provide a valid certificate when the browser visits https://<domain-s>, the certificate check is performed before processing the page content/redirects/... and this is by design.

If you can't create a certificate for domain S and another for domain T, you can list both domains in Subject Alternative Name of your certificate: RFC5280, Section 4.2.1.6

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate.

Swisstone
  • 6,725
  • 7
  • 22
  • 32
2

There is no configuration change that will accomplish what you're trying to do - the problem is that the browser knows that the user tried to browse to domain-s and the website that was served up is protected by a certificate signed for domain-t. From the browser's perspective, domain-t is invalidly impersonating domain-s. The only way to change this would be to a Multi-Domain/SAN Certificate that is authoritative for both domain-s and domain-t. Alternatively, if domain-t is a subdomain of domain-s, you could use a wildcard certificate.

In short, this is TLS doing it's job - notifying the user that the server they reached is actually at domain-t instead of where the user tried to go.

Omar Buhidma
  • 358
  • 1
  • 8
  • 2
    And then there's *Server Name Indication* SNI, [RFC 6066, 3](https://tools.ietf.org/html/rfc6066#section-3). – Esa Jokinen Apr 30 '20 at 19:20
  • 1
    Assuming you're only supporting modern browsers, sure - SNI is built for this, if you only need to support modern browsers. – Omar Buhidma May 01 '20 at 00:46
1

This does exactly what you're trying to do using nginx assuming they reside on different IPs (you didn't specify):

server {
    listen 80;
    server_name olddomain.com;
    return 301 https://newdomain.com;
}

server {
    listen 443 ssl http2;
    server_name olddomain.com;
    ssl_certificate olddomain.fullchain.pem;
    ssl_certificate_key olddomain.privkey.pem;
    return 301 https://newdomain.com;
}

If they reside on the same server/IP then you need to setup and use SNI which is supported on most modern browsers or use a common TLS certificate.

Peleion
  • 303
  • 1
  • 7