Why does my Debian server require a specific ServerAlias but my Ubuntu server doesn't?

OS type and version Debian 11
Webmin version 2.111
Virtualmin version 7.10.0
Webserver version Apache 2.4.59
Related packages Apache

So I’ve setup a CNAME for mta-sts.${DOM} and that works/correctly points to the domain, but on my Debian server Apache will serve up the SSL cert for another domain when I navigate to it. I fixed it by adding a ServerAlias mta-sts.${DOM} directive in the domain’s .conf but I’m curious why it’s necessary.

On another server – Ubuntu 22.04, Apache 2.4.52 – I have several domains setup the same way but they don’t require a ServerAlias directive to serve the proper SSL cert. I guess that’s why it took me so long to think of it as a solution.

Maybe this isn’t the place to ask/discuss but I find it odd that the issue didn’t raise it’s head on my other server with even more virtual hosts active. Does anybody know if it may suggest there is a problem with my config on either server, or could it possibly just be differences in the builds at compilation time that makes them behave slightly differently?

I think and I’m no expert the http challenge is for http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>
if the <YOUR_DOMAIN> doesn’t match the cert your requesting it for it will fail, I presume.

use this site might give you the answer.

Did a little checking on this. Is it a server wide thing or does it actually break out stats per domain? If it is per domain it’s curious that it would work without updating Apache and LetsEncrpt unless you are using some type of wildcard/defaults.

I’m not sure if this could be the actual problem? The mta-sts from how I have been setting up has always been an A record.

mta-sts	3600	IN	A	your.server.ip.here

I can’t remember where I have read that from because it has been over 6 years now since I have set them up.
This is the only info I have in my notes I can start you off with: https://datatracker.ietf.org/doc/html/rfc8461


This shows an example of how it should be set up.

1 Like

Well I don’t have any problems getting certs issued, it all works properly, Debian’s Apache just didn’t serve the right SSL cert without a ServerAlias directive (Ubuntu server doesn’t have this issue). As far as I know it is per domain, each of my domains has their own policy file/TXT record etc.

The several MTA-STS check sites I’ve used showed no issues the way I have it set now, I used to have a separate sub-server for each of my domains just for mta-sts until I recently saw a post somewhere of it only needing a CNAME so I swapped to that to reduce clutter in my virtualmin domain list lol. The only reason I even found out one domain was serving the wrong cert was from one of the sites.

All said and done, everything is working as intended as far as I can tell/verify – just an interesting difference between the two servers, and something I’ll have to stay aware of. My servers are nothing critical, just home/hobby stuff.

I found the article related to my last post https://techcommunity.microsoft.com/t5/exchange-team-blog/introducing-mta-sts-for-exchange-online/ba-p/3106386
Bottom section about implementation:


We try to respect RFCs to the best of our abilities. The goal is to achieve the best interoperability possible. In a small number of scenarios, there may be unexpected behavior, and we’ll do our best to document that behavior.

For example, one difference in behavior involves CNAME records and MX records. Having a CNAME record for an MX record doesn’t comply with the SMTP RFC, but in the interest of successfully sending the email of our customers, we currently resolve CNAMEs to the servers that they point to for message deliveries. For MTA-STS, we’ve taken a stricter approach to supporting the RFC. We do not support CNAMEs when MTA-STS is used. If a domain uses a CNAME and follows the MTA-STS RFC, that domain will fail our MTA-STS checks, and will not receive emails from us. However, it’s possible for a domain to include the final server in their MTA-STS policy and pass our MTA-STS checks, even though that would not strictly follow the MTA-STS RFC.

We had a client a while back that had issues with the CNAME so we resolved it by changing them all to an A record.

Hope this helps if you ever arrive to this problem.

Interesting, I’ll have a deeper look and may adjust again. From a quick glance, I’m not entirely sure this fits for my use case, as my actual MX servers have A records for mail.${DOM}, it’s only the mta-sts.${DOM} that is a CNAME to point to the policy file. It seems like they are suggesting they don’t follow CNAME for the MX record. I’ll have a closer look soon, thanks for the information!

Ah, from the RFC:

Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in [RFC7234]) MUST NOT be used.

I guess I need to to take another stab at it after all :woozy_face:
Edit: Or maybe not? Just checked and Firefox’s console shows a 200 OK for the CNAME. Hmm, now I’ve got myself all wishy washy haha

If it’s working for you, I wouldn’t bother with it.
This is something that came about few years back because Micro$oft considered the MX record with mail.mydomain.tld as a CNAME over the actual mail server name. They could have fixed that issue on their end by now. We just haven’t changed anything since then and left it alone.

i may also just be entirely over-thinking it at the moment. After checking a different domain, mailhardener.com says everything is ok, whereas mxtoolbox.com complains about the certificate – it shows the cert for the default server, but in a browser the proper domain’s cert is served. Who knows how long either of them cache things, I’ll try and do some testing to see what shows up as an issue because now I’m just too curious.

Edit: Yeah, I think I will just default to adding ServerAlias mta-sts.${DOM} to my Apache directives, as including it makes mxtoolbox see the proper cert, and that was the only thing it was complaining about after deeper inspection.