when I want to provision a cert for my mail-in-a-box-server, I get the following message: „Something unexpected went wrong: The HTTP Validation challenge for mydomain.de failed: Could not connect to mydomain.de.“
Ich checked manually, if it is possible to call „http://mydomain.de/.well-known/acme-challenge/
Result: Yes, it’s possible. I get a 200 and can download the file. I also tried to call this URL via „wget“ on the mail-server, which is also possible (no errors).
In the next step, I figured out which file is responsible for the provision-process. It’s „https://github.com/mail-in-a-box/mailinabox/blob/master/management/ssl_certificates.py“. So I tried to debuy this script with simple „print“-commands (i’m not an expert in python-coding).
I was ableo to find out, that the call of „client.issue_certificate(…“ is responsible for this error (line 345). The needed files are created in the „/home/user-data/ssl/lets_encrypt/acme_challenges“-directory. They are callable through „http“, but „client.issue_certificate“ is not able to do this.
Does anybod know how I can fix this?
I have a second mail-in-a-box-Server which runs without a problem.
When I run “management/ssl_certificates.py -v box.mydomain.de” I get the following error:
> The HTTP Validation challenge for box.mydomain.de failed: Could not connect to box.mydomain.de. box.mydomain.de: Something unexpected went wrong: The HTTP Validation challenge for box.mydomain.de failed: Could not connect to box.mydomain.de. Exception ignored in: <bound method ClientNetwork.__del__ of <acme.client.ClientNetwork object at 0x7f721afbb898>> Traceback (most recent call last): File "/usr/local/lib/python3.4/dist-packages/acme/client.py", line 522, in __del__ self.session.close() File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 701, in close for v in self.adapters.values(): File "/usr/lib/python3.4/_collections_abc.py", line 512, in __iter__ for key in self._mapping: File "/usr/lib/python3.4/collections/__init__.py", line 91, in __iter__ curr = root.next ReferenceError: weakly-referenced object no longer exists
When I call the “management/ssl_certificates.py -v box.mydomain.de”-command I get in my access-File these two lines: m.y.i.p - - [15/Jun/2017:10:38:26 +0200] "GET /.well-known/acme-challenge/fE5Ucpn95x5FXoJ1kOwY5YSGAlwpR7Aa7L7-oJGhvco HTTP/1.1" 404 136 "-" "python-requests/2.18.1" m.y.i.p - - [15/Jun/2017:10:38:27 +0200] "GET /.well-known/acme-challenge/fE5Ucpn95x5FXoJ1kOwY5YSGAlwpR7Aa7L7-oJGhvco HTTP/1.1" 200 87 "-" "python-requests/2.18.1"
I was not able to figure out why there is a “404” in first place and short after a “200”. Obviously the script takes the first (404) request as a result.
I have no idea why there are two requests and one of them is a 404.
Looking in my access.log file I realize I have the same problem. If I provision manually (with the button) I get a “could not connect to” error and looking in the logs I see three 404’s immedeately followed by 3 200’s for the 3 domains that it tries to provision for.
Frankly I do not get how this is supposed to work; where do these challenge files reside on the system? Where is the directory /.well-known/acme_challenge? The closest I can find is a directory /home/user-data/ssl/lets_encrypt/acme_challenges/ that does contain the right files, but how they end up being available to the webserver, I have no idea. I really hope someone with more insight in this can explain that to me
It looks like that mail-in-a-box creates a nginx-config file, which is stored in “/etc/nginx/conf.d/local.conf” (the template file for the “local.conf” is amongst other things “~/mailinabox/conf/nginx.con” but I do not know in which step the local.conf is written. But I also think that this template-file is not very important to our problem.)
When you open the “local.conf” you should see for every domain a “server”-block, which starts with “server {” and ends with a “}”. This “server”-block contains the following sub-block: location /.well-known/acme-challenge/ { # This path must be served over HTTP for ACME domain validation. # We map this to a special path where our TLS cert provisioning # tool knows to store challenge response files. alias /home/user-data/ssl/lets_encrypt/acme_challenges/; }
So when the request is “/.well-known/acme-challenge/” it gets redirected to “/home/user-data/ssl/lets_encrypt/acme_challenges/”.
And this is the point where it gets confused: The requested file (which is a hash?!) is in this directory, but it in the first step nginx is not able to find it.
I removed all IPv6 DNS-Records because I thought, that this python-Lib grabs the acme-challenge over IPv6 in a wrong way. But after removing the DNS-Records (waiting a few hours) and running “curl -s https://mailinabox.email/setup.sh | sudo bash” again, the problem wasn’t solved.
I’m not sure if i have to reconfigure something in my MIAB to disable IPv6 completely.
I start to be convinced that this has everything to do with the fact that I have an AAAA record for my box in the dns, while the box is not reachable at that address due to a router problem.
I came upon a discussion about letsencrypt
That more or less exactly describes what I see happen in my box. In the .json file I see that AddressUsed shows my ipv6 address, while AddressesTried is empty.
I will look into this further tomorrow. maybe disable IPv6 on my box, if I can figure out how…
Thanks a lot! With this hint, I was able to solve my problem. With “http://ipv6-test.com/validate.php” i checked my box.mydomain.de and got the information that there was still a AAAA-Record for a ipv6-address (“box AAAA my:ip:v6:add:ress::2”). This address belongs to my vhost, but the vhost was not correctly configured.
Now, my “/etc/network/interfaces” looks like this: # Loopback device: auto lo iface lo inet loopback iface lo inet6 loopback
# device: eth0 - ipv6 (this part was missing) iface eth0 inet6 static address my:ip:v6:add:ress::2 netmask 64 gateway fe80::1
After restarting my machine, the result from “http://ipv6-test.com/validate.php” was okay. So I executed “management/ssl_certificates.py -v box.mydomain.de” and the ssl-certificate was created.
The only thing which is still not so nice, is the fact, that there is still an error:
A TLS certificate was successfully installed for box.mydomain.de. Exception ignored in: <bound method ClientNetwork.__del__ of <acme.client.ClientNetwork object at 0x7f3861954940>> Traceback (most recent call last): File "/usr/local/lib/python3.4/dist-packages/acme/client.py", line 522, in __del__ self.session.close() File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 701, in close for v in self.adapters.values(): File "/usr/lib/python3.4/_collections_abc.py", line 512, in __iter__ for key in self._mapping: File "/usr/lib/python3.4/collections/__init__.py", line 91, in __iter__ curr = root.next ReferenceError: weakly-referenced object no longer exists
It appears after the “A TLS certificate was successfully installed for box.mydomain.de.”-messages and it looks like problem with a session in python. I will check this again in three month, when I have to renew my certificates again. Because the provisioning-task was successful, it doesn’t bother me for now.
As it is quite complex to get IPv6 working over a Fritz!box with a PFsense router behind it I think the quickest way for me is to disable ipV6. Although that has its own difficulties.
After a couple of fruitless attempts to make MIAB use only IPv4 I got back to work on the PFsense firewall. And lo and behold, I managed to make it work. Got the OK from “http://ipv6-test.com/validate.php” on my box, re-provisioned the certificates from the MIAB GUI and voila, new certificates were renewed! So the next three months look sunny. I think I’ll go on vacation
I have to damit, that your configuration is not a “everybody-configuration”, but it’s good to read, that your problem is solved, too. Have a nice weekend and enjoy your secure and trustable MIAB.
