Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
General:
i try to figure out whats wrong with my cert config. i ran everything exactly like always. the issue is - if i type in https://cavort.de (f.e.) everything is fine. if i leave the https:// it redirects to the multisite host url (thx4.dev)
I'm sorry, I'm confused. Are both domains yours? Or just cavort.de?
Also, how did you get the certificate? How did you install it into the webserver? Also please show the output of the command: sudo apachectl -t -D DUMP_VHOSTS
both domains are mine. there are a couple more pointing onto the multisite.
the multisite host is thx4.dev. cavort.de is pointing to one of the subs.
output sudo apachectl -t -D DUMP_VHOSTS
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443 thx4.dev (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80 thx4.dev (/etc/apache2/sites-enabled/000-default.conf:4)
There is only one vhost for HTTP.
Do you understand Apache?
OR
Are you just "publishing" the sites via WordPress?
[if WP, then it has failed to add the secondary site(s)]
@doori Your HTTP VirtualHost is missing all the ServerAlias directives. This will cause the SERVER_NAME variable to always point to ServerName thx4.dev. Add the ServerAlias directives and the redirect should work for all.
And what if you switch out ServerName thx4.dev and ServerAlias cavort.de to become ServerName cavort.de and ServerAlias thx4.dev? E.g., reverse those two? Just as a test for the hypothesis regarding the SERVER_NAME variable.
I was assuming the Apache documentation stating:
SERVER_NAME The ServerName of the current vhost
Also included ServerAlias, but I could be wrong there..
Edit: I just tested locally and it seems ServerName/ServerAlias/SERVER_NAME should just work perfectly for the RewriteRule no matter what.. Even without the ServerAlias directives So I have no idea why your rewriterule would do such strange things, i.e. redirecting always to the same host..
Long shot: maybe a .htaccess somewhere overruling the VirtualHost redirect?
Did you test with UseCanonicalName on ? Because I seem to remember that you may need to use ${HTTP_HOST} for redirect matches when you have that set. I could be remembering wrong and I don't have an Apache to test with at the moment.
In either case, trying ${HTTP_HOST} for the RewriteCond and RewriteRule should work equally well here.
Hm, might be due to the fact curl adds the port to the Host header when explicitely applied on the command line. Weird.. I was using a Pebble test vhost which uses port 5002 Lemme force the Host header.
Ah yes, it was cURL giving me trouble and not Apache/HTTP_HOST! I can confirm your solution to be working @MikeMcQ
Although that does signify the possible issues with using HTTP_HOST, as it's directly coming from what the client put in the Host header apparently...
It's possible removing the UseCanonical would allow server_name to work (less port?) but it was recommended for Apache at one time to avoid some bug or attack. I don't recall the details. So I am hesitant to suggest that.
The other way to resolve this would be to use separate VirtualHosts for each set of related names. Then they would not need to use any RewriteCond and just do a redirect to the one common server_name. That is how we usually see VirtualHosts setup which is why this problem does not often appear.
That's due to some exploits for WordPress, see the CVE in the Apache configuration from OP above.
That's also a possibility, yes. A little bit a "dirty hack" IMO, but certainly a possible solution.
Frankly, I don't see why Apache shouldn't just also use ServerAlias for the SERVER_NAME variable with UseCanonicalName set to On, as that wouldn't be, I think, an exploitable thing.