Closed orlitzky closed 1 year ago
Suggest you create two VirtualHost's for the same content/application, one with the HTTPS names/aliases and one with the HTTP names/aliases. Then enable TLS/SSL and a Managed Domain to issue a certificate just for the HTTPS endpoint.
Suggest you create two VirtualHost's for the same content/application, one with the HTTPS names/aliases and one with the HTTP names/aliases. Then enable TLS/SSL and a Managed Domain to issue a certificate just for the HTTPS endpoint.
That's not quite the problem I have, but the idea isn't far off. I know I can solve this by copy/pasting vhosts and dropping the alias from some, but I'd really rather not do that if it can be avoided. It's a maintenance nightmare to keep them all in sync.
And unless I've misdiagnosed the problem, what I'm doing isn't outrageous. The docs say that certain aliases will in effect be ignored. If apache ignores them, I think mod_md should too. However if @icing tells me to go kick rocks I may have to rethink my plan :)
This also kills the entire server when a certificate is desired for (www.)example.com and other subdomains exist. This works:
<IfModule md_module>
MDomain example.com www.example.com
</IfModule>
<VirtualHost 192.168.1.1:80>
Use VhostRedirect www.example.com
RedirectMatch permanent (.*) https://www.example.com$1
</VirtualHost>
<IfModule md_module>
<IfModule ssl_module>
<VirtualHost 192.168.1.1:443>
Use VhostDrupal www example.com
SSLEngine on
Use HttpsOnly
</VirtualHost>
</IfModule>
</IfModule>
But if I also add,
<VirtualHost 192.168.1.1:80>
Use VhostRedirect shop example.com
RedirectMatch permanent (.*) https://shopping.example.com/
</VirtualHost>
<IfModule ssl_module>
<VirtualHost 192.168.1.1:443>
Use VhostRedirect shop example.com
Use Ssl wildcard.example.com
RedirectMatch permanent (.*) https://shopping.example.com/
</VirtualHost>
</IfModule>
I get my favorite error ever,
[Sat Dec 03 21:25:55.882111 2022] [:emerg] [pid 32181] AH00020: Configuration Failed, exiting
before the entire server crashes. I'd love to tell you what's going wrong under the hood, but I have no idea.
I realize you don't know what any of those macros do (although they're "public..." I can push them to my github account if asked), but the only slightly unusual thing that is taking place is that the shop.example.com vhosts also declare an (ignored) example.com ServerAlias after the www.example.com vhosts do the same (but not ignored, as these come first in the file).
I realize you don't know what any of those macros do (although they're "public..." I can push them to my github account if asked), but the only slightly unusual thing that is taking place is that the shop.example.com vhosts also declare an (ignored) example.com ServerAlias after the www.example.com vhosts do the same (but not ignored, as these come first in the file).
After de-duplicating the ServerAliases, this still fails, so I was wrong to lump them together. I've moved the new issue to https://github.com/icing/mod_md/issues/304
I think I'm hitting the same thing from a different angle… for "interesting" reasons, I'm forced to use two CAs, and I had hoped I could setup something along the lines of (yes, that's not proper config syntax below):
Machine A, public CA
MDomain vanitydoma.in auto
ServerName vanitydoma.in
ProxyPreserveHost On
# additional settings that disable SSL certificate validation etc. for ProxyPass
ProxyPass / https://theproject.my.edu/
Machine (cluster) B, assume CA that only issues for my.edu
MDomain theproject.my.edu manual
ServerName theproject.my.edu
ServerAlias vanitydoma.in
So AFAICT, I'd be good if "AH10040 … but the name/alias itself is not managed …" was a warning only, not an error. As it is, I really can't see what the use case for manual
would be if this isn't it, because you can request extra names even with auto
, and if you use manual
and don't list all the names, httpd
will configtest ok and fail on startup. (IIRC mod_ssl
has it at warning level.) Or do we need/want a third sledgehammeresque "Trust me I know what I'm doing" setting?
I've omitted some abstraction layers (the ProxyPass
is really RewriteMap
+ RewriteRule [P]
), so "just don't use ProxyPreserveHost" isn't really an option here.
Thanks @uschwarz for the good suggestion. Just realeased https://github.com/icing/mod_md/releases/tag/v2.4.22 with this change.
Would be good to know if this solves your and @orlitzky 's woes as well.
Would be good to know if this solves your and @orlitzky 's woes as well.
Thank you! Some of my woes are solved :)
I tested this with a wiki.example.com
host having an alias of example.com
. The wiki host is declared after a www.example.com
host, also having an alias of example.com
. Now that much works:
[Wed Jul 12 10:03:42.947843 2023] [md:warn] [pid 27444] AH10040: Virtual Host wiki.example.com:0 matches Managed Domain 'wiki.example.com', but the name/alias example.com itself is not managed. A requested MD certificate will not match ServerName.
But, if I also try to use mod_md for the "www" host (to see if #304 is still a problem), I now get a new error:
[Wed Jul 12 10:02:51.127405 2023] [md:error] [pid 17226] AH10238: conflict: 2 MDs match Virtualhost wiki.example.com which uses SSL, however there can be at most 1.
[Wed Jul 12 10:02:51.128156 2023] [ssl:emerg] [pid 17226] AH02572: Failed to configure at least one certificate and key for wiki.example.com:443
[Wed Jul 12 10:02:51.128173 2023] [ssl:emerg] [pid 17226] SSL Library Error: error:0A0000B1:SSL routines::no certificate assigned
It looks like mod_md is still associating the wiki.example.com
host with its example.com
alias, even though that alias is unused by apache itself. In other words, the error has just been pushed upwards a bit.
But it's still an improvement; I can now use mod_md for a subdomain if I only use it for subdomains.
Sorry, @orlitzky, I still cannot read your macro setup. I simply lack the time to do this. If you cannot boil it down to a plain config example reproducing it, we may both have to live with it.
Thanks @uschwarz for the good suggestion. Just realeased https://github.com/icing/mod_md/releases/tag/v2.4.22 with this change.
Would be good to know if this solves your and @orlitzky 's woes as well.
Thanks for the quick followup. Works for me, now all I need to do is shuffle the troublesome domains to the back of the list until this has percolated through to ondrej :-)
Sorry, @orlitzky, I still cannot read your macro setup. I simply lack the time to do this. If you cannot boil it down to a plain config example reproducing it, we may both have to live with it.
I don't think you need to know anything about the macros for this one. There are two vhosts,
MDMembers manual
# vhost1
ServerName www.example.com
ServerAlias example.com
# vhost2
ServerName wiki.example.com
ServerAlias example.com
If I try enabling mod_md...
# vhost2
MDomain wiki.example.com
ServerName wiki.example.com
ServerAlias example.com
This used to crash immediately, but now it works with v2.4.22. However, if I also enable mod_md for the first vhost,
# vhost1
MDomain example.com www.example.com
ServerName www.example.com
ServerAlias example.com
then I get the new error,
[Wed Jul 12 10:02:51.127405 2023] [md:error] [pid 17226] AH10238: conflict: 2 MDs match Virtualhost wiki.example.com which uses SSL, however there can be at most 1.
The alias "example.com" is still being associated with the second (wiki) vhost, even though the first vhost should take precedence.
Thanks! With that example, I can understand what is going on and will think about how best to fix this.
I made release v2.4.23 with a new directive MDMatchNames
that allows you to have more control over how the module assignes MDomains to VirtualHosts. See: https://github.com/icing/mod_md#mdmatchnames
I made release v2.4.23 with a new directive
MDMatchNames
that allows you to have more control over how the module assignes MDomains to VirtualHosts. See: https://github.com/icing/mod_md#mdmatchnames
Perfect, thank you. I'm cautiously optimistic that #304 is fixed as well: to test v2.4.23, I enabled mod_md in a scenario very much like the one in #304 and apache started just fine.
Thanks for testing.
I'm finally trying to push this into production, and production has other ideas:
I've already set
MDMembers manual
, and have requested a certificate only forsupport.example.com
. mod_md is, I think, unhappy that an alias is declared which won't wind up on the cert.The alias
example.com
is unused in this case, so it's intended that the certificate won't be valid for it. While it may not be the cleanest configuration, the apache docs say that we can get away with this:In our case, we're defining
www.example.com
with an alias forexample.com
, and then later definingsupport.example.com
with an alias forexample.com
, relying on the latter alias being superseded.