I’ve just tried this with Certbot release 0.9.3, as well as with the master branch from GitHub (following the developer instructions to install the latest development version), and I’m still getting the message “Punycode domains are not presently supported”.
AIUI the master branch should work with punycoded domains. Are you certain you’re running the developer version? There’s a small but important difference in how the client is invoked with that setup - instead of ./certbot-auto, you simply use certbot after enabling the venv. If you run certbot --version you should see something like “certbot 0.10.0.dev0” for master.
1 Like
Yep, I agree with what @pfg said. The error message you cite is removed from the master branch, so I’m guessing you’re not running the master branch correctly.
1 Like
With the developer version, running certbot doesn’t work because it requires root:
ben@markov:~/certbot$ source ./venv/bin/activate
(venv) ben@markov:~/certbot$ certbot
The following error was encountered:
[Errno 13] Permission denied: '/var/log/letsencrypt/letsencrypt.log'
If running as non-root, set --config-dir, --logs-dir, and --work-dir to writeable paths.
And running with sudo doesn’t work either:
(venv) ben@markov:~/certbot$ sudo certbot
[sudo] password for ben:
sudo: certbot: command not found
That’s why I tried certbot-auto in the developer version. It says:
(venv) ben@markov:~/certbot$ ./certbot-auto --version
Requesting root privileges to run certbot...
/home/ben/.local/share/letsencrypt/bin/letsencrypt --version
letsencrypt 0.9.3
On the other hand, certbot --version says:
(venv) ben@markov:~/certbot$ certbot --version
certbot 0.10.0.dev0
So to sum up:
-
certbotrequires root, but cannot be run withsudo. -
certbot --versionreturns the correct version number, but./cerbot-auto --versiondoes not.
You’ll probably need to activate the venv with sudo too, i.e. sudo source ./venv/bin/activate. I’m not entirely certain if that’ll work. You might have to switch to root permanently for both commands, i.e. do sudo su and then source ./venv/bin/activate followed by certbot. If that doesn’t work either, add one more step between sudo su and sudo source ./venv/bin/activate: ./tools/venv.sh - this is because I’m not sure where the developer instructions put the dependencies and whether they’ll be found when you switch from your user to root.
(sudo su is a bad habit to get into, but seems fine in this limited context.)
I’d rather not debug cerbot on my server. Since this issue makes it impossible to follow the instructions in the documentation for using the developer version of certbot, it would be great if the certbot developers could figure out the right sequence of commands and put it in the documentation.
There’s no debugging involved. The commands need to run as root, and sudo su will let you run them as root. The commands I mentioned are the same ones mentioned in the guide, you just run them as root.
If sudo su is the only way to use your software, then at the very least you have a documentation bug. Everyone will expect just to be able to use sudo, as we do with other software that requires root privileges.
Using sudo su with the current master branch, I still get this error with a punycode domain:
An unexpected error occurred:
The request message was malformed :: Name does not end in a public suffix
The domain in question ends with the suffix .xn--ngbc5azd, the Arabic equivalent of .net, which has been generally available as a TLD since 2014.
The software as released via certbot-auto or via distribution repositories works just fine without sudo su. These instructions are intended for developers working on certbot and assume that you either do not want to run the client as root while developing (the client helpfully provides instructions on how to run without root if you attempt that), or that you are familiar with the workings of virtual environments (which is a commonly used tool in python projects, and is the reason you have to stick to one user for all commands, which sudo su achieves).
I don't think adding sudo su would makes sense here, as that's not how developers typically run certbot (while developing).
See this for more details - a fix is currently scheduled for Thursday (might be delayed if something comes up):
OK, but I got to that documentation by following a link from the announcement of punycode support that was posted here, advising me to install the development version to use that feature. This would seem to be a common use case: the user, who is not a Python programmer and is therefore not familiar with virtual environments, realises that the ancient Ubuntu certbot package doesn't have a feature they need. They don't want to develop certbot, they just want to install and run the development version. It would be helpful to provide instructions for that use case.
The average user who does not wish to use the outdated package in their distribution repository can use certbot-auto to get the latest release.
The development version is really that - a version tracking the latest development, possibly with a number of bugs, primarily intended for developers working on certbot. It’s a possible workaround if you need IDN support today, don’t wish to use one of the alternative clients, and are comfortable with running pre-release code on a production server, but it’s not intended for general usage (and shouldn’t be!); the documentation merely reflects that.
OK, thanks for your help.
The fix appears to have been rolled out successfully – people are now reporting success getting certs issued for IDN TLD names.
It’s working now for me, too. Thanks very much!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.