Mailcow-dockerized: Allow fetching autoconfig.* over HTTPS

[foutrelis]

Currently an SSL certificate is automatically generated for autodiscover.* but autoconfig.* remains HTTP-only. Please consider reverting and/or adjusting commit 7386dc1e5cec2824d050f15c7429bf8b697e7db4.

I came across a situation where autoconfig wouldn't work. It was caused by Thunderbird's SiteSecurityServiceState.txt having an HSTS record for the mailcow-hosted email domain. (Possibly by opening an email containing resources from that domain which sends an HSTS header with includeSubdomains.)

My understanding is that Thunderbird 68 will check both http://autoconfig.* and https://autoconfig.* (with an additional pref to only do SSL). [1]

So, if I was using Thunderbird 68 and mailcow had an https://autoconfig.* endpoint, the cached HSTS record wouldn't break autoconfig in the above case.

[1] https://hg.mozilla.org/comm-central/rev/36511bbb7713

[chriscroome]

That sounds like a reason to consider merge request #2509 which addresses the problem as raised in #461 ?

[andryyy]

That PR will not be merged.

We don’t include subdomains for that reason in our config. So I wonder where includeSubdomains is coming from for you. :)

[foutrelis]

It's coming from the main website at https://example.com. Opening an email containing an image fetched from https://example.com/[..] will store the HSTS record in Thunderbird and prevent autoconfig from working.

I'm only asking you to consider generating an SSL certificate for autoconfig.* so Thunderbird 68 will be able to fetch the configuration over HTTPS. I understand that care must be taken not to break autoconfig over HTTP.

[mkuron]

@foutrelis, if any subdomain (that includes autoconfig) does not use HTTPS, includeSubdomain should not be set.

When we removed these SANs a few months ago, Thunderbird didn‘t even support autoconfig over HTTPS. That‘s changed now, so it‘s worth reconsidering. Personally I don‘t think it matters whether one can have 48 or 99 domains in Mailcow before manually managing certificates, but there certainly are people who fall between these two numbers and want things to stay as it currently is. I‘m leaning slightly toward adding autoconfig and thus decreasing the limit to 48 domains again — after all, the main reason we removed those names was that they weren’t used over HTTPS by anything.

[foutrelis]

Fair point about me setting includeSubdomains without considering the autoconfig subdomain. I have also thought about using ADDITIONAL_SAN=autoconfig.* and adapting the http->https redirect from the docs to respond to acme-challenges.

The domain reduction is a bit severe for sure. Thunderbird 68 supporting HTTPS autoconfig and HSTS preload requiring includeSubdomains could perhaps justify it. I haven't considered all possible implications though.

[Braintelligence]

@foutrelis Can you please share your adaption of the HTTP -> HTTPS redirect that works with autoconfig? I'm running into Challenge problems with ACME due to this.

EDIT: Nevermind, figured it out. Just copy the location portion of the well-known acme challenge down below in the same conf to the server portion of the autoconfig.
@andryyy Maybe we can incorporate this change for https://mailcow.github.io/mailcow-dockerized-docs/u_e-80_to_443/ ? This portion added to the autoconfig block shouldn't hurt anyone, right?

EDIT2: Hm, can't visit autoconfig on SSL. Seems I'm still missing something, certificate is there, though. If you naively put the well known portion into the autoconfig block and try to visit autoconfig on https you get redirected to the mailcow UI.

[andryyy]

You need to call the URL like this: https://autoconfig.develcow.de/mail/config-v1.1.xml

It does not rewrite everything to autoconfig.php anymore. We could actually add that to the PHP code. Would be easier than maintaining it via Nginx.

@Braintelligence I will change the u_e file now and push some updates. I _need_ to add a changelog today.

[Braintelligence]

Thank you @andryyy. You're the best :).

[andryyy]

Does it work for you? :)

[Braintelligence]

@andryyy It tries to serve the ssl certificate from mail.* for some reason :/
I changed the HTTP -> HTTPS redirect to not incorporate the autoconfig portion, anymore, though.
EDIT: The reason the wrong ssl certificate was served is that acme-mailcow was unable to verify the challenge due to missing well-known location in the current documentation.

[Braintelligence]

@andryyy
I had to use the older Nginx autoconfig block but leave out the location / and only incorporate location ^~ ./well-known/acme-challenge now everything works!
EDIT: Finally Thunderbird can see the settings automagically :).

EDIT2: For everyone else making it work, my site.conf extra block looks like this:

server {
  listen 80;
  listen [::]:80;
  server_name autoconfig.*;
  root /web;
  location ^~ ./well-known/acme-challenge/ {
    allow all;
    default_type "text/plain";
  }
}

[andryyy]

Do you use a reverse proxy?

Am 24.06.2019 um 11:46 schrieb Braintelligence [e-mail]:

Thank you @andryyy. You're the best :).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Braintelligence]

Nope. Plain latest Mailcow on Ubuntu 18 and nothing else.

EDIT: without the mentioned block acme wouldn't verify the domain.

[andryyy]

Cannot follow your changes, works fine here.

[Braintelligence]

I'll look at it again tomorrow. But as it stands, acme works and Thunderbird, too, so I'm happy :).

[andryyy]

Can you try to reproduce it? I tried and failed. :/

Bound to 80 and 443 without RP:

Just the change you see above.

If you are able to reproduce it, let me know and I will take a look, ok?

[Braintelligence]

I'll try tomorrow and will comment here again. Will test it on two servers.

[andryyy]

Thanks!

[Braintelligence]

I'm not sure why but I can't reproduce it anymore, but without that block I had problems getting a certificate issued on one of my mailcow instances on first sight. Adding it resolved my problems. Now I don't need new certificates and I see no errors without the block.

If I should see problems when certificate renewal is due I will comment again here. For now it looks like everything works as it should. 👍

[foutrelis]

Closing since 2efd27e40e6ecc59cc61858906b07be23b1a9fd0 added autoconfig to the SAN list.