DnsManagementClient.__init__() takes from 3 to 4 positional arguments but 5 were given

Help
1

Hello Team,

we are using certbot command for getting the certs-

certbot certonly --authenticator dns-azure --preferred-challenges dns --noninteractive --agree-tos --dns-azure-config ./azure.ini -m ITSOECloudandIaaS-AzureSMEs@xxxx.com $san_args --key-type rsa --config-dir $HOME/.config/letsencrypt --work-dir $HOME/.local/share/letsencrypt --logs-dir $HOME/.cache/letsencrypt -v

However, we are running in the github actions and here are some plugins that we are installing:

steps:
- name: Checkout Repository
  uses: actions/checkout@v2

- name: Update and Upgrade Packages
  run: |
     sudo apt-get update
     sudo apt-get upgrade -y
  shell: bash

- name: Update and Upgrade Packages
  run: |
     sudo apt install jq 
  shell: bash

- name: Install Python3 and pip
  run: |
     sudo apt-get install python3-pip -y
  shell: bash

- name: Install Certbot and Certbot Plugins
  run: |
     sudo -H pip install --ignore-installed certbot certbot-dns-azure
  shell: bash

- name: Remove python3-openssl and Install pyOpenSSL
  run: |
     sudo apt remove python3-openssl -y
     sudo -H pip install pyOpenSSL
  shell: bash

During the execution of the certbot command, we are getting error now while it worked exactly fine till last month.

This is the error we are getting now along with the logs

dns: cdt-api.fulfillment.xxxx.com

environment: cdt

domainname: fulfillment.xxxx.com

Preparing azure.ini file..

azure.ini file created successfully..

dns_without_domain: cdt-api

-d cdt-api.fulfillment.xxxx.com

checking existing CNAME records..

Renewing certificate now..

Saving debug log to /home/runner/.cache/letsencrypt/letsencrypt.log

Plugins selected: Authenticator dns-azure, Installer None

Account registered.

Requesting a certificate for cdt-api.fulfillment.xxxx.com

Performing the following challenges:

dns-01 challenge for cdt-api.fulfillment.xxxx.com

Cleaning up challenges

Encountered exception during recovery: TypeError: DnsManagementClient.init() takes from 3 to 4 positional arguments but 5 were given

An unexpected error occurred:

TypeError: DnsManagementClient.init() takes from 3 to 4 positional arguments but 5 were given

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /home/runner/.cache/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Could you please help as soon as possible as it may be a high priority issue (p1) if the certificates are not renewed.

Thank you.

2

There's no DnsManagementClient anywhere in the Certbot code base, so it's likely part of the third party DNS plugin you're using or a library that plugin is depending on.

This can be confirmed with a detailed backtrace from the log.

If I were to guess, it's probably a version mismatch between the third party DNS plugin and one of their dependencies.

Edit:
Looks like in azure-mgmt-dns there were 5 arguments possible:

But with the most recent update from 2025-07-14, it was changed to:

Most likely everything starts to work again if you downgrade/ppin the azure-mgmt-dns Python package to 8.2.0.

Also probably a good idea, if 8.2.0 makes everything work again while 9.0.0 breaks it, to file an issue with the author of the Azure DNS plugin at GitHub · Where software is built.

By the way: is the xxxx.com domain really yours? Or is it just a placeholder? If it's the latter: please don't use existing, registered domains as placeholders. Use example.com and/or one of the other TLDs for that domain name as placeholders. Thank you.

2 Likes
3

Hello Osiris,

Thanks for your response.

Just by Replacing this step -

**- name: Install Certbot and Certbot Plugins**

** run: |**
** sudo -H pip install --ignore-installed certbot certbot-dns-azure**

By this step -

**- name: Install Certbot and Certbot Plugins**

** run: |**
** sudo snap install certbot --classic**
** sudo snap install --channel=stable certbot-dns-azure**
** sudo snap set certbot trust-plugin-with-root=ok**
** sudo snap connect certbot:plugin certbot-dns-azure**
** shell: bash**

it started working again. Not sure if this is a good idea to leave it as is or is there any other better approach that I can consider to permanently resolve this issue please?

The Domain belongs to us (Just masked it here)

Thank you.

4

You didn't share enough to convey what you're doing, so I should give this warning: subscribers should NOT order Certificates from a trusted CA as part of their CI/Testing Systems. Staging and Test systems are fine; ordering from Production and saving the cert into CI for other runs is fine as well. Many users have wedged their account with Rate Limits by ordering in their CI systems and bad autoscaling of cloud services though.

3 Likes
5

You didn't "mask" it. You substitutesd a real domain that is not yours. Please don't do that. It makes it harder to troubleshoot and and is inconsiderate to the actual domain registrant.

If you want to hide your domain, please use an appropriate mechanism, such as example.com. This makes it obvious that you are hiding the real domain, and doesn't misuse a domain that belongs to someone else.

2 Likes
6

hi @jvanasco , @linkp , Sure Noted.
This was our first Lets Encrypt Community Support Request :slight_smile:

Could Either of you please confirm the steps that we took to resolve is Okay? Or do you have any other better approaches to resolve this permanently?

Thank you.

7

You should ask that of the author of the plugin. They should be made aware of this problem and that the snap install worked for you.

Maybe a coincidence but someone just posted about your exact problem at that github. See: Hardcode azure-mgmt-dns version to 8.2.0 by carnerito · Pull Request #58 · terricain/certbot-dns-azure · GitHub

Maybe some volunteer here has personal experience with that 3rd party azure plugin. But, it is still best to work directly with the author for the best solution.

2 Likes
8

The snap probably worked by lucky timing.

The issue, as disclosed on the link shared, is that azure-mgmt-dns was recently upgraded with breaking changes and the certbot plugin does not guard against that via version pinning.

Installation via PyPi will always provide the most recent versions of a package immediately after they have been uploaded to all users. It is up to developers to pin releases of required packages. If you install software with unpinned dependencies, the latest version of that dependency is getting pulled in from PyPi.

Installation via Snap will utilize their systems and deployment logic -- so there is usually a delay in getting the snap developed from the PyPi release, and then there is a delay in how the snap is distributed across channels (see Channels | Snapcraft documentation). Snapd also (at least at one time) partitioned releases to the general public – so once something hits stable, it slowly rolls out to users in groups instead of all users at once.

Most likely the @Suhas_Chandrashekar switched to snap during a window in which the breaking changes in the azure package have not widely deployed on the snap network yet. If you have a snap machine handy, you can interrogate the system to see what is live on which channels. I would not be surprised if snapd updates to the broken packages in the next few days.

4 Likes
9

Thanks @MikeMcQ and @jvanasco !

So, while I wait this PR to be merged - Hardcode azure-mgmt-dns version to 8.2.0 by carnerito · Pull Request #58 · terricain/certbot-dns-azure · GitHub, Could this be a safer option to use with - ?

  • name: Install Certbot and Certbot Plugins
    run: |
    sudo -H pip install certbot certbot-dns-azure azure-mgmt-dns==8.2.0
    shell: bash

Could you please suggest?

1 Like
10

sudo -H pip install certbot certbot-dns-azure azure-mgmt-dns==8.2.0

Yes, that's what I would do.

4 Likes
11

Thanks @jvanasco. Tried this and it is working now.

Just for my understanding, so, should we lock in this version of plugin that works for us? For instance, lets say, there are newer versions of this getting released and we would still be on 8.2.0.

would that affect in any way?

12

I'd probably pin the plugin too.

13

Thanks @Osiris . Would you mean, something like this as an example?
pip install certbot==2.10.0 certbot-dns-azure==2.10.0 azure-mgmt-dns==8.2.0

Just for my understanding, so, should we lock in the versions of all these plugins that works for us? For instance, lets say, there are newer versions of this getting released and we would still be on 8.2.0.

would that affect in any way?

Thanks in advance for your suggestions.

14

Where does certbot-dns-azure==2.10.0 come from? Third party plugins most of the time don't follow the Certbot version. The most recent version of the Azure DNS plugin (certbot-dns-azure · PyPI) at this time is 2.6.1.

I'd probably pin the DNS plugin and the azure-mgmt-dns library to their current most recent versions. Certbot 2.10.0 is more than a year old now, so I don't know why you'd pin it to that old version. It's current stable release is 4.1.1.

That would at least fix your current issue.

If you're using the package==version stuff, yes, pip will install the requested versions.

It might in the future. E.g., if Azure makes a breaking change in their API and the old library/plugin breaks, that's a risk of course. But there almost never is a "one size fits all" solution.

1 Like
15

Based on what you want to do, I'm not sure if you need to or not. On an upgrade, pip should catch this and not update the certbot plugin; I'm not sure how the compatibility matrix would work on a fresh install.

That being said, personally, I would not pin and hope it breaks. Ideally when certbot-dns-azure is updated, it will likely be incompatible with azure-mgmt-dns==8.2.0 and cause a failure on your system. That failure will be your notification the plugin has updated, and you can unpin the azure-mgmt-dns=8.2.0 version. I prefer that approach to scheduling a manual version and upgrade into every weekly sprint, or onto someone's calendar.

For most other situations I would pin everything and just let it be - but I consider packages that do third party credentialed auth (like azure-mgmt-dns) to be sensitive and I'd want to ensure I get them unpinned to receive security updates ASAP. If you prefer to schedule version checks to catch the forthcoming upgrade, then you can safely pin everything.

Also on a quick check - the breaking change seems to be in azure-mgmt-dns>=9.0. I would test the pin with azure-mgmt-dns<9.0 and use that if it works. That will pull in all security updates if they backport anything. Their versioning policy appears to breaking changes in major versions only (I couldn't find the explicit policy).

As someone who has participated in a lot of Python projects, every project gets hit with a breaking changes issue at one point or another. The next release of the certbot plugin will likely feature better alignment and sensitivity to versioning policy of the azure plugin, and I'd want to leverage that ASAP and stop managing their dependencies for them.

1 Like
16

@Suhas_Chandrashekar Tbh it would be quicker to fix the plugin and submit a pull request for future generations than discuss it much here. Pinning the version is temporary workaround.

1 Like
17

Thank you @Osiris , @jvanasco For your help for sharing your suggestions. That was indeed helpful. :slight_smile:

@webprofusion - Absolutely. Waiting for this PR to get merged - Hardcode azure-mgmt-dns version to 8.2.0 by carnerito · Pull Request #58 · terricain/certbot-dns-azure · GitHub

18

will eagerly wait for this! :slight_smile: