0

My hoster directly resolves *.mydomain.tld to my server, whitout having to setup subdomains manually. This nicely allows me to add subdomains using virtual hosts. Now the problem with that is that also subdomains that i don't need will resolve to that server. I'd like to handle that using a temporary redirect (in case i add a subdomain, permanent doesn't seem sensible):

<VirtualHost _default_:80> # note: going to http would redirect to https anyways, so directly going https here Redirect / https://www.mydomain.tld </VirtualHost> 

So far so easy, works fine. Now let's do the same on https.

<VirtualHost _default_:443> Redirect / https://www.mydomain.tld </VirtualHost> 

That does not work, because ofc i do not have a wildcard certificate (using letsencrypt), so any browser accessing i.e. https://foo.mydomain.tld will complain about not being able to make a secure connection before the redirect would be sent.

Is there any other way around this i'm missing here? I also tried using RewriteEngine, but with the same result, as the header would only be sent after the secure connection has been made.

If that is not possible, would it be sensible to just throw away the default conf? What would happen with non-configured domains in that case?

8
  • 1
    Without a wildcard certificate, every connection would fail at SSL/TLS level. Then it's up to the user to click on "continue to site anyway" to receive your redirect. It is not possible to change that for unknown hostnames unless you use a wildcard certificate, and even in that case, take into account that wildcard does only work for a single level: that is, if you have *.domain.com, it would work for unknown.domain.com, but it won't for subdomain.unknown.domain.com. Commented Sep 19, 2020 at 10:02
  • @NuTTyX would it be possible to just 404 in that case? Commented Sep 19, 2020 at 10:05
  • @Mr.Manhattan: Any kind of HTTP response requires a successful TLS handshake first. This includes the redirect (302, 301) but also the error page (404). Commented Sep 19, 2020 at 10:07
  • Darn...then i guess i'll have to live with that... Commented Sep 19, 2020 at 10:09
  • 1
    Nope. SSL/TLS error will always happen first. Just think that https is http on top of a pre-existing SSL/TLS later, so if the connection fails to validate the certificate, the http part won't have any way to talk to the server. If your server wasn't listening on port 80, you would not receive a 404 trying to reach it from your browser, just a "couldn't connect to server", right? This is the same: if the browser does not like the certificate, there is no connection for the http part to proceed. Commented Sep 19, 2020 at 10:10

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.