miigotu / certbot-dns-godaddy

A godaddy dns plugin using lexicon for cerbot to authenticate and retrieve letsencrypt certificates

Hi there 👋

certbot-dns-godaddy's Issues

PIP install fails

This is on AlmaLinux 8. I see there is an issue already for the pip install not working, but I am getting a very different error than what that issue states:

(certbot_venv) [root@certs certs]# pip install cerbot-dns-godaddy
ERROR: Could not find a version that satisfies the requirement cerbot-dns-godaddy (from versions: none)
ERROR: No matching distribution found for cerbot-dns-godaddy
(certbot_venv) [root@certs certs]# pip install ./cerbot-dns-godaddy
ERROR: Invalid requirement: './cerbot-dns-godaddy'
Hint: It looks like a path. File './cerbot-dns-godaddy' does not exist.

For the second command, the path DOES exist. I'm probably mis-using the command for that, but I do not know a whole lot about pip. If I use pip3 instead of pip the output is the same.

Docker image is broken

$ docker run miigotu/certbot-dns-godaddy:latest
standard_init_linux.go:228: exec user process caused: exec format error

Missing command line flags

Running under Ubuntu 22.04. Goal is to have GoDaddy DNS auth used to generate certs for several internal subdomains and have certbot install into Apache.

It seems like it doesn't like -a dns-godaddy or --authenticator dns-godaddy

Missing command line flags. For non-interactive execution, you will need to specify a plugin on the command line. Run with '--help plugins' to see a list of options, and see https://eff.org/letsencrypt-plugins for more detail on what the plugins do and how to use them.

~/certbot-dns-godaddy/bin/certbot --authenticator dns-godaddy --dns-godaddy-credentials /path/to/credentials.ini --dns-godaddy-propagation-seconds 900 --keep-until-expiring --non-interactive --expand --server https://acme-v02.api.letsencrypt.org/directory -d subdomain1.example.com -d subdomain2.example.com -d subdomain3.example.com -d subdomain4.example.com

No Permissions for `var/log`

Heyo followed the python virtual env instructions. Got my credentials etc working but I get the following error when I run it:

The following error was encountered:
[Errno 13] Permission denied: '/var/log/letsencrypt'
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/folders/fg/g81x8hq51l14nnxd6wvg81hr0000gn/T/certbot-log-cnv0ol78/log or re-run Certbot with -v for more details.

Two questions for my own sanity:

1. Is this referring to local folders? Ie in my virtual python environment?
2. If not, I do not have var/log on my server in godaddy. Only logs. So where is this log going?

s

Certbot unable to authenticate with GoDaddy's API

I'm using nginx 2.10.4 (latest docker release) with certbot-dns.godaddy 2.6.0. I can no longer renew certificates. The log says that it is not authorized to access godaddy's api.

dns_godaddy_secret and dns_godaddy_key are working fine since using them with curl reports:
[{"createdAt":"2023-06-14T21:53:10.000Z","domain":"xxx.it","domainId":3xxxx9,"expirationProtected":false,"expires":"2024-06-14T21:59:59.000Z","exposeWhois":false etc...

2023-10-26 20:36:46,558:DEBUG:certbot._internal.error_handler:Calling registered functions
2023-10-26 20:36:46,559:INFO:certbot._internal.auth_handler:Cleaning up challenges
2023-10-26 20:36:46,570:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): api.godaddy.com:443
2023-10-26 20:36:46,775:DEBUG:urllib3.connectionpool:https://api.godaddy.com:443 "GET /v1/domains/xxx.it HTTP/1.1" 401 98
2023-10-26 20:36:46,780:DEBUG:certbot_dns_godaddy:Encountered error finding domain_id during deletion: Error determining zone identifier for xxx.it: 401 Client Error: Unauthorized for url: https://api.godaddy.com/v1/domains/xxx.it.

no longer work with subdomain cert generation

believed this is cased by the recent refactoring work "refactor: use the new Lexicon-based plugin API"

certbot certonly \ --authenticator dns-godaddy \ --dns-godaddy-propagation-seconds 120 \ --dns-godaddy-credentials c.ini \ --keep-until-expiring --non-interactive --expand \ --server https://acme-v02.api.letsencrypt.org/directory \ --agree-tos --email ${{ secrets.EMAIL }} \ -d subdomain.domain.com

The request for domain cert will be rejected with error message

Requesting a certificate for subdomain.domain.com Error determining zone identifier for subdomain.domain.com: 404 Client Error: Not Found for url: https://api.godaddy.com/v1/domains/subdomain.domain.com. Ask for help or search for solutions at https://community.letsencrypt.org./ See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Do I need "production" or "ote" keys?

Would be nice if this info was in the README. Going to make one of each and find out the hard way.

urllib3 version error

Hello,
I am attempting to use this on a centos 8 machine, and am running into the following error:

An unexpected error occurred:
pkg_resources.VersionConflict: (urllib3 1.24.2 (/usr/lib/python3.6/site-packages), Requirement.parse('urllib3<2.0.0,>=1.26.4'))

I'm using python 3.6

Sub domain wildcard certs fail to be generated because of the GoDaddy API check

Discussed in #75

^{Originally posted by mnejmantowicz March 28, 2024}
Hello all. When requesting a sub domain wildcard cert such as *.lab.work.com the verification performed by the API produces an error:

Error determining zone identifier for lab.work.com: 404 Client Error: Not Found for url: https://api.godaddy.com/v1/domains/lab.work.com

The only way that I know of that GoDaddy DNS supports sub domains is the add a TXT record like so:

TXT _acme-challenge.lab in the work.com root domain.

Is there a way I can bypass this check?

Plugin does not detect API errors?

I did put the godaddy credentials wrong and it was obvious in the logs because of the 401 error from the API but the certbot execution didn't tell. It makes you wait until timeout then it just say the challenge failed and suggest to increase the timeout. It would help if it says "The API returned authentication error" or something. Thanks!

ImportError with latest version

Starting with the latest version from 2023-07-14 there seems to be an issue with the ACME client.py file, e.g. running:

docker run --rm -v /etc/letsencrypt/:/etc/letsencrypt/ -v /var/lib/letsencrypt/:/var/lib/letsencrypt/ miigotu/certbot-dns-godaddy certbot help

yields

Traceback (most recent call last):
  File "/usr/local/bin/certbot", line 5, in <module>
    from certbot.main import main
  File "/usr/local/lib/python3.10/site-packages/certbot/main.py", line 6, in <module>
    from certbot._internal import main as internal_main
  File "/usr/local/lib/python3.10/site-packages/certbot/_internal/main.py", line 28, in <module>
    from certbot import crypto_util
  File "/usr/local/lib/python3.10/site-packages/certbot/crypto_util.py", line 42, in <module>
    from certbot import interfaces
  File "/usr/local/lib/python3.10/site-packages/certbot/interfaces.py", line 21, in <module>
    from acme.client import ClientBase
ImportError: cannot import name 'ClientBase' from 'acme.client' (/opt/certbot/src/acme/acme/client.py)

Certbot breaks when installed with Python3.10

OS: Ubuntu 22.04

Steps to recreate:

I followed the official steps to install Certbot with pip. (I can not get snap to work in my WSL2 distro so this was the work around)
https://certbot.eff.org/instructions?ws=other&os=pip

Up to this point when I run sudo certbot --version it outputs correctly as expected. (See below)

When I install this package using sudo /opt/certbot/bin/pip install certbot-dns-godaddy and try to run any certbot command it returns this following:

When I run sudo /opt/certbot/bin/pip uninstall certbot-dns-godaddy and then sudo certbot --version it once again outputs correctly as expected.

does not work until I create symlinks

certbot wasn't able to find this package until I created the following symlinks:

ln -s /usr/local/lib/python3.9/site-packages/certbot_dns_godaddy.py /usr/lib/python3.9/site-packages/certbot_dns_godaddy.py

ln -s /usr/local/lib/python3.9/site-packages/certbot_dns_godaddy-0.2.2.dist-info /usr/lib/python3.9/site-packages/certbot_dns_godaddy-0.2.2.dist-info

acme record doesn't get created

I'm on ubuntu 22.04. I installed certbot-dns-godaddy in a virtual environment as described here:
#6
and also called the certbot as described in that post. But the txt record never gets created. I increased the propagation seconds to 2000 but I am checking the godaddy console directly so that shouldn't matter. I have also verified my godaddy api keys and they are also good.

requires sudo?

not sure if it was just me, but i'd get authenticator not found errors if i did not preface my call with sudo

sudo certbot certonly \
  --authenticator dns-godaddy \
  --dns-godaddy-credentials /path/to/my.ini \
  --dns-godaddy-propagation-seconds 900 \
  --keep-until-expiring --non-interactive --expand \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d 'example.com' \
  -d '*.example.com'

update readme?

2.9.0 release ?

Hi,

If one is using nginx-proxy-manager, it will try to install this package, however using latest nginx-proxy-manager (2.11.1) with certbot 2.9.0 will fail with No matching distribution found for certbot-dns-godaddy==2.9.0

Looking at sources of nginx-proxy-manager, it's gonna install certbot-dns-godaddy==${certbot-version}. Ref

The way it gets certbot-version is by doing certbot --version Ref

Doing it on the latest nginx-proxy-manager, I get this:

$ docker exec -it 5042b6b961c1 /bin/bash

Version 2.11.1 (aec3020) 2024-02-28 22:33:06 UTC, OpenResty 1.21.4.3, debian 12 (bookworm), Certbot certbot 2.9.0
Base: debian:bookworm-slim, linux/amd64
Certbot: nginxproxymanager/nginx-full:latest, linux/amd64
Node: nginxproxymanager/nginx-full:certbot, linux/amd64

[root@docker-5042b6b961c1:/app]# certbot --version
certbot 2.9.0
[root@docker-5042b6b961c1:/app]#

So I think we effectively need release of this repo with version 2.9.0, or we open an issue in nginx-proxy-manager to use 2.8.0 (latest version of this repo at the time of writing)

Update: I should have checked nginx-proxy-manager repo for this issue. and indeed there is one: NginxProxyManager/nginx-proxy-manager#3592

But I think the proposed solutions there (exec into container, and hack stuff is not a great solution, so opening a issue here to fix the root cause)

Automatically remove _acme-challenge DNS TXT entries

Hi,

This plugin is working great, however I have noticed that it leaves behind the "_acme-challenge" DNS TXT entries. Would it be possible to automatically remove these entries after certbot is finished?

Thanks!

I am facing an error: unrecognized arguments

I ran
certbot certonly --authenticator dns-godaddy --dns-godaddy-credentials $FILENAME --dns-godaddy-propagation-seconds 900 --keep-until-expiring --non-interactive --expand --server https://acme-v02.api.letsencrypt.org/directory -d '$DOMAINNAME'

But I am facing this Error:

certbot: error: unrecognized arguments: --dns-godaddy-credentials $FILENAME --dns-godaddy-propagation-seconds 900

I am using certbot v1.22.0 and python v3.9 pip v20.3.4

Not working anymore with Snap based Certbot installs

I'm not sure how I was able to get this working before with Snap based installs of Certbot but I cannot get it work anymore to renew my certs. The snap based version of certbot was updated in the last 90 days and it doesn't see the certbot-dns-godaddy package anymore installed on the host system.

When I try to use the python embedded in the Snap install to pip install a package, it fails on install due to read-only filesystem.

/snap/certbot/current/bin/python3 -m pip install certbot-dns-godaddy

ERROR: Could not install packages due to an OSError: [Errno 30] Read-only file system: '/snap/certbot/current/lib/python3.8/site-packages/soupsieve'

Looks like the official certbot DNS plugins all got their own Snap packages: certbot/certbot#8096

I think we need a snap based install of this certbot DNS plugin.

For now, I'm doing a pip-based install of certbot based on these instructions: https://certbot.eff.org/instructions?ws=apache&os=pip

Propagation time

I have this setup with a propagation time of 900 seconds and it still isnt long enough, its creating the txt record but it seems to just timeout waiting for certs after this.

Error determining zone identifier for <mydomain.com>

I receive this error while generating a wildcard cert.

Error determining zone identifier for <mydomain.com>

This appears to be an error generated from the extended Lexicon library (I'm not a Python dev, so this is the best way I can articulate this). Do you know if it is possible for me to provide the DNS zone name, or to prompt Lexicon to lookup the zone name rather than guess it?

Where Should This Be Ran?

Is this tool meant to be ran via ssh while inside my server, or from a local machine and then i transfer the .pem etc to the server? It's unclear. GoDaddy does not allow the upload of .pem files so...?

How do you renew certificates

what is the command line for renewing

Unrecognised arguments

Hey,

Thanks for making this public. I haven't been able to get it to run on certbot 1.15.0 (PYTHON).
Can you check this command, the readme states double backslash \\ which doesn't work in the terminal. I wonder if theres something less missing?

Using the named schema as well due to version:
COMMAND:

$ certbot certonly \
>   --authenticator certbot-dns-godaddy:dns-godaddy \
>   --certbot-dns-godaddy:dns-godaddy-credentials /path/to/creds.ini \
>   --dns-godaddy-propagation-seconds 900 \
>   --keep-until-expiring --non-interactive --expand \
>   --server https://acme-v02.api.letsencrypt.org/directory \
>   -d 'example.com' \
>   -d '*.example.com'

ERR:

usage:
  certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates.  By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: unrecognized arguments: --certbot-dns-godaddy:dns-godaddy-credentials /path/to/creds.ini --dns-godaddy-propagation-seconds 900

Cheers,
Alfanhui

Error adding TXT record HTTP 422

Hi there,

it seems that something about the GoDaddy API is incompatible with this plugin.
I was trying to generate a wildcard certificate for one of my domains, but I keep getting this error.
I redacted some of the information, but here's the output:

Requesting a certificate for DOMAIN and *.DOMAIN
Encountered exception during recovery: lexicon.exceptions.LexiconError: Could not find record matching type: TXT, name: _acme-challenge.DOMAIN, content: <redacted>
Error adding TXT record: 422 Client Error: Unprocessable Entity for url: https://api.godaddy.com/v1/domains/DOMAIN/records/TXT/_acme-challenge
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details

This is the shell script I use:
(again, I redacted some stuff)

#!/usr/bin/env sh
docker run --rm \
  -v /var/lib/letsencrypt:/var/lib/letsencrypt \
  -v /etc/letsencrypt:/etc/letsencrypt \
  --cap-drop=all \
  miigotu/certbot-dns-godaddy certbot certonly \
    --authenticator dns-godaddy \
    --dns-godaddy-propagation-seconds 900 \
    --dns-godaddy-credentials /var/lib/letsencrypt/godaddy_credentials.ini \
    --keep-until-expiring --non-interactive --expand \
    --server https://acme-v02.api.letsencrypt.org/directory \
    --agree-tos --email "MYEMAIL" \
    -d DOMAIN -d '*.DOMAIN'

EDIT: This might be an upstream issue with lexicon, will check a bit later.

Deploy and schedule in kubernetes

I would like to try using your docker image in a Kubernetes environment with a cronjob. Do you have any suggestions on how to do that?

hub.docker.com images all have "ENV QEMU_ARCH=x86_64" in layer 16

All images on hub.docker.com are x86_64 binaries even though they are labelled arm64 etc.
The error is "exec /bin/sh: exec format error". Same for all binaries.

I think this is a bug in the multiarch build script. It shows up on layer 16:
"ENV QEMU_ARCH=x86_64" which I assume is the target architecture?

I'll have to build locally from source - doh!

It's a pity because it works really well on the Ryzen....

Cheers