Letsencrypt-auto certonly fails with KeyError: u'domain.tld'

Help
1

Hi. I try to run Let’s Encrypt Client (the latest version, from GIT) using the following command:

./letsencrypt-auto certonly --email myemail@myemail.net --webroot -w /var/www/ --webroot-map '{"(10 domains here)" : "/var/www/"}' --csr /home/jason/Desktop/mydomainsAIO.csr.der

I am running Ubuntu 15.10, 64-bit.

And I get the errors:

Encountered exception during recovery

An unexpected error occurred:
KeyError: u'(the first out of the 10 domains is here)'
Please see the logfiles in /var/log/letsencrypt for more details.

How can I fix that?

2

Don’t know if that’s the problem, but try it without the -w switch? --webroot-map should be enough on its own.

4

I think I know the issue:

You’ve probably got something like this:

--webroot-map '{"example1.com example2.com example3.com" : "/var/www/"}'

As far as I know with my limited testing (like, 10 seconds), that’s not allowed.

I think the --webroot-map wants a "example.com": "/var/www/" combo. I.e.: single domain with the corresponding webroot-path. I’m afraid you should duplicate the : "/var/www/" part a few times :wink:

Note: the use of --webroot-map is more an internal thing and is only usefull in this instance because of your use of the CSR… (Buggy --webroot-path and the sorts)… When the CSR-webroot-path bug is solved, you won’t be needing --webroot-map any longer.

5

If you want my exact webroot-map format it is:

--webroot-map '{"dom1.tld, www.dom1.tld, mail.dom1.tld, mx.dom1.tld, mx2.dom1.tld, dom2.tld, www.dom2.tld, mail.dom2.tld, mx.dom2.tld, mx2.dom2.tld" : "/var/www/"}'

What should I change there?

6

Make it like: "dom1.tld": "/var/www/", "www.dom1.tld": "/var/www/", ...

7

Great, thanks a lot!! That solved the problem, although the text is now soooo long…

8

Yes, I can imagine… :stuck_out_tongue: Using --webroot-path with multiple -d switches would be better, but is currently broken: https://github.com/letsencrypt/letsencrypt/issues/1802

9

The u'domain.tld' type error should be solved in the current version on GitHub, which will be the basis of the forthcoming 0.4.0 release; with that release, other workarounds shouldn’t be necessary. But please let us know if anyone comes across this kind of problem after that.