TypeError: coercing to Unicode: need string or buffer, NoneType found


I’m trying to renew a certificate, which I understand is as simple as re-running the same letsencrypt-auto command again, but am getting the error:

TypeError: coercing to Unicode: need string or buffer, NoneType found
Please see the logfiles in /var/log/letsencrypt for more details.

However the log (below) is of no help. Any ideas ? This is Fedora Core 21, I’m using :

./letsencrypt-auto -vv --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly -d domain.info -d www.domain.info --authenticator webroot --webroot-path /home/my-web-root/here/

(this is -vv output). The last part of the log is

2015-11-08 15:15:18,500:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-11-08 15:15:18,886:DEBUG:requests.packages.urllib3.connectionpool:“GET /directory HTTP/1.1” 200 263
2015-11-08 15:15:18,910:DEBUG:root:Received <Response [200]>. Headers: {‘Content-Length’: ‘263’, ‘Expires’: ‘Sun, 08 Nov 2015 15:15:18 GMT’, ‘Strict-Transport-Security’: ‘max-age=604800’, ‘Server’: ‘nginx’, ‘Connection’: ‘keep-alive’, ‘Pragma’: ‘no-cache’, ‘Cache-Control’: ‘max-age=0, no-cache, no-store’, ‘Date’: ‘Sun, 08 Nov 2015 15:15:18 GMT’, ‘X-Frame-Options’: ‘DENY’, ‘Content-Type’: ‘application/json’, ‘Access-Control-Allow-Origin’: ‘’, ‘Replay-Nonce’: ‘XXXXXXXXXXXXXX’}. Content: '{“new-authz”:“https://acme-v01.api.letsencrypt.org/acme/new-authz",“new-cert”:“https://acme-v01.api.letsencrypt.org/acme/new-cert”,“new-reg”:“https://acme-v01.api.letsencrypt.org/acme/new-reg”,“revoke-cert”:"https://acme-v01.api.letsencrypt.org/acme/revoke-cert”}'
2015-11-08 15:15:18,933:DEBUG:acme.client:Received response <Response [200]> (headers: {‘Content-Length’: ‘263’, ‘Expires’: ‘Sun, 08 Nov 2015 15:15:18 GMT’, ‘Strict-Transport-Security’: ‘max-age=604800’, ‘Server’: ‘nginx’, ‘Connection’: ‘keep-alive’, ‘Pragma’: ‘no-cache’, ‘Cache-Control’: ‘max-age=0, no-cache, no-store’, ‘Date’: ‘Sun, 08 Nov 2015 15:15:18 GMT’, ‘X-Frame-Options’: ‘DENY’, ‘Content-Type’: ‘application/json’, ‘Access-Control-Allow-Origin’: '
’, ‘Replay-Nonce’: ‘YYYYYYYYYYYYYYYYYYYY’}): '{“new-authz”:“https://acme-v01.api.letsencrypt.org/acme/new-authz",“new-cert”:“https://acme-v01.api.letsencrypt.org/acme/new-cert”,“new-reg”:“https://acme-v01.api.letsencrypt.org/acme/new-reg”,“revoke-cert”:"https://acme-v01.api.letsencrypt.org/acme/revoke-cert”}'
2015-11-08 15:15:18,960:DEBUG:letsencrypt.cli:Exiting abnormally:
Traceback (most recent call last):
File “/root/.local/share/letsencrypt/bin/letsencrypt”, line 11, in
File “/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/cli.py”, line 1140, in main
return args.func(args, config, plugins)
File “/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/cli.py”, line 490, in obtaincert
_auth_from_domains(le_client, config, domains, plugins)
File “/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/cli.py”, line 310, in _auth_from_domains
lineage = _treat_as_renewal(config, domains)
File “/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/cli.py”, line 230, in _treat_as_renewal
config, domains)
File “/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/cli.py”, line 204, in _find_duplicative_certs
candidate_names = set(candidate_lineage.names())
File “/root/.local/share/letsencrypt/lib/python2.7/site-packages/letsencrypt/storage.py”, line 438, in names
with open(target) as f:
TypeError: coercing to Unicode: need string or buffer, NoneType found

Synology NAS using LE as a CA Signing Authority?
Exception when running letsencrypt-auto

This was issues/1195
and the work around there was helpful.

Delete from etc letsencrypt folder : renewal, archive, live, csr, keys to recover


I can
confirm this bug to centos 7 as well.
After deleting the folders tomC mentoned,
the installation is successful.
However, the site is still not available via https


There could be many reasons for that. Best to start a new thread, but it’s likely your web server is simply not configured correctly (not all the lets-encrypt options will set this up for you, and most of them are on alpha quality according to the docs).


Github Issue: https://github.com/letsencrypt/letsencrypt/issues/1195

I am running CentOS7 and also had this problem. I am new to linux and apache, so i thought it might help to explain the root of this problem in plain language: The error is simply Let’s Encrypt complaining about missing files. If anything inside /etc/letsencrypt/ has been modified (deleted, renamed, etc) it will get upset and fail to run. I am not sure why, but thats whats happening.

The most common reason for this to occur is likely if you renamed/deleted a folder containing your certificate. Let’s Encrypts default behavior is to place your issued certs in /etc/letsencrypt/live in a folder with the common name of the certificate, such as “www.domain.com”.

I disliked this and renamed the folder to “www” for shorthand. This prevented the client from running.

There are two solutions I know of, the first is described on the GitHub issue:

  1. For every certificate in /live/ there will be matching files/folders in /archive/ and /renewal/. For every certificate that you have modified or deleted in /live/, delete the corresponding files/folders in /archive/ and /renewal/.

If you are unsure of what folders need to be deleted, or this is not working, entirely delete the following folders in

/etc/letsencrypt/: renewal, archive, live, csr, keys

Note that this deletes your certificates and private keys, so you will need to get new ones. DONT delete the account folder.

  1. The other option is to return all the files you moved and rename them to the original names. In my case, this was easy as it just involved changing one folder name. However if you have deleted files or forgot your changes, this wont be an option.

I am not sure if this is reasonable behavior by the client. In my opinion, it seems ridiculous that you cant rename your certificate folders or files in /live/

But either way, that is the solution.