Okay, this one is weird. I have four domains set up so far. Let’s just call them a, b, c, and d.com for now. I’ve spent about 4 hours trying to solve this one, I’m pretty sure it’s got to be a bug.

I have all the DNS set up the same for the four domains, specifically including the mail. autoconfig. and autodiscover. entries for each.

Sites a.com and b.com (and I’m indicating the order I set them up in, too) have been great. a.com is the main PTR name, too. All the SPF records allow a.com to send for all the domains.

The DNS button on the domain list for c.com (the third domain I created) will never come up. Just spins and spins. The modal comes up but never populates. Of course having already done the work on a.com and b.com I knew what was required. I just used those as templates, and I found the DKIM data somewhere else in the UI. The DNS information for the next domain, the fourth domain (problem below) does come up just fine.

Now… the fourth domain. Sigh. Domain d.com is the problem child. I brought up the third domain above in case somehow its issue is related to the fourth domain. The mailcow-acme simply will not attempt to get a cert for mail.d.com. It generates for autoconfig.d.com and autodiscover.d.com, but not mail.d.com. I’ve done the force_renew/restart several times (trying to minimize before LetsEncrypt gets fussy, seen that before).

Of course I’ve replaced the domain names and IP addresses and stripped the “log” timestamps, etc., but note the “[[WHERE…”


Using existing domain rsa key /var/lib/acme/acme/key.pem
Using existing Lets Encrypt account key /var/lib/acme/acme/account.pem
Detecting IP addresses...
OK: 1.2.3.4, 0000:0000:0000:0000:0000:0000:0000:0000
Found A record for autodiscover.d.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autoconfig.d.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autodiscover.b.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autoconfig.b.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autodiscover.a.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autoconfig.a.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autodiscover.c.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for autoconfig.c.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for mail.a.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for mail.b.com: 1.2.3.4
Confirmed A record 1.2.3.4
Found A record for mail.c.com: 1.2.3.4
Confirmed A record 1.2.3.4
[[ WHERE IS mail.d.com ??? ]]
Certificate /var/lib/acme/mail.a.com/cert.pem doesn't exist yet or forced renewal - start obtaining
Creating backups in /var/lib/acme/backups/mail.a.com/2024-07-26_20_41_58 ...
Checking resolver...
Resolver OK

…and further down in the log:

acme-mailcow-1  | Creating new order...
acme-mailcow-1  | Order created!
acme-mailcow-1  | Already verified: autoconfig.d.com, skipping...
acme-mailcow-1  | Already verified: autoconfig.b.com, skipping...
acme-mailcow-1  | Already verified: autoconfig.a.com, skipping...
acme-mailcow-1  | Already verified: autoconfig.c.com, skipping...
acme-mailcow-1  | Already verified: autodiscover.d.com, skipping...
acme-mailcow-1  | Already verified: autodiscover.b.com, skipping...
acme-mailcow-1  | Already verified: autodiscover.a.com, skipping...
acme-mailcow-1  | Already verified: autodiscover.c.com, skipping...
acme-mailcow-1  | Already verified: mail.b.com, skipping...
acme-mailcow-1  | Already verified: mail.a.com, skipping...
acme-mailcow-1  | Already verified: mail.c.com, skipping...
[[ AGAIN WHERE IS mail.d.com ??? ]]
acme-mailcow-1  | Signing certificate...
acme-mailcow-1  | Certificate signed!

Can anyone offer a suggestion on how I might resolve this issue? My next step (was up past midnight trying to solve, tackling again this morning), is to see if there’s a massive export and import process so I can maybe rebuild everything. Or if there’s a just straight up way to script the entire build. I have all the setup for all the domains documented, including user passwords, but haven’t investigated that yet. I feel like the setup of c.com and the subsequent DNS-won’t-show issue could be related, but I don’t know.

I’ll be glad to provide additional information. Really, really, liking mailcow so far, and I feel like this is just a “lucky me” glitch and that it’s a wonderful project! VERY polished.

Let me also add that the website https://mail.d.com does come up, but “cert issues”. So the server is recognizing that the name is associated with the domain and I can log into it.

And I have these entries in the mailcow.conf, trying to solve it this way, didn’t help:

ADDITIONAL_SAN=mail.d.com,mail.c.com,mail.b.com
ADDITIONAL_SERVER_NAMES=mail.belden.net,mail.c.com,mail.b.com,mail.a.com

I also, just now, tried changing to ENABLE_SSL_SNI=y, but that didn’t help, since I just got knocked out with the too many certificates (5) already issued for this exact set of domains in the last 168 hours: message. Clearly mail.d.com didn’t get included in this last attempt.

Let me also add that the website https://mail.d.com does come up, but “cert issues”. So the server is recognizing that the name is associated with the domain and I can log into it.

And I have these entries in the mailcow.conf, trying to solve it this way, didn’t help:

ADDITIONAL_SAN=mail.d.com,mail.c.com,mail.b.com
ADDITIONAL_SERVER_NAMES=mail.belden.net,mail.c.com,mail.b.com,mail.a.com

I also, just now, tried changing to ENABLE_SSL_SNI=y, but that didn’t help, since I just got knocked out with the too many certificates (5) already issued for this exact set of domains in the last 168 hours: message. Clearly mail.d.com didn’t get included in this last attempt.

Let me also add that the website https://mail.d.com does come up, but “cert issues”. So the server is recognizing that the name is associated with the domain and I can log into it.

And I have these entries in the mailcow.conf, trying to solve it this way, didn’t help:

ADDITIONAL_SAN=mail.d.com,mail.c.com,mail.b.com
ADDITIONAL_SERVER_NAMES=mail.belden.net,mail.c.com,mail.b.com,mail.a.com

I also, just now, tried changing to ENABLE_SSL_SNI=y, but that didn’t help, since I just got knocked out from LE with the too many certificates (5) already issued for this exact set of domains in the last 168 hours message. Clearly mail.d.com didn’t get included in this last attempt.

Let me also add that the website https://mail.d.com does come up, but “cert issues”. So the server is recognizing that the name is associated with the domain and I can log into it.

And I have these entries in the mailcow.conf, trying to solve it this way, didn’t help:

ADDITIONAL_SAN=mail.d.com,mail.c.com,mail.b.com
ADDITIONAL_SERVER_NAMES=mail.belden.net,mail.c.com,mail.b.com,mail.a.com

I also, just now, tried changing to ENABLE_SSL_SNI=y, but that didn’t help, since I just got knocked out from LE with the too many certificates (5) already issued for this exact set of domains in the last 168 hours message. Clearly mail.d.com didn’t get included in this last attempt.

(Sorry about the repeated content. Was adding as a Reply since I can’t find an Edit button. I kept getting 500 errors doing the post, but it was adding to the original post, but showing me an error. I didn’t notice it was doing this. That should be looked into.)

[unknown] And, since I missed hiding it, d.com is belden.net. Bah.

    Additional information attempted today, restarting between each thing, none of the steps solved the issue. Each step also included the force_renew step and a restart of the entire docker stack.

    _It’s worth adding that during my testing the DNS modal for d.com shows that autoconfig.d.com and autodiscover.com both point as a CNAME to mail.d.com and that mail.d.com does resolve to the correct IP address._

    • Completely wiped all d.com mailboxes and then the domain and regenerated (this dropped the autodiscover.d.com and autoconfig.d.com from the LE cert request.)
    • Changed ADDITIONAL_SAN=mail.d.com,mail.c.com,mail.b.com to ADDITIONAL_SAN=mail.*
    • Updated to ADDITIONAL_SERVER_NAMES=mail.d.com,mail.c.com,mail.b.com,mail.a.com
    • Even changed to have: SKIP_LETS_ENCRYPT=y but still contacts Let’s Encrypt. (I know because I get the rate limit error message because there’s no change, namely the inclusion of mail.d.com that isn’t happening. I was hoping to only see the IP verification for each expected domain.)
    • Changed to: ENABLE_SSL_SNI=y
    • Changed to: SKIP_IP_CHECK=y
    • Changed to: AUTODISCOVER_SAN=n (they were still included in the request.)

    Okay, fixed it. Followed the instructions at: docs.mailcow.email Icon Reset TLS certificates - mailcow: dockerized documentation

    docs.mailcow.email Icon docs.mailcow.email
    Reset TLS certificates - mailcow: dockerized documentation
    None
    docs.mailcow.email

    Unfortunately, part of the commands failed, namely the removal of directories. Those should probably be run as sudo. (I ran the entire block, if I had run each line one by one, I would’ve caught it.) Happy, though, the log check now showed inclusion of mail.d.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!

      CaptainPalapa Unfortunately, part of the commands failed, namely the removal of directories. Those should probably be run as sudo

      You have to control the stack as ‘root’ user anyway, just as the documentation states:

      docs.mailcow.email Icon Install mailcow - mailcow: dockerized documentation

      docs.mailcow.email Icon docs.mailcow.email
      Install mailcow - mailcow: dockerized documentation
      None
      docs.mailcow.email

      Using sudo etc breaks stuff!

          No one is typing