SteveLTN / https-portal

A fully automated HTTPS server powered by Nginx, Let's Encrypt and Docker.
MIT License
4.41k stars 295 forks source link

acme_tiny valueError in docker #223

Open jaromrax opened 4 years ago

jaromrax commented 4 years ago

Hi, I managed to run httpsportal in docker recently, it was fantastic. However, now I cannot get it working.

I tried to change the `DOMAINS: '--------.cz -> http://dockerhost:8000, zato.---------.cz -> http://dockerhost:8001'

to

`DOMAINS: 'www.--------.cz -> http://dockerhost:8000, zato.---------.cz -> http://dockerhost:8001, grafana.-------------.cz -> http://dockerhost:3000'

And now it remembers one certificate, Signing skipped for zato.----------.cz, it expires at 75 days from now., but the others.... (www, grafana) generate errors:

Signing certificates from https://acme-v02.api.letsencrypt.org/directory ...
httpsportal     | Parsing account key...
httpsportal     | Parsing CSR...
httpsportal     | Found domains: www.------------.cz
httpsportal     | Getting directory...
httpsportal     | ================================================================================
httpsportal     | Failed to sign www.-----------.cz, is DNS set up properly?
httpsportal     | ================================================================================
httpsportal     | Failed to obtain certs for www.------------.cz

later I get this error.

Traceback (most recent call last):
httpsportal     |   File "/bin/acme_tiny", line 198, in <module>
httpsportal     |     main(sys.argv[1:])
httpsportal     |   File "/bin/acme_tiny", line 194, in main
httpsportal     |     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)
httpsportal     |   File "/bin/acme_tiny", line 106, in get_crt
httpsportal     |     directory, _, _ = _do_request(directory_url, err_msg="Error getting directory")
httpsportal     |   File "/bin/acme_tiny", line 46, in _do_request
httpsportal     |     raise ValueError("{0}:\nUrl: {1}\nData: {2}\nResponse Code: {3}\nResponse: {4}".format(err_msg, url, data, code, resp_data))
httpsportal     | ValueError: Error getting directory:
httpsportal     | Url: https://acme-v02.api.letsencrypt.org/directory
httpsportal     | Data: None
httpsportal     | Response Code: None
httpsportal     | Response: <urlopen error [Errno 99] Cannot assign requested address>

Should I delete all certificates and start over? I played with ufw, with DNS setting (I removed CNAME line). I use the last docker tag. thanks for help Jaromir

SteveLTN commented 4 years ago

First, do another pull so you get the latest image.

Then check your DNS settings. Make sure all of them are still correct.

Finally, make sure your port 80 of the host machine are open.

Good luck!

On Thu, 27 Feb 2020 at 4:23 PM jaromrax notifications@github.com wrote:

Hi, I managed to run httpsportal in docker recently, it was fantastic. However, now I cannot get it working.

I tried to change the `DOMAINS: '--------.cz -> http://dockerhost:8000, zato.---------.cz -> http://dockerhost:8001'

to

`DOMAINS: 'www.--------.cz -> http://dockerhost:8000, zato.---------.cz -> http://dockerhost:8001, grafana.-------------.cz -> http://dockerhost:3000'

And now it remembers one certificate, Signing skipped for zato.----------.cz, it expires at 75 days from now., but the others.... (www, grafana) generate errors:

Signing certificates from https://acme-v02.api.letsencrypt.org/directory ... httpsportal | Parsing account key... httpsportal | Parsing CSR... httpsportal | Found domains: www.------------.cz httpsportal | Getting directory... httpsportal | ================================================================================ httpsportal | Failed to sign www.-----------.cz, is DNS set up properly? httpsportal | ================================================================================ httpsportal | Failed to obtain certs for www.------------.cz

later I get this error.

Traceback (most recent call last): httpsportal | File "/bin/acme_tiny", line 198, in httpsportal | main(sys.argv[1:]) httpsportal | File "/bin/acme_tiny", line 194, in main httpsportal | 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) httpsportal | File "/bin/acme_tiny", line 106, in getcrt httpsportal | directory, , _ = _do_request(directory_url, err_msg="Error getting directory") httpsportal | File "/bin/acme_tiny", line 46, in _do_request httpsportal | raise ValueError("{0}:\nUrl: {1}\nData: {2}\nResponse Code: {3}\nResponse: {4}".format(err_msg, url, data, code, resp_data)) httpsportal | ValueError: Error getting directory: httpsportal | Url: https://acme-v02.api.letsencrypt.org/directory httpsportal | Data: None httpsportal | Response Code: None httpsportal | Response: <urlopen error [Errno 99] Cannot assign requested address>

Should I delete all certificates and start over? I played with ufw, with DNS setting (I removed CNAME line). I use the last docker tag. thanks for help Jaromir

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SteveLTN/https-portal/issues/223?email_source=notifications&email_token=AAD4AZ7CUXT2HP3H64PRJKLRE7LH5A5CNFSM4K45H4MKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IQ2MJSQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD4AZ777MUNCJLSEBHYNQ3RE7LH5ANCNFSM4K45H4MA .

jaromrax commented 4 years ago

Thank you for your help.

1/ I deleted containers and images and started from scratch. With this docker-compose_staging_certs.yml

version: '3'
services:
  https-portal:
    image: steveltn/https-portal:latest
    container_name: httpsportal
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - /data/ssl_certs:/var/lib/https-portal
    environment:
      DOMAINS: 'www.-------.cz -> http://dockerhost:8000'
      STAGE: 'staging'
      # STAGE: 'local'
      # STAGE: 'production'

I get SSL Error when I open links for 127.0.0.1 or for www.----.cz. Also on remote computer.

I do ufw allow from 172.25.0.2 to 172.25.0.1 port 8000 that is based on your advices, but no help.

I tried to run simple server on ports 80 and 443 and I can see the correct responses from remote pc (with links www.----.cz:443) == firewall is OK.

I have found, that :latest is not the same files as :1, but it idnt solve te situation.

RESUME:

It works for STAGE:local from remote pc. I have no idea, maybe I have crossed the limits for letsencrypt in the meantime, maybe I have bad DNS settings (only A records to IP). Thanks for the help.

ofthesun9 commented 4 years ago

I had a similar issue today, with same error for 1 domain (the other ones aren't expired yet) httpsportal | Failed to sign xx.yyy.net, is DNS set up properly? the declaration for xx.yyy.net domain was the first item in the DOMAINS: '......' in the docker-compose.yml. I put the declaration at the end, and the verification was then successful....

Maybe the order in DOMAINS: does matter ?

SteveLTN commented 4 years ago

Could you paste before and after docket-compose? Thanks!

On Wed, 11 Mar 2020 at 11:34 PM ofthesun9 notifications@github.com wrote:

I had a similar issue today, with same error for 1 domain (the other ones aren't expired yet) httpsportal | Failed to sign xx.yyy.net, is DNS set up properly? the declaration for xx.yyy.net domain was the first item in the DOMAINS: '......' in the docker-compose.yml. I put the declaration at the end, and the verification was then successful....

Maybe the order in DOMAINS: does matter ?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/SteveLTN/https-portal/issues/223#issuecomment-597913417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD4AZ3CABUUXV35UMASUYTRHAGVRANCNFSM4K45H4MA .

ofthesun9 commented 4 years ago

before:

version: '3.2'
services:
  https-portal:
    image: steveltn/https-portal:1
    ports:
      - '80:80'
      - '443:443'
    restart: unless-stopped
    environment:
      DOMAINS: 'srv.ofthesun.net -> http://tautulli:8181, mail.ofthesun.net -> http://front, portainer.ofthesun.net -> http://portainer:9000, blog.ofthesun.net -> http://wordpress-app-lol, ofthesun.net => blog.ofthesun.net, www.ofthesun.net => blog.ofthesun.net, nextcloud.ofthesun.net -> http://nextcloud-app, www.mirguettes.fr => mirguettes.fr, mirguettes.fr -> http://wordpress-app-sof'

After:

version: '3.2'
services:
  https-portal:
    image: steveltn/https-portal:1
    ports:
      - '80:80'
      - '443:443'
    restart: unless-stopped
    environment:
      DOMAINS: 'mail.ofthesun.net -> http://front, portainer.ofthesun.net -> http://portainer:9000, blog.ofthesun.net -> http://wordpress-app-lol, ofthesun.net => blog.ofthesun.net, www.ofthesun.net => blog.ofthesun.net, nextcloud.ofthesun.net -> http://nextcloud-app, www.mirguettes.fr => mirguettes.fr, mirguettes.fr -> http://wordpress-app-sof, srv.ofthesun.net -> http://tautulli:8181'
SteveLTN commented 4 years ago

@ofthesun9 I tried with your configuration. The parsed domain list was correct, there were not difference in terms of the domain names we get. That's hard to explain who changing the order would make things different. Is it possible that the DNS weren't fully populated when you tried the first time? If you go back to before, could you reproduce the problem?

ofthesun9 commented 4 years ago

Yes it is probable that DNS were still propagating some DNS changes when I encountered the error. I have hit some limit at Let's encrypt, so I will not be able to try to reproduce very soon....

nakazonot commented 4 years ago

I have a similar problem. The certificate was actually created, so it worked by manually continuing the following process.

https://github.com/SteveLTN/https-portal/blob/273ed46185e4acfa6beb21719b284752aaa22cb3/fs_overlay/opt/certs_manager/certs_manager.rb#L59

edisinovcic commented 4 years ago

Is this working with latest changes? I'm getting the same error on multiple domains...

SteveLTN commented 4 years ago

@edisinovcic Yes. First check if your DNS is propagated. DNS being not ready is the most common issue.

edisinovcic commented 4 years ago

It was a DNS issue in the end, propagation took much more than usual. Tnx