icing / mod_md

Let's Encrypt (ACME) in Apache httpd
https://icing.github.io/mod_md/
Apache License 2.0
334 stars 28 forks source link

Error on unused alias discrepancy #301

Closed orlitzky closed 1 year ago

orlitzky commented 1 year ago

I'm finally trying to push this into production, and production has other ideas:

[Sun Oct 23 07:08:47.501404 2022] [md:error] [pid 6543] AH10040: Virtual Host support.example.com:0 matches Managed Domain 'support.example.com', but the name/alias example.com itself is not managed. A requested MD certificate will not match ServerName.

I've already set MDMembers manual, and have requested a certificate only for support.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:

The first matching ServerName or ServerAlias is used, with no different precedence for wildcards (nor for ServerName vs. ServerAlias).

In our case, we're defining www.example.com with an alias for example.com, and then later defining support.example.com with an alias for example.com, relying on the latter alias being superseded.

whereisaaron commented 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.

orlitzky commented 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.

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 :)

orlitzky commented 1 year ago

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).

orlitzky commented 1 year ago

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

uschwarz commented 1 year ago

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.

icing commented 1 year ago

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.

orlitzky commented 1 year ago

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.

icing commented 1 year ago

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.

uschwarz commented 1 year ago

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 :-)

orlitzky commented 1 year ago

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.

icing commented 1 year ago

Thanks! With that example, I can understand what is going on and will think about how best to fix this.

icing commented 1 year ago

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

orlitzky commented 1 year ago

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.

icing commented 1 year ago

Thanks for testing.