0

I have a website hosted on *.mydomain.com, my Apache web server in conjunction with PHP will return/echo some plain text based on the subdomain provided. *.mydomain.com is secured with a wildcard SSL certificate.

I need to allow users to redirect requests from their own domain to my domain, for example: demo.theirdomain.com to demo.mydomain.com

I've accomplished this with HTTP using CNAME records, however I've read that this is not ideal. And I need my website to be served over HTTPS. When I try and connect to the site on https://demo.theirdomain.com over HTTPS I will receive a certificate mismatch error.

What is the best way to allow other subdomains to redirect their requests to my domain securely? NOTE: I do NOT want users to create their own certificates.

Owen
  • 21
  • 2
  • Just to clarify, you want a user to visit `https://demo.theirdomain.com` but have content served up from a server you control (demo.mydomain.com) using your mydomain.com certificate and the browser to remain at `https://demo.theirdomain.com`? – sippybear Feb 25 '20 at 22:10
  • Correct @sippybear – Owen Feb 26 '20 at 03:34

2 Answers2

2

Unfortunately a CNAME is not going to work in this case. As you've said, your certificate is only valid for *.mydomain.com and will not work for any other domain. Using a CNAME from demo.theirdomain.com to mydomain.com is going to result in a certificate mismatch error because the client has been lead to believe it is connecting to demo.theirdomain.com but the server (mydomain.com) is providing a certificate for *.mydomain.com

You'll need to rethink the way that you're attempting to do this. I would advise putting more details about why you're doing this so we can avoid an X-Y problem but I'll go ahead and give two possible solutions:

  1. The other domain needs to utilize a redirect such as an HTTP 302. A web server would sit at demo.theirdomain.com and serve an HTTP response of 302 to redirect the client to mydomain.com. This will allow the client to realize that the current server is a mydomain.com server and that the *.mydomain.com certificate is valid for it. If this is not ideal because you want demo.theirdomain.com to be the only domain visible, try #2. This redirect is however likely the best solution for you.
  2. A reverse proxy can sit at demo.theirdomain.com and provide a pass-through/backend over at mydomain.com. The advantage of this is that the reverse proxy will handle the certificate transitions because the connection is terminated at demo.mydomain.com and therefore the certificate there (hopefully configured correctly) is valid. A new connection is initiated at the reverse proxy to mydomain.com and is considered valid. You've said you don't want users to create their own certificates so this solution is likely not ideal for you, especially since it also involves a reverse proxy setup (although they could configure a DNS entry for demo.theirdomain.com to point to an IP on your reverse proxy).

You could have certificates on your end for their domains but it sounds like that would not be feasible for you. I would advise against using wildcard certificates wherever possible as they are not good security practice.

duct_tape_coder
  • 826
  • 4
  • 13
  • I'm working on a muti vendor shopping cart web application that uses subdomains to distinguish individual stores (stored in a database). Stores are being created continuously across multiple servers. I don't expect my end users to have any knowledge of website and server administration, which is why in in search of a solution on my part. I've researched into SAN certificates and SNI certificates, not sure if theses would help? – Owen Feb 26 '20 at 01:55
  • 1
    The problem would arise that you won't know what the domains are that need to be covered by a certificate until after the customer starts with you. So you'll either need to re-issue the certificate (with SAN) or obtain a new one (SNI) every time a new domain needs to be covered. If you're using commercials CAs such as Verisign, that's an expensive proposition. An alternative would be to use your own CA but that means getting all the customers of those domains to trust your CA which is impractical. Or you could try using a service like Let's Encrypt but that could also be difficult. – duct_tape_coder Feb 26 '20 at 04:37
1

If your user wants to redirect their domain https://demo.example.net to your domain https://demo.example.com only two configurations are possible:

  1. They run a TLS web server with a valid certificate, which redirects (using HTTP redirects) everything to demo.example.com,
  2. You run a VirtualHost named demo.example.net with a valid certificate. In this case you can get rid of the redirect and serve the content directly.

In any case they have to obtain a valid certificate for demo.example.com, but things get easier if you use Let's Encrypt certificates. In this case:

  1. the client just needs to authorize you to use the demo.example.net domain as per Let's Encrypt terms of service, notably you must satisfy the condition:

    You warrant to ISRG and the public-at-large that You are the legitimate registrant of the Internet domain name that is, or is going to be, the subject of Your Certificate, or that You are the duly authorized agent of such registrant.

  2. to obtain such a certificate, you just need demo.example.net to point to your address (which is already done) and use an ACME client like certbot to obtain and renew certificates.
Piotr P. Karwasz
  • 5,748
  • 2
  • 11
  • 21