Docker version of certbot

Help
1

Hi Folks,

Does anyone know if the Docker version of Certbot will respond to a challenge request on port 443? I have a success over 80, but would like to get new certs on 443. The container is listening on 443, but the challenge only appears to work on 80.

As a second question - how can I pass in the initial values for the questions asked (like my email address?) - these servers need to start and be configured automatically. Is that the -m flag?

Thanks.

My domain is: docker.dev.vaultara.com

I ran this command:

sudo docker run -it --rm --name certbot \
    -v "/home/ubuntu/docker_cache/certs:/etc/letsencrypt" \
    -v "/home/ubuntu/docker_cache/letsencrypt:/var/lib/letsencrypt" \
    -p 80:80 \
    -p 443:443 \
    certbot/certbot certonly --standalone --dry-run

It produced this output (with port 80 restricted on the firewall):

Simulating a certificate request for docker.dev.vaultara.com

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
  Domain: docker.dev.vaultara.com
  Type:   connection
  Detail: Fetching http://docker.dev.vaultara.com/.well-known/acme-challenge/ZdFHfpBM96ZUUxrTqqUevwi9K12E3ucfqJKf9nCCADM: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority couldn't exterally verify that the standalone plugin completed the required http-01 challenges. Ensure the plugin is configured correctly and that the changes it makes are accessible from the internet.

From Docker:

$ docker ps -a
CONTAINER ID   IMAGE             COMMAND                  CREATED             STATUS                         PORTS                                                                      NAMES
8d9ecc8fa1fa   certbot/certbot   "certbot certonly --…"   32 seconds ago      Up 31 seconds                  0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   certbot

My web server/operating system is (include version):

ubuntu - I'm setting up a Docker Registry, so these certs will go in that container. So technically, it's Go.

My hosting provider, if applicable, is: AWS/EC2

I can login to a root shell on my machine (yes or no, or I don't know): Yes

The version of my client is: certbot 1.16.0

1 Like
2

Welcome to the Let's Encrypt Community :slightly_smiling_face:

Certbot has no authority in this regard.

The HTTP-01 challenge can only be done on port 80. Allowing clients to specify arbitrary ports would make the challenge less secure, and so it is not allowed by the ACME standard.

Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).

register:

Options for account registration

--register-unsafely-without-email

Specifying this flag enables registering an account with no email address. This is strongly discouraged, because you will be unable to receive notice about impending expiration or revocation of your certificates or problems with your Certbot installation that will lead to failure to renew. (default: False)

-m EMAIL, --email EMAIL

Email used for registration and recovery contact. Use comma to register multiple emails, ex: u1@example.com,u2@example.com. (default: Ask).

--eff-email

Share your e-mail address with EFF (default: None)

--no-eff-email

Don't share your e-mail address with EFF (default: None)

https://certbot.eff.org/docs/using.html#certbot-command-line-options

Please, please, please be sure to store the certificates you acquire into permanent storage and reference them when turning-up instances. Failure to do so will result in terrible consequences...

1 Like
3

Pass --non-interactive if you want Certbot to proceed without user prompts.

Once you've done that, Certbot will produce error messages if it can't proceed without your input.

For totally non-interactive usage, you'll need at least these flags to get past the prompts:

certbot certonly \
--standalone \
--agree-tos \
-m email@example.com \
--no-eff-email
2 Likes
4

There are various ways to validate the required certificate authentication.
Using certbot limits the initial authentication to HTTP or DNS.
[DNS based authentications don't require any connection to the system requesting the cert]
HTTP based authentications can be redirected to HTTPS (but they will continue as HTTP initially in all subsequent renewals). So, that doesn't mitigate the need for port 80; it merely adds the need for port 443 to it.

That said, there is another authentication method that could allow for the initial challenge request to be made via TLS-ALPN (port 443), but that would require the use of another ACME client that supports it.

1 Like
5

Thank you for this.

Unfortunately, I don't have a way to redirect 80 to 443 because 80 is locked down at the network level. We are FedRAMP compliant, opening the port just for this is problematic. Perhaps a DNS option may work. I'll continue to research.

And I am passing in a stock cli.ini with the options I need. Seems to work great.

Thanks again.

2 Likes
6

HTTP to HTTPS redirection is done within the web server.
Port translating the external port 80 to an internal port 443 is NOT how to solve this problem and will only make matters worse.

1 Like
7

Agreed. To clarify, I don't have a web server in the mix - this is for an internal docker repo (hosted in a container). Port 80 is blocked at the firewall (NetworkACL) level. Traffic to port 80 will never reach the machine to be redirected.

We have some other options, but it looks like HTTP-01 is not one of them. Locking this to port 80 is limiting considering how much many sites are moving to TLS based traffic, and as in our case, locking down 80 entirely. Re: @griffin's response, I agree, but I also don't think 443 is an arbitrary port. The Certbot container is listening on 443, but it seems it would never be used.

We will continue to look for a way to make this work. Thanks everyone.

2 Likes
8

Port 443 was previously supported for direct authentication.
There was an issue / potential exploit found that removed that from the list.
TLS-ALPN overcomes the issue but hasn't yet been well accepted and included in popular web servers.
[ I use TLS-ALPN with acme.sh and nginx and have had no problems ]

1 Like
9

I concur with @rg305.

DNS-01 would be the most hands-off in terms of local setup, but TLS-ALPN-01 might be easier to automate for renewal.

10

Is that a deal breaker?
Can you install one and only use it to get the cert (and renew it) ?
If so, then you would have to find an ACME client that support TLS-ALPN-01 in standalone mode.
Otherwise, DNS-01 would be the last possible choice (not always an easy one).

1 Like
11

This is an excellent idea. Will explore. Thanks a bunch to all!

2 Likes
12

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