[2.15.0] Certbot error: crypto.X509Extension

[CrowMash]

Checklist

• Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
  • Yes
• Are you sure you're not using someone else's docker image?
  • Yes
• Have you searched for similar issues (both open and closed)?
  • Yes

Describe the bug

When trying to renew a certificate or adding a new one with Gandi Live DNS and ECDSA 256 key type, I get an Internal Error.

Nginx Proxy Manager Version

2.15.0

To Reproduce
Steps to reproduce the behavior:

1. Go to Certificates
2. Click on Add Certificate
3. Select ECDSA 256 key type and Gandi Live DNS as provider
4. Click save
5. See error

Expected behavior

The certificat is renewed/created

Screenshots

Operating System

Docker on Debian 6.12.41-1

Additional context

[6/1/2026] [7:35:00 AM] [Express  ] › ⚠  warning   Traceback (most recent call last):
  File "/opt/certbot/bin/certbot", line 3, in <module>
    from certbot.main import main
  File "/opt/certbot/lib/python3.13/site-packages/certbot/main.py", line 6, in <module>
    from certbot._internal import main as internal_main
  File "/opt/certbot/lib/python3.13/site-packages/certbot/_internal/main.py", line 23, in <module>
    from acme import client as acme_client
  File "/opt/certbot/lib/python3.13/site-packages/acme/client.py", line 27, in <module>
    from acme import challenges
  File "/opt/certbot/lib/python3.13/site-packages/acme/challenges.py", line 24, in <module>
    from acme import crypto_util
  File "/opt/certbot/lib/python3.13/site-packages/acme/crypto_util.py", line 504, in <module>
    extensions: Optional[List[crypto.X509Extension]] = None,
                              ^^^^^^^^^^^^^^^^^^^^
  File "/opt/certbot/lib/python3.13/site-packages/cryptography/utils.py", line 76, in __getattr__
    obj = getattr(self._module, name)
AttributeError: module 'OpenSSL.crypto' has no attribute 'X509Extension'

[geephile]

I confirm this bug:
NPM: 2.15.0
Docker: Docker version 28.3.1, build 38b7060
OS: TrueNAS 25.10.3.1 - Goldeye

[6/1/2026] [4:07:30 PM] [SSL      ] › ℹ  info      Requesting LetsEncrypt certificates for Cert #26: <REDACTED DOMAIN>
[6/1/2026] [4:07:30 PM] [SSL      ] › ℹ  info      Command: certbot certonly -n --config /etc/letsencrypt.ini --work-dir /tmp/letsencrypt-lib --logs-dir /data/logs --cert-name npm-26 --agree-tos --authenticator webroot -m <REDACTED EMAIL> preferred-challenges http --domains <REDACTED DOMAIN>
[6/1/2026] [4:07:30 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[6/1/2026] [4:07:31 PM] [Express  ] › ⚠  warning   Traceback (most recent call last):
  File "/opt/certbot/bin/certbot", line 3, in <module>
    from certbot.main import main
  File "/opt/certbot/lib/python3.13/site-packages/certbot/main.py", line 6, in <module>
    from certbot._internal import main as internal_main
  File "/opt/certbot/lib/python3.13/site-packages/certbot/_internal/main.py", line 23, in <module>
    from acme import client as acme_client
  File "/opt/certbot/lib/python3.13/site-packages/acme/client.py", line 27, in <module>
    from acme import challenges
  File "/opt/certbot/lib/python3.13/site-packages/acme/challenges.py", line 24, in <module>
    from acme import crypto_util
  File "/opt/certbot/lib/python3.13/site-packages/acme/crypto_util.py", line 504, in <module>
    extensions: Optional[List[crypto.X509Extension]] = None,
                              ^^^^^^^^^^^^^^^^^^^^
  File "/opt/certbot/lib/python3.13/site-packages/cryptography/utils.py", line 78, in __getattr__
    obj = getattr(self._module, attr)
AttributeError: module 'OpenSSL.crypto' has no attribute 'X509Extension'

Both HTTP and DNS API route (mijn.host)

[jc21]

Whenever you see the crypto.X509Extension problem with a DNS plugin, it's usually because there's a mismatched python library installed as part of the dns plugin. This kind of crap is why I hate python. But I digress..

pyOpenSSL removed the X509Extension code in 24+. Certbot and Acme packages are updated to accommodate that.

In a vanilla install before installing any plugins:

# pip list | grep -i -E '(acme|certbot|openssl)' | sort
acme                    5.6.0
certbot                 5.6.0
pyOpenSSL               26.2.0

After installing the gandi dns plugin:

acme                    3.3.0
certbot                 3.3.0
certbot-dns-gandi       1.6.1
pyOpenSSL               26.2.0

So you can see the plugin itself is the problem, it needs to be updated to use the newer certbot and acme dependencies. I cannot pin these newer versions for an install because then the DNS plugin will fail to install; other plugins might be ok with a slightly lower version of a dep but in this case this is significantly lower.

If you really wanted things to work without an updated plugin, you can attempt to downgrade pyOpenSSL in dns-plugins.json for the gandi package. Or stick with v2.14.0 for the time being.

I don't see the point of holding back Certbot and pyOpenSSL entirely just because some plugins are out of date.

[jc21]

@geephile I see your problem happens when requesting a http only cert. You have the same problem above, though maybe with another dns plugin.

When you have a DNS provided Cert in NPM, you'll have the certbot dns plugin installed for it. Since that changes the python packages for the entire system, you'll be using an older certbot package and that ruins everything else including http certs.

[CrowMash]

Thanks @jc21, it look likes there is a pull request pending since february for this issue : obynio/certbot-plugin-gandi#56

In the meantime, I'll stick with the 2.14.0 I think.

[geephile]

Thanks for pointing me in the right direction (wasn't aware that the DNS plugins were not native NPM) .
The search will continue :)

[geephile]

looks like mijnhost/certbot-dns-mijn-host has a fixed (as far as i can tell unneeded) requirement of josepy==1.14.0 that causes a downgrade of certbot and acme to 3.3.0.
Fixed it for myself and submitted a pullrequest

[AceDenghar]

I'm in doubt about #5624 I thought it was a duplicate of this issue...
Sorry for my level of understanding logs...

Is-it really, not exactly the same but, a related case of this one ? Or not ?
Should we reopen #5624 ?

Thanks for all,

Ace