certbot / certbot-docker Goto Github PK

According to the email I received today from Let's Encrypt, it looks like ACMEv1 is being deprecated.

Beginning June 1, 2020, we will stop allowing new domains to validate using
the ACMEv1 protocol. You should upgrade to an ACMEv2 compatible client before
then, or certificate issuance will fail.
ACMEv1 API deprecation details can be found in our community forum:
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1

Hello,

The penultimate link in the description on the Dockerhub page for certbot links to https://www.github.com/certbot/certbot-docker.git (which 404s), but it should link to https://github.com/certbot-docker/certbot-docker/ (this repo).

That's about it, thanks for the fine work !

With the sunset of Python 2 on January 1, 2020, are there plans to update the core Dockerfile from using python:2-alpine3.10 to python:3-alpine3.10?

Each of these Certbot DNS plugins supports Python >=3.4.

• dns-dnsmadeeasy
• dns-dnsimple
• dns-ovh
• dns-cloudflare
• dns-cloudxns
• dns-digitalocean
• dns-google
• dns-luadns
• dns-nsone
• dns-rfc2136
• dns-route53
• dns-gehirn
• dns-linode
• dns-sakuracloud

Is there a Windows version planned?

When the tags on this repository are updated, builds are triggered for all of our Docker images at https://hub.docker.com/u/certbot. There is a race condition here though because the plugins depend on base Certbot image being built.

This race condition caused our builds to fail for what I believe was the first time recently where both the Cloudflare plugin and the DNS Made Easy plugin failed to build.

What can we do to fix this problem? Can we use the custom build hooks to wait until the Certbot image is available? Can we cause the image for the DNS plugin to rebuilt when the corresponding tag in the base Certbot image is built without having it affect older images?

Hi,

The Dockerfile I use:

FROM certbot/dns-cloudflare:v0.37.2

ARG CLOUDFLARE_API_KEY=__SET_CLOUDFLARE_API_KEY__

ENV APP_FOLDER /app
ENV CLOUDFLARE_EMAIL [email protected]
ENV CLOUDFLARE_API_KEY $CLOUDFLARE_API_KEY
ENV DOMAIN_NAME *.domain.com

WORKDIR $APP_FOLDER

COPY cloudflare.ini $APP_FOLDER/cloudflare.ini.tmp

RUN set -x && \
    apk update && \
    apk --no-cache add gettext && \
    envsubst '${CLOUDFLARE_EMAIL} ${CLOUDFLARE_API_KEY}' < cloudflare.ini.tmp > cloudflare.ini && \
    chmod 600 cloudflare.ini && \
    certbot certonly \
              --dns-cloudflare \
              --dns-cloudflare-credentials $APP_FOLDER/cloudflare.ini \
              -d "${DOMAIN_NAME}" \
              --non-interactive \
              --agree-tos \
              -m [email protected] \
              --server https://acme-v02.api.letsencrypt.org/directory

The Cloudflare.ini file:

# Cloudflare API credentials used by Certbot
dns_cloudflare_email = $CLOUDFLARE_EMAIL
dns_cloudflare_api_key = $CLOUDFLARE_API_KEY

I build the image with this command:

$ docker image build --build-arg CLOUDFLARE_API_KEY=__my_cloudflare_key__ -t certbot --no-cache .

The build succeeds but /etc/letsencrypt is empty.

But if I run the container:

$ docker container run -it --rm --entrypoint=/bin/ash certbot

then execute the same command, it works!!!

/app # certbot certonly \
>               --dns-cloudflare \
>               --dns-cloudflare-credentials $APP_FOLDER/cloudflare.ini \
>               -d "${DOMAIN_NAME}" \
>               --non-interactive \
>               --agree-tos \
>               -m [email protected] \
>               --server https://acme-v02.api.letsencrypt.org/directory

This is driving me crazy, can you help ?

Is the certbot script installed in this docker image considered certbot-auto, implying that cli flags specific to certbot-auto have meaning? For example does the --no-self-upgrade flag (which is certbot-auto only) actually do anything when used with this certbot installation?

I'm trying to run certbot on a Raspberry Pi 3 B+, but I get the error standard_init_linux.go:211: exec user process caused "exec format error".

[slang@alarmpi ~]$ docker pull certbot/certbot
Using default tag: latest
latest: Pulling from certbot/certbot
050382585609: Pull complete
39e8b6a82737: Pull complete
9c3480ede676: Pull complete
7dbf571e3a56: Pull complete
9bb6018c38b6: Pull complete
eb34e770aadb: Pull complete
48b3917fa816: Pull complete
1807b38b6e0c: Pull complete
8c132af6b00c: Pull complete
Digest: sha256:f92b35d7b247190648149d8583ed143c061827ceac6775c30f5cd03b03319826
Status: Downloaded newer image for certbot/certbot:latest
docker.io/certbot/certbot:latest
[slang@alarmpi ~]$ docker run --rm  certbot/certbot --help
standard_init_linux.go:211: exec user process caused "exec format error"

Running the same 2 commands on my non-ARM laptop works as expected; it prints out the help text.

The images of dns-cloudflare and dns-dnsmadeeasy on Docker Hub are still using certbot v1.1.0.
An update to v1.2.0 would be great, especially for Cloudflare (v1.2.0 supports restricted API tokens).

Add a CI to this repo that generates try builds from PRs and branches and optionally run smoke tests.

A big advantage of the docker library (certbot/certbot#5540) are automated rebuilds if a base image have been updated.
The current image published on DockerHub has not been rebuild against recent (security) updates of Python and Alpine Linux.

I used https://github.com/wmnnd/nginx-certbot and expected this container to work fine out-of-the-box -- which it did, until renew was due and did not work. For a while I was just puzzled, but then I decided to investigate the issue.

Running certbot renew manually from inside the container I get

The requested nginx plugin does not appear to be installed

Trying certbot --nginx renew yields the same.

What to do?

Indeed, I do run certbot with nginx:

version: '3.7'

networks:
  proxy:
    external: true

services:
  n_proxy: 
    image: nginx:1.18.0-alpine
    hostname: n_proxy
    restart: on-failure:5
    networks:
      - proxy
    volumes:
      - /root/2proxy/nginx.conf:/etc/nginx/nginx.conf
      - /root/2proxy/nginx/log/:/var/log/nginx/
      - /root/2proxy/nginx/cache/:/etc/nginx/cache
      - /etc/letsencrypt/:/etc/letsencrypt/
    ports:
      - mode: host
        protocol: tcp
        published: 80
        target: 80
      - mode: host
        protocol: tcp
        published: 443
        target: 443
    command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"

  certbot:
    image: certbot/certbot
    restart: unless-stopped
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt
      - /var/www/certbot:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

My certbot version is

/opt/certbot # certbot --version
certbot 1.5.0

Also, I cannot find out which operating system it runs on, so I have no idea which command for install would be correct:

/opt/certbot # uname -a
Linux 7e0a9a3dd132 4.18.0-147.8.1.el8_1.x86_64 #1 SMP Thu Apr 9 13:49:54 UTC 2020 x86_64 Linux

According to some hints I found googling, I should run

/opt/certbot # apt-get install python-certbot-apache -y
ash: apt-get: not found

so apt-get is not ok and apache does not make sense anyway. Looking at Dockerfile I deduce it is alpine, so I try

/opt/certbot # apk add python-certbot-nginx
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
ERROR: unsatisfiable constraints:
  python-certbot-nginx (missing):
    required by: world[python-certbot-nginx]

Some more info:

/opt/certbot # env
QEMU_ARCH=x86_64
HOSTNAME=7e0a9a3dd132
PYTHON_PIP_VERSION=20.1.1
SHLVL=1
HOME=/root
GPG_KEY=E3FF2839C048B25C084DEBE9B26995E310250568
PYTHON_GET_PIP_URL=https://github.com/pypa/get-pip/raw/eff16c878c7fd6b688b9b4c4267695cf1a0bf01b/get-pip.py
TERM=xterm
PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
CERTBOT_VERSION=1.5.0
PYTHON_VERSION=3.8.3
PWD=/opt/certbot
PYTHON_GET_PIP_SHA256=b3153ec0cf7b7bbf9556932aa37e4981c35dc2a2c501d70d91d2795aa532be79

I ran out of ideas.

Your certificate (or certificates) for the names listed below will expire in 10 days (on 12 Aug 20 12:07 +0000).

Certbot doesn't work with Google Domains DNS so acme-dns was made to workaround that problem without having to sign up for another 3rd party DNS service (acme-dns is self-hosted). It would be helpful to have a certbot plugin to automate the ACME process with acme-dns so that these two Docker containers can generate wildcard certificates for users of Google Domains DNS.

acme-dns Docker:
https://hub.docker.com/r/joohoi/acme-dns/
acme-dns Github:
https://www.github.com/joohoi/acme-dns
A useful script from acme-dns that may help with building an official plugin:
https://github.com/joohoi/acme-dns-certbot-joohoi/blob/master/acme-dns-auth.py

Thank you

During our last release, our Docker images failed to build until #23 landed. I think it's worth spending the time to try and ensure we catch these issues earlier rather than at release time.

To fix this, I think we should build/test/deploy these images nightly. Ideally we should do this for all images, but I think it's possible this will be too slow and we should just test a subset. Whether or not this is too slow requires testing.

As for how to do this, I think we have at least a few options. Probably in my order of preference from least to most preferred:

1. Build (and run smoke tests) on the Docker images built using the latest release tag.
2. Build (and run smoke tests) on the Docker images built using Certbot master.
3. Build (and run smoke tests) and deploy the Docker images built using Certbot master to something like a <arch>-nightly tag on Docker Hub.

While those are my preferences for the end goal, any of these approaches are a significant improvement over what we have now and would have caught the problem we had during our last release. Because of that, I think implementation simplicity should be a major factor here.

A related issue here is #15.

@joohoi, you expressed interest in working on this issue.

cc @adferrand as I'd be surprised if you didn't have opinions here 😄

There was a bit of confusion on the community forum at https://community.letsencrypt.org/t/is-this-really-an-official-repository/99444 about whether our Docker images are really official images. The only reference to them outside of this separate GitHub org is in https://certbot.eff.org/docs/install.html#running-with-docker which you probably won't see if you just happened to stumble across the images on Docker Hub.

I think one way to help fix this is to link to this section of our docs in the Docker image's README. This has the added benefit of providing more information on how to successfully use these images.

I was trying to use image certbot/certbot:v1.4.0 behind a http proxy.
But it seems the version of httplib2 used in this image is 0.10.3.
Which happens to be the last version not respect HTTP_PROXY / HTTPS_PROXY environment variables.
httplib2/httplib2#90

Would anyone help to upgrade httplib2 to a newer version?

you fixed recently the multiarch problem.
Help others to see which arch now are supported and add the matching tags on docker hub.