Lingering unsigned certificates on error

[carukc]

Hello,

Thank you for the script! It's very useful!

I have a quick question regarding failed signing attempts.

Perhaps we are doing something wrong but if we mess up for some reason (like forgetting to set the external DNS) then the script leaves a set of unsigned certificates behind. This seems to leave the site inaccessible due to HSTS errors.

Should the script be cleaning up after itself if it failed to get a signed certificate... or perhaps it should be trying to get a signature again in some automated way?

We don't mind doing a little work on the script to enhance the way it works but do not want to waste time if we are simply doing something wrong.

Thanks
Chris

[buchdag]

Hi Chris. Sorry for the answering delay, haven't had much free time lately.

First, if you use HSTS, any issue with HTTPS will lead to an inaccessible site for browser that already visited it when HTTPS was up and running. There is nothing this container or nginx-proxy can do to avoid this, even if HTTPS was entirely disabled after a certificate issuance or renewal failure, the site would still be inaccessible to prior visitor due to HSTS. If you use HSTS, you are committing to the fact that your site will be accessible via HTTPS.

You can disable HSTS using nginx-proxy configuration if required.

The unsigned certificate your are seeing is the default certificate automatically generated by the container. This default certificate is there to avoid a potential connection error described in the previous link to the nginx-proxy doc.

perhaps it should be trying to get a signature again in some automated way?

It will, every hour. I agree that's far from optimal and should ideally be replaced with, using Let's Encrypt own words, a graceful retry logic using an exponential backoff pattern. I don't think that can easily be done yet without in depth change to the way the script works, but discussions and contributions about that feature are more than welcome.

Do not hesitate to tell me if you think I missed your point or if something is still unclear.

[buchdag]

@carukc ping

[carukc]

Thank you for pinging. I had not seen the previous response.

In this case the issue is entirely self inflicted. Sever times I have forgotten to setup the external DNS record before starting the container. Since docker-gen is monitoring for any changes in the containers it dutifully creates a new configuration for the new container. This results in an unsigned certificate because there is no way for LetsEncrypt to verify the domain name.

At the moment I manually delete the certificate records and restart the container.... Perhaps there should be a variable that when set, tells the script to delete any unsigned certificates and retry immediately?

This way all the user would need to do is fix the DNS problem and restart the docker-gen and proxy-companion containers.

Thanks
Chris

[buchdag]

Let me rephrase, the unsigned certificate you see is not the result of a failed ACME challenge. When the ACME challenge fails, no certificate get generated at all and you'll instead get the default certificate when you try to connect (please follow and read the previous link and this one to understand what is this default certificate and why it's there).

You don't have to delete anything, just fix your DNS misconfiguration then either restart the container or use docker container exec your-letsencrypt-container-name /app/signal_le_service.

Again, and I insist on this, no certificate nor private key get generated when the challenge fails. You either get a signed certificate or you don't get a certificate at all (and keep using the previous certificate if you already had one).

This is the full content of a fresh nginx-proxy + companion /etc/nginx/certs folder after trying to request a domain that does not resolve to the host:

bash-4.4# ls -AlhR
.:
total 20K
drwxr-xr-x 3 root root 4.0K Jun 10 12:16 accounts
-rw-r--r-- 1 root root 1.9K Jun 10 12:16 default.crt
-rw-r--r-- 1 root root 3.2K Jun 10 12:16 default.key
-rw-r--r-- 1 root root  115 Jun 10 12:16 dhparam.pem
drwxr-xr-x 2 root root 4.0K Jun 10 12:16 fail.mydomain.tld

./accounts:
total 4.0K
drwxr-xr-x 3 root root 4.0K Jun 10 12:16 acme-v01.api.letsencrypt.org

./accounts/acme-v01.api.letsencrypt.org:
total 4.0K
drwxr-xr-x 2 root root 4.0K Jun 10 12:16 directory

./accounts/acme-v01.api.letsencrypt.org/directory:
total 4.0K
-rw-r--r-- 1 root root 3.1K Jun 10 12:16 default.json

./fail.mydomain.tld:
total 4.0K
lrwxrwxrwx 1 root root 63 Jun 10 12:16 account_key.json -> ../accounts/acme-v01.api.letsencrypt.org/directory/default.json

As you can see the aforementioned default key and cert are there, and the only thing that get created by the failed attempt to get a certificate is the ACME account key.

[carukc]

Thank you for the lengthy response. I will debug further on this end to see what's going on.