nginx-proxy / acme-companion

Automated ACME SSL certificate generation for nginx-proxy
MIT License
7.42k stars 824 forks source link

Cert renewals fail when nginx proxy runs in network mode "host" #600

Open DatAres37 opened 4 years ago

DatAres37 commented 4 years ago

Hi, I hope someone can point me to the right direction to fix this issue. The automatic renewal doesn't work for me, because I'm running jwilders nginx proxy in network mode "host". I have to do this, because the proxy fails to forward real user IPs without it.

The whole error message is:

ERROR:simp_le:1396: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/1622245421, https://acme-v02.api.letsencrypt.org/acme/authz-v3/1622245422
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1370, in finalize_order
    finalized_order = client.poll_and_finalize(order)
  File "/usr/lib/python3.7/site-packages/acme/client.py", line 712, in poll_and_finalize
    orderr = self.poll_authorizations(orderr, deadline)
  File "/usr/lib/python3.7/site-packages/acme/client.py", line 736, in poll_authorizations
    raise errors.ValidationError(failed)
acme.errors.ValidationError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1443, in persist_new_data
    order = finalize_order(client, order)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1397, in finalize_order
    raise Error('Challenge validation has failed, see error log.')
simp_le.Error: Challenge validation has failed, see error log.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1565, in main
    return main_with_exceptions(cli_args)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1549, in main_with_exceptions
    persist_new_data(args, existing_data)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1464, in persist_new_data
    chain=None,
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1128, in persist_data
    plugin.save(new_data)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 557, in save
    key = self.dump_key(data.key)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 455, in dump_key
    return OpenSSL.crypto.dump_privatekey(self.typ, data.wrapped).strip()
AttributeError: 'NoneType' object has no attribute 'wrapped'

Unhandled error has happened, traceback is above

Each time I want to renew the certificates, I have to recreate the container with the default network options. Is there a way to fix this? Running the companion in network mode "host" didn't.

buchdag commented 4 years ago

Hi.

You've probably already heard about X-Real-IP, X-Forwarded-For headers and the ngx_http_realip_module module. This is only correct way of handling nginx-proxy's real IP issue that I'm aware of.

I don't think nginx-proxy was ever really meant to handle container on host network mode.

DatAres37 commented 4 years ago

Hi.

You've probably already heard about X-Real-IP, X-Forwarded-For headers and the ngx_http_realip_module module. This is only correct way of handling nginx-proxy's real IP issue that I'm aware of.

I don't think nginx-proxy was ever really meant to handle container on host network mode.

I already tried that, but it doesn't work for me. The problem is that the nginx container doesn't even receive the correct public IPs, so it also can't forward the right IP.

Dav1dK commented 4 years ago

I experience the same issue. For me, the problem is Dockers poor IPv6 support. I only get a public IPv6 address. But I am unable to pass the real IP with HTTP headers for IPv6 connections. Therefore I need to run nginx in host network mode. I got docker-letsencrypt-nginx-proxy-companion working some time ago, but apparently, an update broke it.

buchdag commented 4 years ago

@DatAres37 after a bit more research, this appears to be a known issue with Docker : https://github.com/moby/moby/issues/15086

Sadly it seems this issue has been there for a long time and a fix is nowhere in sight.

I'll try to get a shot at the host network mode if I get a bit of free time but I can't promise anything.

dmp1ce commented 4 years ago

I am getting the same errors. For some reason an update broke my configuration as soon as my certificate needed to be renewed.

I do not have IPv6 and I am not running in host network mode. I'm not sure how to resolve the issue for myself.

EDIT:

For me, my companion container wasn't getting the same volume from nginx-proxy container which it should have with the --volumes-from. I have no idea why. I stopped and removed the companion container and restarted it. This solved my issue and certificate was renewed!

So, it seems, this error will result if the .well-known directory is available to the Let's Encrypt service.