Hi!
My mailcow hostname is mail.example.com.
I have the problem that nginx is handling traffic on example.com and serving the mailcow ui and that also with the wrong certificate that is for mail.example.com. I used to have example.com set in the mailcow.conf as ADDITIONAL_SERVER_NAME. But i took it out again.
Now, I cant find any reason in the nginx configs (eg there is no server_name set to example.com, or default server) why it is behaving this way. I could set an explicit handling but I want to find the root cause as I think it is a bug in mailcow how it handles changes to the ADDITIONAL_SERVER_NAME parameter.

I have another issue which might be related: When setting up an account on thunderbird with autoconfig/autodiscover it gives a warning that I should add a security acception as the certificate is for the wrong name.

Any ideas how to find the root cause?
Happy to provide you with any logs that can be helpful.

Thank you and much love to all beings ❤️

EDIT: Just as a side note: I have an A record for example.com on the same ip as mail.example.com

Have something to say?

Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!

esackbauer

I am using the standard mailcow nginx setup. Nothing special yet.

I guess that means a “yes” for my first question?
How do the certificates that mailcow gets are installed on your nginx reverse proxy?

    esackbauer

    How can I check? I didnt change anything. It’s the default mailcow setup. The certs are issued by LE with the default acme container

    You still did not answer my first question 😉
    Please clarify, do you have a separate nginx reverse proxy (e.g. where you host example.com)? Or do you want to use the nginx inside of mailcow for that?

      esackbauer
      Right now I am not hosting anything on example.com. I am likely going to but right now nothing is hosted on example.com. I have not setup anything additional as to the default mailcow setup.
      So I dont have a separate nginx reverse proxy (yet), I want to get this working first.
      But for whatever reasons, example.com is served with the mailcow UI with a cert for mail.example.com.

      My theory is that when I set example.com as ADDTIONAL_SERVER_NAME it changed some configs that it later didnt change back accordingly.

        Philipp But for whatever reasons, example.com is served with the mailcow UI with a cert for mail.example.com.

        Seems you are very new to hosting web services.ADDITIONAL_SERVER_NAME is telling mailcow what to listen for. But not how the certificates are generated
        What you need is ADDITIONAL_SAN to include the example.com name in the certificate.
        docs.mailcow.email Icon Advanced SSL - mailcow: dockerized documentation


        And then follow this documentation for hosting different web pages:
        docs.mailcow.email Icon Custom sites - mailcow: dockerized documentation
        docs.mailcow.email Icon docs.mailcow.email
        Custom sites - mailcow: dockerized documentation
        None
        docs.mailcow.email

        However I strongly suggest to not use mailcow for such a thing. Instead use a nginx in front of mailcow as reverse proxy. Then you could run e.g. WordPress behind that, and send mailcow traffic to mailcow.

          esackbauer

          I am pretty new to this overall topic, thats why i mistakenly put example.com as ADDITIONAL_SERVER_NAME at first.
          But as I said I changed it back when I noticed that it is not what I want to do. There is no ADDITIONAL_SERVER_NAME set anymore. Thats what I am pointing out.
          I assume there are some config arifacts still there that mailcow left over.
          I dont want ADDITIONAL_SAN=example.com for now because I am not using example.com for anything (for now).
          (I could as a workaround for the thunderbird issue though)
          However, even setting example.com as ADDITIONAL_SAN wouldnt solve the problem that example.com shouldnt be served with the mailcow UI.

          You know that you have to issue docker compose up -d to make any changes to the config active?

            esackbauer

            Yes, I know that.

            esackbauer

            So it sounds like this is unexpected behavior and a bug in mailcow?
            It shouldnt server example.com with the mail UI, right?

            Which artifacts / leftover configs could lead to this issue?

            Just to understand your issue better:

            You set up your mailcow as mail.example.com but don’t want to access the mailcow UI via mail.example.com but via example.com instead?

            If so, then there is no other way as to set

            ADDITIONAL_SAN=example.com

            AND

            ADDITIONAL_SERVER_NAME=example.com

            No one is typing