Certbot-auto 0.24.0 borked per issue 5369

Server
1 
Seems pretty clear that there is something borked in 0.24.0 similar to issue 5369 seen
over at https://github.com/certbot/certbot/issues/5369

I have tried over and over to get a standalone wildcard issued but the result is always 
the same message : 

 None of the preferred challenges are supported by the selected plugin

Due to : 

    Performing the following challenges:
    Exiting abnormally:
    Traceback (most recent call last):
      File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in 
        sys.exit(main())
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 1315, in main
        return config.func(config, plugins)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 1206, in certonly
        lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 118, in _get_and_save_cert
        lineage = le_client.obtain_and_enroll_certificate(domains, certname)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/client.py", line 351, in obtain_and_enroll_certificate
        cert, chain, key, _ = self.obtain_certificate(domains)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/client.py", line 294, in obtain_certificate
        orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/client.py", line 330, in _get_order_and_authorizations
        authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 66, in handle_authorizations
        self._choose_challenges(aauthzrs)
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 107, in _choose_challenges
        self._get_chall_pref(aauthzr.authzr.body.identifier.value),
      File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 289, in _get_chall_pref
        "None of the preferred challenges "
    AuthorizationError: None of the preferred challenges are supported by the selected plugin
    None of the preferred challenges are supported by the selected plugin
2

Hi @arts,

Could you please show the command you are using to issue your wildcard cert?.

Cheers,
sahsanu

3

sure thing … sorry about that :

     psd9# ./certbot-auto certonly --verbose --rsa-key-size 2048 \
    > --standalone --email me@my_tld_name.com \
    > -d *.my_tld_name.com --agree-tos --no-bootstrap \
    > --manual-public-ip-logging-ok --preferred-challenges dns-01 \
    > --server https://acme-v02.api.letsencrypt.org/directory

clearly the domain name and my email are edited here … but I think the real
issue is that a TXT record needs to exist in the zone file for the domain but
it isn’t clear what data is in the txt record.

5

You can't use --standalone with dns-01 plugin, you should use this:

./certbot-auto certonly --verbose --rsa-key-size 2048 -a manual --email me@my_tld_name.com -d '*.my_tld_name.com' --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Keep in mind that you are issuing the cert in a manual mode and you would need to repeat the same process to renew the cert. Also, the cert won't cover the base domain, only the third level domain. If you want to cover base domain too, you need to add one more -d my_tld_name.com parameter.

Cheers,
sahsanu

2 Likes
6

brilliant ! :smile:

That seems to work perfectly. Al it asked for was a txt record in the zone file and that was trivial.

I am fine with a fully manual process. There is no way around that. The apache 2.4.x server is running on an old production Oracle server and certbot won’t work there at all. So I have to do this on a debian 9 machine ( a vmware vm actually ) and if I need to redo this every 90 days then such is life.

1 Like
7

Glad it works ;).

I don’t know if your DNS provider uses some kind of API, if that is the case you could automate the process creating your own hook scripts or using something like lexicon (it is a script that covers a lot of DNS providers) and here a guide to use it with certbot.

Also, maybe certbot won’t work in that old oracle server but maybe other clients will do. For example, acme.sh is a shell script acme client with almost no dependencies.

Cheers,
sahsanu

1 Like
8

Yes I did try the acme.sh and it won’t work there either. Really you need a whole GNU toolchain around and it isn’t worth the hassle. As for DNS provider … well … same server :slight_smile: and the toll to use to update the zone file is “vi”. Not “vim” nor “nano” or anything else as they doesn’t exist either. However openssl 1.1.0h does and apache 2.4.33 and thus the server works great for that sort of stuff with no concerns about intel spectre or other cisc cpu bugs. This will be more easy when we migrate over to IBM Power with Red Hat but that won’t happen for months.

1 Like
9

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