Dry-run works but real run doesn't

[Hans1]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
portal.ihr-potential.de
portal.viaem.de

I ran this command:
sudo docker-compose run --rm certbot certonly --standalone --cert-name portal.ihr-potential.de -d portal.ihr-potential.de --preferred-challenges http -m xxxxxx@ihr-potential.de --agree-tos

It produced this output:
Failed authorization procedure. portal.ihr-potential.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://portal.ihr-potential.de/.well-known/acme-challenge/H43LBo_wKbxiCTrwIoxY3owzazLVIQVTUrpxFkvdwfs: Connection refused

My web server is (include version):
usually: docker nginx:latest; But for the command I stopped the nginx container and only started certbot

The operating system my web server runs on is (include version):
usually debian
My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):
yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

If I add a --dry-run to the command above, it runs without any problem.
The output of certbot certificates is:
Found the following certs:
Certificate Name: portal.ihr-potential.de
Domains: portal.ihr-potential.de portal.viaem.de
Expiry Date: 2018-03-19 20:40:36+00:00 (VALID: 24 days)
Certificate Path: /etc/letsencrypt/live/portal.ihr-potential.de/fullchain.pem
Private Key Path: /etc/letsencrypt/live/portal.ihr-potential.de/privkey.pem
Certificate Name: portal.viaem.de
Domains: portal.viaem.de
Expiry Date: 2018-03-18 21:59:14+00:00 (VALID: 23 days)
Certificate Path: /etc/letsencrypt/live/portal.viaem.de/fullchain.pem
Private Key Path: /etc/letsencrypt/live/portal.viaem.de/privkey.pem
It was not my intention to have two domains in the first certificate. I’m afraid I messed up something. Does anyone have an idea?

[schoen]

@Hans1

But for the command I stopped the nginx container and only started certbot

Hallo @Hans1,

In this case I think there is probably a difficulty with the container configuration that results in the publicly-visible port 80 not being routed to the Certbot container. In the past --standalone used port 443 rather than port 80 (indeed, your --dry-run tests possibly might still be using port 443 for some subtle reasons, though not necessarily) and so recipes and tutorials for using Docker with Certbot may have said that the container only needed port 443. According to current practice (newly as of just 1-2 months ago), the Certbot container will need port 80.

So, you should make sure that any firewall rules and container configurations allow the public to reach that container on port 80.

@Hans1

It was not my intention to have two domains in the first certificate. I’m afraid I messed up something. Does anyone have an idea?

This would be due to a previous run of Certbot mentioning both names on the command line. However, your use of --cert-name should fix this and establish the setup that you intended, as soon as the other problems are resolved and the command that you showed above completes successfully.

[Hans1]

Hi schoen
thanks for the hint. That could really be the reason. I used a reverse proxy but only proxied .well-known/acme-challenge on port 443.
In the mean time I backuped /etc/letsencrypt and deleted it and started all over again. It seems to work now.
I use http and probably have to stick to this if I understand you correctly.
I probably have to delete my old account. I have some trouble with the manual in this point.
I probably have to revoke the old certificates or just wait a couple of days until they are out of date anyway. And then it probably should be something like:
certbot unregister --account ACCOUNT_ID
Thanks
Hans

[schoen]

It’s not necessarily necessary to invalidate old accounts or certificates. In many cases you can simply delete your own copies of the associated keys, if there’s no reason to believe that those keys have been compromised.