Mailcow-dockerized: autoconfig.* is not included in the LE cert by default

Created on 23 Jun 2019  Â·  50Comments  Â·  Source: mailcow/mailcow-dockerized

The documentation found here states that Mailcow checks the subdomains autoconfig and autodiscover for each added domain and if these subdomains resolve to the IP of the server running mailcow, it will include these subdomains in the certificate generated by Let's Encrypt.

It seems like this is only true for the autodiscover subdomain. The acme container detects the autodiscover subdomains and adds them to the certificate, but it does not do so for the autoconfig subdomain. To add these to the cert, I have to add ADDITIONAL_SAN=autoconfig.* to mailcow.conf. Please either update the documentation or add the expected behaviour to the acme container.

I'll be happy to provide additional information if you can not reproduce.

enhancement
Source
picture Syndace
👍2

Most helpful comment

This has nothing to do with the original issue, could you please stop posting your own issues here, I don't want to get spammed with notifications that have nothing to do with my post.

picture Syndace on 27 Jun 2019
👍3

All 50 comments

Yes. It was removed. Docs need updates. :)

Am 23.06.2019 um 17:24 schrieb Syndace notifications@github.com:

The documentation found here states that Mailcow checks the subdomains autoconfig and autodiscover for each added domain and if these subdomains resolve to the IP of the server running mailcow, it will include these subdomains in the certificate generated by Let's Encrypt.

It seems like this is only true for the autodiscover subdomain. The acme container detects the autodiscover subdomains and adds them to the certificate, but it does not do so for the autoconfig subdomain. To add these to the cert, I have to add ADDITIONAL_SAN=autoconfig.* to mailcow.conf. Please either update the documentation or add the expected behaviour to the acme container.

I'll be happy to provide additional information if you can not reproduce.

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

andryyy picture andryyy on 23 Jun 2019

Docs are being rebuilt, can you check back in a bit?

andryyy picture andryyy on 23 Jun 2019

Hmm, is there a reason it was removed ? Last time i've checked Thunderbird it now uses https instead of http for autoconfig :/

edit: But well anyway, being able to add it through ADDITIONAL_SAN if needed is great :)

sriccio picture sriccio on 23 Jun 2019
👍1

Thunderbird does indeed use HTTPS in some cases. Which is why I noticed this issue :) Which is why I would prefer to have autoconfig.* included in the cert by default. But a note in the docs will also do. Amazing project btw. :)

Syndace picture Syndace on 23 Jun 2019
👍1

Can confirm that the documentation is now more precise, works for me.

Syndace picture Syndace on 23 Jun 2019

What's the motivation behind including autodiscover but leaving out autoconfig?

Braintelligence picture Braintelligence on 23 Jun 2019

It will need HTTPS when a parent domain has HSTS enabled and advertises "includeSubdomains".

andryyy picture andryyy on 23 Jun 2019

we should consider adding it back

andryyy picture andryyy on 23 Jun 2019
👍1

What's the motivation behind including autodiscover but leaving out autoconfig?

My guess would be that autodiscover is supported by most clients, while autoconfig is Thunderbird specific... There was a quite some battle in thunderbird bugzilla about adopting autodiscover in place of their autoconfig system.

edit: found it again.. damn 10 years ago https://bugzilla.mozilla.org/show_bug.cgi?id=521538#c17

sriccio picture sriccio on 23 Jun 2019

we should consider adding it back

I don't know why it was removed at first, maybe to lower the count of SAN's per domain so that the limit of SANs per certificate is not too quickly reached (depending on how many domains you host).

But the solution for SANs limit would better be adressed by creating a single certificate per domain and creating a nginx name virtualhosts per domain.

sriccio picture sriccio on 23 Jun 2019

+1 for supporting open source and open standards

raoulbhatia picture raoulbhatia on 23 Jun 2019
👍1

I'll reopen due to the ongoing discussion, feel free to close it again.

Syndace picture Syndace on 23 Jun 2019

@sriccio Let's encrypt supports wildcard certificates and also multiple domains in one certificate afaik.

Braintelligence picture Braintelligence on 23 Jun 2019

@Braintelligence Wildcards certificates can only be created using DNS validation, not HTTP. It's a pain if the nameservers of the domain aren't your own. Even if they are you must setup a rfc2136 compatible config so that the letsencrypt bot can update dns entries for the domain.

Yes you can have multiple domains per certificate but there's a limit (100 entries per cert).

So if you have for each domain entries like:
autodiscover.domain.tld
autoconfig.domain.tld
your certificate will only hold 50 domains.

edit: not sure you can have multiple wildcards domain in a single cert, never tried to be honest

sriccio picture sriccio on 23 Jun 2019

we should consider adding it back

Yes, we should add that SAN again, now that Thunderbird supports HTTPS.

mkuron picture mkuron on 23 Jun 2019
👍3

@sriccio Many domain providers have an API that you can use for this, you don't necessarily need your own DNS server for that.

https://community.letsencrypt.org/t/dns-providers-who-easily-integrate-with-lets-encrypt-dns-validation/86438

Braintelligence picture Braintelligence on 23 Jun 2019

@Braintelligence True, some domain providers allows it :)

sriccio picture sriccio on 23 Jun 2019

I will not integrate a per-domain autoconfig/autodiscover cert. This is something you can do so much easier with a reverse proxy and all of the plugins for DNS validation you can think of. It is a pita to manage that in mailcow. Much, much less afford to do that externally.

andryyy picture andryyy on 23 Jun 2019
👍2

But the solution for SANs limit would better be adressed by creating a single certificate per domain and creating a nginx name virtualhosts per domain.

See #461

chriscroome picture chriscroome on 23 Jun 2019

I will not integrate a per-domain autoconfig/autodiscover cert.

Just to add the cross-reference: #2509 implements just that. It supposedly works, but adds complexity by proxying connections to Postfix.

Many domain providers have an API that you can use for this

Every provider has their own API specification, so Mailcow can‘t reasonably support them all. This means we‘ll stick to HTTP validation.

mkuron picture mkuron on 23 Jun 2019

Yes, I have seen this, but I don't want to use submission via Dovecot as of today. I really, really appreciate the PR. I just don't want Dovecot to handle it yet. I hope @mhofer117 will not stop updating his PR. :o

andryyy picture andryyy on 23 Jun 2019

Well in my case SAN is not generated ANY certificates for me. I have added a couple of domains already and I've added mail.*,autoconfig.*,autodiscover.* to SAN and nothing happens. The domains were already added to the system when I made changes to the SAN variable, but how do I get it to generate the certificates? Sorry if you feel I'm hijacking the thread.

zietbukuel picture zietbukuel on 26 Jun 2019

Check the updated docs. :)

Did you run up -d and check the acme-mailcow logs?

andryyy picture andryyy on 26 Jun 2019

Yeah I checked this page https://mailcow.github.io/mailcow-dockerized-docs/firststeps-ssl/

And yeah I did that several times. It's only generating it for the main domain.

zietbukuel picture zietbukuel on 26 Jun 2019

I cannot help you at all without logs. :)

andryyy picture andryyy on 26 Jun 2019

Please note that I've changed the domain and IP for security purposes. This is a live installation in a 4GB Ubuntu 18.04 server.

Attaching to mailcowdockerized_acme-mailcow_1
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Waiting for Docker API...OK
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Waiting for database... Uptime: 19068  Threads: 34  Questions: 52182  Slow queries: 0  Opens: 72  Flush tables: 1  Open tables: 60  Queries per second avg: 2.736
acme-mailcow_1       | OK
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Waiting for Nginx... OK
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Waiting for domain table... OK
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Initializing, please wait...
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Using existing domain key /var/lib/acme/acme/key.pem
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Using existing Lets Encrypt account key /var/lib/acme/acme/account.pem
acme-mailcow_1       | Tue Jun 25 19:25:22 -05 2019 - Detecting IP addresses... OK
acme-mailcow_1       | Tue Jun 25 19:25:42 -05 2019 - Found A record for mx.domain.com: 192.168.0.100
acme-mailcow_1       | Tue Jun 25 19:25:42 -05 2019 - Confirmed A record 192.168.0.100
acme-mailcow_1       | Certificate will not expire
acme-mailcow_1       | Tue Jun 25 19:25:42 -05 2019 - Certificate validation done, neither changed nor due for renewal, sleeping for another day.
acme-mailcow_1       | Tue Jun 25 19:25:48 -05 2019 - Waiting for Docker API...OK
acme-mailcow_1       | Tue Jun 25 19:25:48 -05 2019 - Waiting for database... Uptime: 19094  Threads: 34  Questions: 52196  Slow queries: 0  Opens: 72  Flush tables: 1  Open tables: 60  Queries per second avg: 2.733
acme-mailcow_1       | OK
acme-mailcow_1       | Tue Jun 25 19:25:48 -05 2019 - Waiting for Nginx... OK
acme-mailcow_1       | Tue Jun 25 19:25:48 -05 2019 - Waiting for domain table... OK
acme-mailcow_1       | Tue Jun 25 19:25:49 -05 2019 - Initializing, please wait...
acme-mailcow_1       | Tue Jun 25 19:25:49 -05 2019 - Using existing domain key /var/lib/acme/acme/key.pem
acme-mailcow_1       | Tue Jun 25 19:25:49 -05 2019 - Using existing Lets Encrypt account key /var/lib/acme/acme/account.pem
acme-mailcow_1       | Tue Jun 25 19:25:49 -05 2019 - Detecting IP addresses... OK
acme-mailcow_1       | Tue Jun 25 19:26:08 -05 2019 - Found A record for mx.domain.com: 191.168.0.100
acme-mailcow_1       | Tue Jun 25 19:26:08 -05 2019 - Confirmed A record 192.168.0.100
acme-mailcow_1       | Certificate will not expire
acme-mailcow_1       | Tue Jun 25 19:26:08 -05 2019 - Certificate validation done, neither changed nor due for renewal, sleeping for another day.

As you can see, there is nothing about the other domains I've added to mailcow. The only certificate that's being generated is mailcow's domain.

zietbukuel picture zietbukuel on 26 Jun 2019

Are you sure that all DNS records exist? The tool probably skips SANs it can't find records for. But that's just a guess, I'm just a user :D

Syndace picture Syndace on 27 Jun 2019

Ate the domains active and not configured as relay domains?

andryyy picture andryyy on 27 Jun 2019

It seems not to be working on my end....
Tries to, but it receives a 403 on the http check.
Anybody know a simple way to fix this for all my domains without giving errors ?

Getting directory...
Directory found!
Registering account...
Already registered!
Creating new order...
Order created!
Verifying autoconfig.aniradio.org...
Traceback (most recent call last):
  File "/usr/bin/acme-tiny", line 10, in <module>
    sys.exit(main())
  File "/usr/lib/python3.6/site-packages/acme_tiny.py", line 194, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
  File "/usr/lib/python3.6/site-packages/acme_tiny.py", line 150, in get_crt
    raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
ValueError: Challenge did not pass for autoconfig.aniradio.org: {'identifier': {'type': 'dns', 'value': 'autoconfig.aniradio.org'}, 'status': 'invalid', 'expires': '2019-07-04T08:24:37Z', 'challenges': [{'type': 'tls-alpn-01', 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/challenge/su-v92K_7VWBKpc9W_HKSzHENvYbGYcPq271YouBZDA/17571173393', 'token': '9krdEW2ivf-gLYyg7SU16e4a3EYjDZJmXTPQVhBnDZc'}, {'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:unauthorized', 'detail': 'Invalid response from http://autoconfig.aniradio.org/.well-known/acme-challenge/yOqez7gkPSFQP9oKkChavGX0XwseRYRLHAYoy_fnazA [109.72.83.211]: "<?xml version=\\"1.0\\"?><clientConfig version=\\"1.1\\">\\n    <emailProvider id=\\"mx.power2all.com\\">\\n      <domain>%!E(MISSING)MAILDOMAIN%!<(MISSING)/domain>"', 'status': 403}, 'url': 'https://acme-v02.api.letsencrypt.org/acme/challenge/su-v92K_7VWBKpc9W_HKSzHENvYbGYcPq271YouBZDA/17571173394', 'token': 'yOqez7gkPSFQP9oKkChavGX0XwseRYRLHAYoy_fnazA', 'validationRecord': [{'url': 'http://autoconfig.aniradio.org/.well-known/acme-challenge/yOqez7gkPSFQP9oKkChavGX0XwseRYRLHAYoy_fnazA', 'hostname': 'autoconfig.aniradio.org', 'port': '80', 'addressesResolved': ['109.72.83.211'], 'addressUsed': '109.72.83.211'}]}, {'type': 'dns-01', 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/challenge/su-v92K_7VWBKpc9W_HKSzHENvYbGYcPq271YouBZDA/17571173395', 'token': 'Rloaj3zTkPVpjHiYInqIcIKdIXrqqcUQQxRTv1fG1K4'}]}
Thu Jun 27 10:35:38 CEST 2019 - Retrying in 30 minutes...
OK
Power2All picture Power2All on 27 Jun 2019

@andryyy This looks like the problem I had! The invalid response part reminds me of that error.
@Power2All try using my code block from here: https://github.com/mailcow/mailcow-dockerized/issues/2624#issuecomment-504966294 and tell us if it helped please. Don't forget to restart nginx-mailcow before restarting acme-mailcow.

EDIT: @mkuron I can't follow you on the API specifications. They should be abstracted away by the ACME client, it's not like you'd need to incorporate different mechanisms for every DNS provider that exposes an API.
You can also DNS-challenge via a TXT record that you specify on your DNS-server, which is completely API-agnostic; the change to the acme container should be trivial depending on the underlying ACME client.

EDIT2: @sriccio The part about DNS-challenge via a TXT record is also maybe of interest to you. This works with any DNS provider or server.

Braintelligence picture Braintelligence on 27 Jun 2019

@andryyy This looks like the problem I had! The invalid response part reminds me of that error.
@Power2All try using my code block from here: #2624 (comment) and tell us if it helped please. Don't forget to restart nginx-mailcow before restarting acme-mailcow.

Thanks.
I used the following in the existing block:

server {
  listen 80;
  listen [::]:80;
  server_name autoconfig.*;
  root /web;
  location / {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass phpfpm:9002;
    include /etc/nginx/fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root/autoconfig.php;
    try_files /autoconfig.php =404;
  }

  location ^~ ./well-known/acme-challenge/ {
    allow all;
    default_type "text/plain";
  }
}
Power2All picture Power2All on 27 Jun 2019

@Power2All Oh, you still had that block in there... Damn. Look at the documentation; you actually shouldn't use that block anymore at all.
I thought you didn't have it and ran into problems getting your certificate =/...

Braintelligence picture Braintelligence on 27 Jun 2019

@Power2All Oh, you still had that block in there... Damn. Look at the documentation; you actually shouldn't use that block anymore at all.
I thought you didn't have it and ran into problems getting your certificate =/...

Oh, nice to know...
Thanks for pointing it out.

UPDATE: It works 💃

Power2All picture Power2All on 27 Jun 2019

Did it work without the entire block or did you have to use my version?

Braintelligence picture Braintelligence on 27 Jun 2019

Did it work without the entire block or did you have to use my version?

I just removed the php-fpm part.
Since it was overriding your location block anyway.

Power2All picture Power2All on 27 Jun 2019

So you basically used my version but didn't try removing the block entirely before getting the cert?

Braintelligence picture Braintelligence on 27 Jun 2019

So you basically used my version but didn't try removing the block entirely before getting the cert?

That is correct.

Power2All picture Power2All on 27 Jun 2019
👀1

After the last update, ACME reports the following error and does not finish the certificate renewal. Don't you know what to do with it?

`
Thu Jun 27 15:48:09 CEST 2019 - Waiting for Docker API...OK
Thu Jun 27 15:48:11 CEST 2019 - Waiting for database... Uptime: 2 Threads: 12 Questions: 65 Slow queries: 0 Opens: 38 Flush tables: 1 Open tables: 30 Queries per second avg: 32.500
OK
Thu Jun 27 15:48:19 CEST 2019 - Waiting for Nginx... OK
Thu Jun 27 15:48:19 CEST 2019 - Waiting for domain table... OK
Thu Jun 27 15:48:19 CEST 2019 - Initializing, please wait...
Thu Jun 27 15:48:19 CEST 2019 - Using existing domain key /var/lib/acme/acme/key.pem
Thu Jun 27 15:48:19 CEST 2019 - Using existing Lets Encrypt account key /var/lib/acme/acme/account.pem
Thu Jun 27 15:48:19 CEST 2019 - Detecting IP addresses... OK
Thu Jun 27 15:48:47 CEST 2019 - Found A record for imap.affari-crm.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for smtp.affari-crm.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for autoconfig.affari-crm.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for autodiscover.affari-crm.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for autoconfig.affari-crm.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for imap.agentes-it.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for smtp.agentes-it.com: 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:47 CEST 2019 - Found A record for autoconfig.agentes-it.com: 94.130.136.31
Thu Jun 27 15:48:48 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:48 CEST 2019 - Found A record for autodiscover.agentes-it.com: 94.130.136.31
Thu Jun 27 15:48:48 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:48 CEST 2019 - Found A record for autoconfig.agentes-it.com: 94.130.136.31
Thu Jun 27 15:48:48 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:49 CEST 2019 - Found A record for imap.akvachta.cz: 94.130.136.31
Thu Jun 27 15:48:49 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:49 CEST 2019 - Found A record for smtp.akvachta.cz: 94.130.136.31
Thu Jun 27 15:48:49 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:50 CEST 2019 - Found A record for autoconfig.akvachta.cz: 94.130.136.31
Thu Jun 27 15:48:50 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:50 CEST 2019 - Found A record for autodiscover.akvachta.cz: 94.130.136.31
Thu Jun 27 15:48:50 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:50 CEST 2019 - Found A record for autoconfig.akvachta.cz: 94.130.136.31
Thu Jun 27 15:48:50 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:51 CEST 2019 - No A or AAAA record found for hostname imap.klic-k-fakture.cz
Thu Jun 27 15:48:51 CEST 2019 - No A or AAAA record found for hostname smtp.klic-k-fakture.cz
Thu Jun 27 15:48:51 CEST 2019 - Found A record for autoconfig.klic-k-fakture.cz: 94.130.136.31
Thu Jun 27 15:48:52 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:52 CEST 2019 - Found A record for autodiscover.klic-k-fakture.cz: 94.130.136.31
Thu Jun 27 15:48:52 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:52 CEST 2019 - Found A record for autoconfig.klic-k-fakture.cz: 94.130.136.31
Thu Jun 27 15:48:52 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - No A or AAAA record found for hostname imap.wet-wipes-international.com
Thu Jun 27 15:48:54 CEST 2019 - No A or AAAA record found for hostname smtp.wet-wipes-international.com
Thu Jun 27 15:48:54 CEST 2019 - Found A record for autoconfig.wet-wipes-international.com: 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - Found A record for autodiscover.wet-wipes-international.com: 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - Found A record for autoconfig.wet-wipes-international.com: 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:54 CEST 2019 - No A or AAAA record found for hostname imap.wet-wipes-international.de
Thu Jun 27 15:48:54 CEST 2019 - No A or AAAA record found for hostname smtp.wet-wipes-international.de
Thu Jun 27 15:48:54 CEST 2019 - Found A record for autoconfig.wet-wipes-international.de: 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Found A record for autodiscover.wet-wipes-international.de: 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Found A record for autoconfig.wet-wipes-international.de: 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Found A record for mailadmin.agentes-it.com: 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Confirmed A record 94.130.136.31
Thu Jun 27 15:48:56 CEST 2019 - Found new SANs autoconfig.affari-crm.com autoconfig.agentes-it.com autoconfig.akvachta.cz autoconfig.klic-k-fakture.cz autoconfig.wet-wipes-international.com autoconfig.wet-wipes-international.de
Thu Jun 27 15:48:56 CEST 2019 - Creating backups in /var/lib/acme/backups/2019-06-27_15_48_56/ ...
Parsing account key...
Parsing CSR...
Found domains: mailadmin.agentes-it.com, autoconfig.agentes-it.com, autoconfig.wet-wipes-international.de, imap.agentes-it.com, smtp.akvachta.cz, autodiscover.affari-crm.com, autoconfig.klic-k-fakture.cz, autoconfig.akvachta.cz, autodiscover.akvachta.cz, autodiscover.wet-wipes-international.com, autodiscover.wet-wipes-international.de, imap.affari-crm.com, smtp.affari-crm.com, autodiscover.agentes-it.com, smtp.agentes-it.com, autodiscover.klic-k-fakture.cz, imap.akvachta.cz, autoconfig.affari-crm.com, autoconfig.wet-wipes-international.com
Getting directory...
Directory found!
Registering account...
Already registered!
Creating new order...
Order created!
Verifying autoconfig.affari-crm.com...
Traceback (most recent call last):
File "/usr/bin/acme-tiny", line 10, in
sys.exit(main())
File "/usr/lib/python3.6/site-packages/acme_tiny.py", line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
File "/usr/lib/python3.6/site-packages/acme_tiny.py", line 150, in get_crt
raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
ValueError: Challenge did not pass for autoconfig.affari-crm.com: {'identifier': {'type': 'dns', 'value': 'autoconfig.affari-crm.com'}, 'status': 'invalid', 'expires': '2019-07-04T13:46:21Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:unauthorized', 'detail': 'Invalid response from http://autoconfig.affari-crm.com/.well-known/acme-challenge/SSW8VsjmQI3Wl50S4uggpYZkKNagE43A9-aQWX_B7Z8 [94.130.136.31]: "\n \n %!E(MISSING)MAILDOMAIN%!<(MISSING)"', 'status': 403}, 'url': 'https://acme-v02.api.letsencrypt.org/acme/challenge/PBFyoSHbFXT14311_pHNjDiTlFJ0fmVU4BVs0oyixWA/17579872858', 'token': 'SSW8VsjmQI3Wl50S4uggpYZkKNagE43A9-aQWX_B7Z8', 'validationRecord': [{'url': 'http://autoconfig.affari-crm.com/.well-known/acme-challenge/SSW8VsjmQI3Wl50S4uggpYZkKNagE43A9-aQWX_B7Z8', 'hostname': 'autoconfig.affari-crm.com', 'port': '80', 'addressesResolved': ['94.130.136.31'], 'addressUsed': '94.130.136.31'}]}, {'type': 'tls-alpn-01', 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/challenge/PBFyoSHbFXT14311_pHNjDiTlFJ0fmVU4BVs0oyixWA/17579872859', 'token': 'rc9u1f9--buKc4F4WB46RwEYOaWZFIZ_6rujxG704rY'}, {'type': 'dns-01', 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/challenge/PBFyoSHbFXT14311_pHNjDiTlFJ0fmVU4BVs0oyixWA/17579872860', 'token': 'Gdw5LH5AQHhLNXJ99NPXFli1e8A0ILDNwFNV3wzVw78'}]}
Thu Jun 27 15:49:05 CEST 2019 - Retrying in 30 minutes...
OK

`

GlowManCZ picture GlowManCZ on 27 Jun 2019

@GlowManCZ Did you actually read some of the newest comments? Power2All had the exact same problem and solved it: https://github.com/mailcow/mailcow-dockerized/issues/2722#issuecomment-506252713

Braintelligence picture Braintelligence on 27 Jun 2019

This has nothing to do with the original issue, could you please stop posting your own issues here, I don't want to get spammed with notifications that have nothing to do with my post.

Syndace picture Syndace on 27 Jun 2019
👍3

This has nothing to do with the original issue, could you please stop posting your own issues here, I don't want to get spammed with notifications that have nothing to do with my post.

His issue has got to do with the autoconfig LetsEncrypt ACME system.
It's basically what this whole post is about.
However, @Syndace could have looked at the last few posts as @Braintelligence remarked, that his solution is there.
It's kind of weird why he did post his whole issue, when he only could have posted the bit where it says "nope" ....

Power2All picture Power2All on 27 Jun 2019

The post is about autoconfig.* not being part of the cert, this is not a general "something acme is not working" thread.

Syndace picture Syndace on 27 Jun 2019
👍1

@Syndace
To make this short: You asked to either incorporate autoconfig by default again or change the docs.
The docs were changed as you can see here: https://github.com/mailcow/mailcow-dockerized-docs/commit/2c89d6ed40758f256a089868b7036d9065d5b2b4
The HTTP -> HTTPS redirect block was also changed.

Thus your issue is resolved and this ticket is closed, so it won't be derailed any further.
@andryyy Feel free to reopen if you want to keep it as a reminder to perhaps reconsider taking autoconfig in by default.

Braintelligence picture Braintelligence on 27 Jun 2019

Thus your issue is resolved

Absolutely correct! I already closed the issue when I saw the documentation update and only just reopened it, when discussion about reconsidering autoconfig.* started.

The consus is (as far as I understood), to add autoconfig.* to the cert again, which is why the issue received the "enhancement" label and why the issue should not be closed yet. If the discussion derails too much, you can "lock" the conversation on GitHub IIRC.

Syndace picture Syndace on 27 Jun 2019

@Syndace Yup. I only considered @andryyy when closing it, but @mkuron wanted to keep it as a reminder. Thanks for bringing it up 😸.
Let's leave it as a reminder and discussion about if/how autoconfig should be added as default SAN then. 😺.

Braintelligence picture Braintelligence on 1 Jul 2019
👍1

it's not like you'd need to incorporate different mechanisms for every DNS provider that exposes an API

There is no standard way to manage DNS records via an API. ACME DNS validation requires the dynamic creation and deletion of TXT records So the Acme client would need to come with wrapper scripts for potentially hundreds of DNS providers' APIs.

if/how autoconfig should be added as default SAN then

Wasn't that already done a few days ago?

mkuron picture mkuron on 1 Jul 2019

Is it dynamic creation though? I thought the TXT records stays the same forever (just like the DNS verification for Google domains). Sure, you'd have to input that, but only once afaik.
You have to touch DNS records when you setup Mailcow anyway.

Was autoconfig added as default San? Do you have a commit available? I'm on the go currently.

Braintelligence picture Braintelligence on 1 Jul 2019

The documentation was updated and now states that the acme-container will automatically try and add autoconfig.* to the SANs. I think this commit is where the container is updated. So yes, looks like autoconfig.* is now automatic again, thank you all!

From my point this issue is fixed now but I'll leave it open for the TXT/DNS record discussion.

Syndace picture Syndace on 1 Jul 2019
👍1

I just checked. It seems that the TXT record in question is indeed different for each renewal. I wonder what the motivation was behind this decision.
Well, I've read that there are workarounds by providing your own DNS (if even only temporarily) but it's not like we depend on this. Too much work for a problem that's not a problem yet IMHO. Right?

Braintelligence picture Braintelligence on 1 Jul 2019

Just a heads up for @andryyy and all others which may encounter a similar problem:
I've been using a CNAME for autodiscover and autoconfig forever (at least a year) and since those subdomains are now added to the cert SAN list automagically, mailcow was unable to renew my certs since it was trying to add a cert for autodiscover and autoconfig. The reason was the missing A records (lookup and ping was still fine thanks to the CNAME). Took me some time to figure this out even though the acme client message is quite clear actually :-)

trick77 picture trick77 on 2 Aug 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

CrAazZyMaN21 picture CrAazZyMaN21  Â·  3Comments
RogerSik picture RogerSik  Â·  3Comments
lgleim picture lgleim  Â·  3Comments
Braintelligence picture Braintelligence  Â·  3Comments
pgollor picture pgollor  Â·  3Comments