@Spork_Schivago, thanks for testing this; could you send us some more information about how you used the client before and how you ran letsencrypt-auto renew, and also exactly what error messages it printed or logged (if any)?
@mpqft, that's true at present -- what client and settings were you using to get your ECDSA key? Our Python letsencrypt client doesn't support ECDSA keys, so it wouldn't even have realized that you might want to use one.
1 Like
@mattanja, if my hypothesis about your situation is right, you should delete the [[webroot_map]] line from the bottom of your domain.de.conf file and then try the renewal again. (But can you confirm that you didn’t use webroot when you originally got the domain? You said you originally used apache? My hypothesis is based on an idea about what would happen if you tried to switch from non-webroot to webroot by editing the config file just before renewal.)
Another equivalent way of fixing it might be
letsencrypt certonly -a webroot -w /var/www/domain.de/web -d domain.de
assuming that the cert only covers domain.de and not also www.domain.de or other names. (If there are other names, they should be explicitly specified with additional -d flags at the end.) That would modify the domain.de.conf in a way that should cause plain letsencrypt renew to succeed for future renewal attempts.
I actually used the official letsencrypt client 0.4.0 with the webroot plugin and my own CSR. I have generated a few ECDSA certificates already. So if I understand correctly, it’s currently not possible to do letsencrypt renew with custom CSR?
@mpqft, oh, I didn’t think about the custom CSR method at all. No, if you do letsencrypt renew with a custom CSR you will get
raise errors.Error("Currently, the renew verb cannot be used when "
"specifying a CSR file. Please try the certonly "
"command instead.")
As the error message will suggest, you might want to try certonly; I think the differences between the two are unlikely to affect your use case. There is no difference on the CA back end between certonly and renew; the CA doesn’t record your request as a “renewal” in one case but not the other, it just has to do with how the client determines its own configuration when requesting the certificate.
You can add --renew-by-default (which we are renaming to --force-renew) if you want to skip certonly's interactive prompt about whether to save the new cert as a replacement for an existing cert.
Edit: one limitation of certonly --force-renew is that it’s not able to determine when the existing certificate is near expiry, so if you ran this automatically every day, you would quickly hit the rate limit because a new certificate would be requested every day. We don’t have any functionality implemented currently that combines checking when an existing certificate is near expiry with using a specified CSR file for the new certificate request. Hopefully we’ll either add this soon or some other cert management features that we implement will be more useful for scripting this check yourself.
1 Like
@schoen Thank you! Yes, I think you’re right. After removing the [[webroot_map]] line at the bottom of the renewal config I got a different error (not finding the correct credentials in the webroot).
2016-02-20 00:36:05,190:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/domain.com.conf produced an unexpected error: Failed authorization procedure. domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://domain.com/.well-known/acme-challenge/xxxx-xxxx [x.x.x.x]: 404. Skipping.
However, executing the certonly for the same domain worked fine
/opt/letsencrypt/letsencrypt-auto certonly --keep-until-expiring -w /var/www/domain.com/web -d domain.com
I may still have some misconfiguration in my renewal files and will continue testing as soon as other certs are due.
For the renewal files being generated for new certificates I think the content was not generated correctly according to the way the original cert was created. In any case it would help a lot to have a documentation for the parameters that can be used there - I couldn’t seem to find a page discribing the format. Thanks!
Edit: I only now realized that the renewal file will be updated by such an action - which is good to know. The part that I probably got wrong (missing documentation?) is that the webroot_path must end with a comma (?) and/or that the entry was added to the [[webroot_map]] part:
webroot_path = /var/www/domain.com/web, [[webroot_map]] domain.com = /var/www/domain.com/web
Ugh… testing that was a mistake.
I only have 5 certs. 3 were issued new earlier today. Then I went and ran “renew” because my two old certs are about to expire. Only I was Instantly rate limited without the oldest certs actually renewing. That cert will now likely expire before the rate-limit resets 
Renew should be intelligent and operate on certs from oldest to newest… I can’t even tell what order it goes in, it doesn’t appear alphabetical or date.
Really though that shouldn’t matter, the rate limits are just too low for renewals. It wouldn’t be so bad if we had wildcard certs, but with every sub-domain being a separate cert, five is not sufficient specifically because of the renewal issue.
Soon I’ll have 6 sub-domains and frankly I have better things to do than login to my server twice a week apart to renew them every 60 days.
1 Like
You know you can request SAN certs, right? as in, multiple domains on one cert, counting as just one against the rate limit? Just specify multiple -d options on the command line.
1 Like
—@:/opt/letsencrypt# ./letsencrypt-auto renew
Checking for new version...
Requesting root privileges to run letsencrypt...
/root/.local/share/letsencrypt/bin/letsencrypt --no-self-upgrade renew
Processing /etc/letsencrypt/renewal/--it.conf
2016-02-24 10:06:46,994:WARNING:letsencrypt.cli:An error occured while parsing /etc/letsencrypt/renewal/--it.conf. The error was Expected a numeric value for http01_port. Skipping the file.
Processing /etc/letsencrypt/renewal/--y.it.conf
Processing /etc/letsencrypt/renewal/--l.conf
Processing /etc/letsencrypt/renewal/owncloud.---.conf
2016-02-24 10:06:47,016:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/owncloud.---.conf produced an unexpected error: The webroot plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('d does not exist or is not a directory',). Skipping.
Processing /etc/letsencrypt/renewal/test.--.conf
Processing /etc/letsencrypt/renewal/---.com.conf
2016-02-24 10:06:47,022:WARNING:letsencrypt.cli:An error occured while parsing /etc/letsencrypt/renewal/---.com.conf. The error was Expected a numeric value for http01_port. Skipping the file.
The following certs are not due for renewal yet:
/etc/letsencrypt/live/---.it/fullchain.pem (skipped)
/etc/letsencrypt/live/---l/fullchain.pem (skipped)
/etc/letsencrypt/live/test.---.it/fullchain.pem (skipped)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/owncloud.---/fullchain.pem (failure)
Additionally, the following renewal configuration files were invalid:
/etc/letsencrypt/renewal/---.it.conf (parsefail)
/etc/letsencrypt/renewal/---.com.conf (parsefail)
ssl per owncloud was exipred 3 days ago (my fault on to a cron script)
Looks like the webroot was moved? So you need to edit the config file.
Having just installed letsencrypt on a Centos server running cPanel / WHM and obtained certificates that all work perfectly - I tested the renew option - it also ran perfectly - well done guys!
I’ve renewed two separate certificates recently. The first I renewed on 2/17 and everything worked but today I got another email about that certificate expiring and it still lists the original expiration date (3/6).
I’m getting reproducible parsefail error messages. It seems like config files from prior versions of the letsencrypt client fail. Those are the ones without the webroot_map section.
Here’s a diff of a working vs a non-working (diff working.conf non_working.conf, I replaced the domain names but nothing else was changed.
The forum appears to have a bug. I only have this one link in the post yet it complains that I have a limit of 2. So you’ll have to assemble the link by yourself. Replace space by slash here:
FreeBSD user, just updated the pkg to 0.4.0. My certs were created with the 0.3.0 pkg, using webroot. I changed all of my apache port 80 vhosts to 301 redirects to https, with HSTS and can’t use letsencrypt renew. The renew attempts to use webroot on http, and I don’t see a method in the renewal conf to change to https.
Error: 2016-02-29 09:31:53,578:WARNING:letsencrypt.cli:Attempting to renew cert from /usr/local/etc/letsencrypt/renewal/domain.net.conf produced an unexpected error: Failed authorization procedure. domain.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://domain.net/.well-known/acme-challenge/XXXX. Skipping.
That’s a standing bug in the mailer - it can’t recognize whether or not you renewed the certificate.
Thanks, I’ll just ignore the emails after I’ve renewed for now.
@ulikoehler, do you have any more information about the specific reason for the parsefail in the Let’s Encrypt error logs?
@schoen I just (re-)tried running “letsencrypt renew” as root. For some reason, today there is an error message (I’m not sure if it wasn’t there yesterday or if I just missed it !?!?):
2016-03-01 03:23:24,252:WARNING:letsencrypt.cli:An error occured while parsing /etc/letsencrypt/renewal/mydomain.conf. The error was Expected a numeric value for http01_port. Skipping the file.
In the config: “http01_port = None”. I use (and have always used) only webroot auth.
When I manually set the http01_port to 80, letsencrypt renew works again. Maybe you could allow http01_port to be None for backwards compatibility?
Best regards, Uli
@ulikoehler, fortunately or unfortunately that’s a known issue
Hopefully we can get it fixed soon (precisely by allowing http01_port to be None, as you suggest).
I believe the problem results when a user created a cert with standalone prior to November and is now trying to use letsencrypt renew without having used letsencrypt certonly -a standalone in between. (It should be possible to renew in this combination of circumstances without an error, but it’s apparently not.)