Crypto: - How to Troubleshoot Let's Encrypt Errors with Docker Packages

Hi All,

I use this docker package which includes acme/autocert integration allowing us to request, receive, and use Let’s Encrypt certificates for domains configured to use this package.

I run this command to start the container:

docker run --restart=always -p 33333:33333 -p 443:443 -v /var/www/geoservices:/tmp/www -i -t fiorix/freegeoip -http :33333 -https :443 -public /tmp/www -letsencrypt -letsencrypt-email -letsencrypt-hosts www.{MYDOMAIN},{MYDOMAIN}

I was using an SSL certificate recently without issue, but for some reason, it appears to have stopped working recently, and I have no idea why. I’m no expert on docker packages, nor do I know anything about the Go language… so does anyone know how to troubleshoot / see why Let’s Encrypt integration in docker containers using acme/autocert is not working?

I can run the package interactively, but all I get from the output is:

[error] 2018/03/01 17:31:33 http: TLS handshake error from {MYIP}: acme/autocert: missing certificate

I’m guessing it’s missing the certificate because it failed to get / renew one, but it doesn’t show why. :frowning:

Hi @own3mall,

Are there any associated log files under /var/log inside the container?

In the docker container itself? How do I access the files in the docker container?

I tried modifying the command to run the docker container with this:

-v /var/www/geoservices/logs:/var/log

I would assume that would use my server’s /var/www/geoservices/logs directory for the docker container’s /var/log directory. Unfortunately, that didn’t work, and I don’t see any logs from the docker container in /var/www/geoservices/logs. My server’s let’s encrypt logs are in /var/log/letsencrypt, but these aren’t the docker logs, so they show nothing of value.

You could start a bash shell with docker run (if the container isn’t running) or docker exec (if it is).

Thanks, I didn’t know that. I was able to connect to the docker container directly using a bash shell, but I don’t see anything Let’s Encrypt related in /var/log for the container… or anywhere in that container… I looked everywhere for something Let’s Encrypt related but found nothing.

Can you see anything about how the Let’s Encrypt client is set up inside the container? Could you conceivably run it interactively?

(There’s no guarantee that any particular kind of logging is happening—so we might ultimately end up pointing you to the people who developed the Docker image to ask them to add more logging or error reporting.)

Oh, another thing that I just noticed is that you have the port 443 redirection in place, which is a likely explanation for a failure here. There was a change last month which no longer allows port 443 to be used for validation for new issuances:

If this image was developed prior to that change and hasn't updated its software and/or documentation, that would be a very likely reason for the validation failures!

1 Like

Wouldn’t it just try to validate over port 80 then? I have port 80 for that domain redirect to the one I’m using for http in the docker image (33333), so I’d imagine it should still work?

I didn’t find anything certbot related, so I don’t know how it works or how it’s used in this docker image. I’m guessing it uses built in GO functionality that acme/autocert somehow takes care of it all.

Yeah, it’s an older docker image.

The autocert package only implemented the TLS-SNI challenge up until the incident, so all applications that use it have to be rebuilt.

Based on the vendor file in the project you are using:

	"checksumSHA1": "4z75fxISOgKOmbS/X+qcTCXdyCs=",
	"path": "",
	"revision": "76eec36fa14229c4b25bb894c2d0e591527af429",
	"revisionTime": "2017-09-27T17:19:09Z"

the project is using the old version of autocert that will never succeed. Author needs to update their project.


Thanks, I let the author know. :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.