Renewal does not work. It hangs when trying to letsencrypt renew

Please fill out the fields below so we can help you better.

My domain is: kumkju.com

I ran this command: letsencrypt, letsencrypt renew, letsencrypt certonly

It produced this output: no output. It hangs.

My operating system is (include version): Ubuntu 16.04 LTS

My web server is (include version): Apache 2.4.18

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

This is the var/log/letsencrypt.log after trying letsencrypt

/var/log/letsencrypt/letsencrypt.log [----] 0 L:[ 1+34 35/ 35] (9263/9263b) [][X]
2016-10-05 13:05:37,736:DEBUG:letsencrypt.cli:Root logging level set at 30
2016-10-05 13:05:37,738:INFO:letsencrypt.cli:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-10-05 13:05:37,739:DEBUG:letsencrypt.cli:letsencrypt version: 0.4.1
2016-10-05 13:05:37,740:DEBUG:letsencrypt.cli:Arguments: []
2016-10-05 13:05:37,741:DEBUG:letsencrypt.cli:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,P
2016-10-05 13:05:37,746:DEBUG:letsencrypt.cli:Requested authenticator None and installer None
2016-10-05 13:05:38,317:DEBUG:letsencrypt.display.ops:Single candidate plugin: * apache
Description: Apache Web Server - Alpha
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = letsencrypt_apache.configurator:ApacheConfigurator
Initialized: <letsencrypt_apache.configurator.ApacheConfigurator object at 0x7f0a36f27b90>
Prep: True
2016-10-05 13:05:38,319:DEBUG:letsencrypt.cli:Selected authenticator <letsencrypt_apache.configurator.ApacheConfigurator object at 0x7f0a36f27b90> and installer <letsencrypt_apac
2016-10-05 13:05:51,741:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {}
2016-10-05 13:05:51,746:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-10-05 13:10:06,413:DEBUG:requests.packages.urllib3.connectionpool:“GET /directory HTTP/1.1” 200 280
2016-10-05 13:10:06,417:DEBUG:root:Received <Response [200]>. Headers: {‘Content-Length’: ‘280’, ‘Expires’: ‘Wed, 05 Oct 2016 13:10:06 GMT’, ‘Boulder-Request-Id’: 'shdihbnFXNgosO
2016-10-05 13:10:06,418:DEBUG:acme.client:Received response <Response [200]> (headers: {‘Content-Length’: ‘280’, ‘Expires’: ‘Wed, 05 Oct 2016 13:10:06 GMT’, ‘Boulder-Request-Id’:
2016-10-05 13:10:06,418:DEBUG:root:Requesting fresh nonce
2016-10-05 13:10:06,419:DEBUG:root:Sending HEAD request to https://acme-v01.api.letsencrypt.org/acme/new-reg. args: (), kwargs: {}
2016-10-05 13:10:06,420:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-10-05 13:14:21,108:DEBUG:requests.packages.urllib3.connectionpool:“HEAD /acme/new-reg HTTP/1.1” 405 0
2016-10-05 13:14:21,113:DEBUG:root:Received <Response [405]>. Headers: {‘Content-Length’: ‘91’, ‘Pragma’: ‘no-cache’, ‘Boulder-Request-Id’: 'qtqOJNLYwjYJbeGai4rdhoJZMBHnzdG9mn92w
2016-10-05 13:14:21,114:DEBUG:acme.client:Storing nonce: 'bM\x81\xcb\x16\xae\x9c\xeb\xb8\x10#\xc6:Q\xb7\xc1;)V8\xd4\xf5f"\xedDn\xbe5{#\xb4’
2016-10-05 13:14:21,117:DEBUG:acme.jose.json_util:Omitted empty fields: authorizations=None, certificates=None, agreement=None, key=None
2016-10-05 13:14:21,117:DEBUG:acme.client:Serialized JSON: {“contact”: [“mailto:norman@kumkju.com”], “resource”: “new-reg”}
2016-10-05 13:14:21,118:DEBUG:acme.jose.json_util:Omitted empty fields: x5c=(), x5tS256=None, cty=None, jku=None, x5u=None, x5t=None, crit=(), kid=None, alg=None, jwk=None, typ=N
2016-10-05 13:14:21,122:DEBUG:acme.jose.json_util:Omitted empty fields: jku=None, x5tS256=None, cty=None, x5c=(), x5u=None, x5t=None, crit=(), nonce=None, kid=None, typ=None
2016-10-05 13:14:21,123:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-reg. args: (), kwargs: {‘data’: '{“header”: {“alg”: “RS256”, “jwk”: {“e”:
2016-10-05 13:14:21,125:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-10-05 13:18:36,344:DEBUG:requests.packages.urllib3.connectionpool:“POST /acme/new-reg HTTP/1.1” 201 557
2016-10-05 13:18:36,352:DEBUG:root:Received <Response [201]>. Headers: {‘Content-Length’: ‘557’, ‘Expires’: ‘Wed, 05 Oct 2016 13:18:36 GMT’, ‘Boulder-Request-Id’: 'j6s9YteGrken_D
2016-10-05 13:18:36,353:DEBUG:acme.client:Storing nonce: '\x16\xb3\xb8!\xe0\x0b\x0c\x98q\x18\xff\xfe\xb0\xab\xc8\xbc\x80\xa7\x0fL\x14\xd4\x02\xa1X\x10\x06\xcf\x043\xc0l’
2016-10-05 13:18:36,354:DEBUG:acme.client:Received response <Response [201]> (headers: {‘Content-Length’: ‘557’, ‘Expires’: ‘Wed, 05 Oct 2016 13:18:36 GMT’, ‘Boulder-Request-Id’:

This is a common issue with broken IPv6 configurations on your end. See this issue for more details.

Disabling IPv6 on your end, or fixing your IPv6 configuration should solve this. You can use something like ping6 acme-v01.api.letsencrypt.org to verify that IPv6 connectivity is working.

1 Like

Thank you. But now my apache is broken. I guess I need to fix it first. Is letsencrypt apache plugin change something on apache?

The apache plugin is what you’d use when you want the client to automatically change your configuration to enable HTTPS, so yes, it adds a new vhost as part of the process. Renewal, on the other hand, doesn’t make any persistent configuration changes other than changing the certificate and key files. It does (gracefully) reload apache as part of the renewal, so if your configuration was in a broken state already, the renewal might have been what made that visible to you.

Can you provide more details about the errors you’re seeing? Error messages, logs, etc.

Thank you. It works again. I did not know that the plugin writes the rewrite conditions. The first time I was installing letsencrypt I already have written my own vhost config and was using certonly param. But that is a lot easier and much more convenient. This is really an awesome product, for that reason alone.

I cannot trace back the error. I tried to delete all letsencrypt stuff and rewrote the vhost back to http connection only to get the site working again. Apache did not create errors but I was not even able to ping on port 80. Maybe I forgot to delete something?!

Now I tested the renewal with the dry run. The following message was written in red:

Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443…
Wat did I make wrong? The vhost has a ServerName but no ServerAlias?!

Can you verify the following things?

  • Each file in your apache configuration contains at most one <VirtualHost> tag, and
  • each <VirtualHost> tag contains at least a ServerName directive.

Both of these things could cause this error. If it’s not that, I’d probably need to see the vhost configuration to figure this out.

Dry-Run works fine now. The error occurs when ServerAlias is not set.

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