Trouble renewing certificate

Dears,

I run a webserver (Ubuntu 14.04 with Apache 2.4.7) with one IP and five subdomains (subdomain0.domain.tld (with domain.tld as an alias), subdomain1.domain.tld, subdomain2.domain.tld …). All subdomains (and the domain) exclusively use one (WORKING) letsencrypt-generated certificate (SAN) which I need to renew now (with letsencrypt 0.5.0). “Exclusively” means that each of the (multiple) vhost.conf files for the subdomains redirects to my (single) ssl.conf files. I tried to renew the certificate in two different ways, each leading to a different error.

  1. If I use “letsencrypt-auto renew --apache --dry-run” I get the following output:

    Updating letsencrypt and virtual environment dependencies…
    Requesting root privileges to run with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt renew --apache --dry-run


    Processing /etc/letsencrypt/renewal/subdomain4.domain.tld.conf

    2016-04-06 12:47:49,928:WARNING:letsencrypt.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/subdomain4.domain.tld.conf produced an unexpected error: Failed to run Apache plugin non-interactively
    Missing command line flag or config entry for this setting:
    We were unable to find a vhost with a ServerName or Address of subdomain1.domain.tld.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    Choices:
    [‘00-default-subdomain0.conf | Multiple Names | | Enabled’,
    ‘02-subdomain2.conf | subdomain2.domain.tld | | Enabled’,
    ‘03-subdomain3.conf | subdomain3.domain.tld | | Enabled’,
    ‘04-subdomain4.conf | subdomain4.domain.tld | | Enabled’,
    ‘01-subdomain1.conf | subdomain1.domain.tl | | Enabled’]
    (The best solution is to add ServerName or ServerAlias entries to the VirtualHost directives of your apache configuration files.). Skipping.
    ** DRY RUN: simulating ‘letsencrypt renew’ close to cert expiry
    ** (The test certificates below have not been saved.)

    All renewal attempts failed. The following certs could not be renewed:
    /etc/letsencrypt/live/subdomain4.domain.tld/fullchain.pem (failure)
    ** DRY RUN: simulating ‘letsencrypt renew’ close to cert expiry
    ** (The test certificates above have not been saved.)
    1 renew failure(s), 0 parse failure(s)

subdomain1.domain.tl” in the last line of the “Choices” (which I cannot choose from) is not a typo. It is also the very ServerName of which letsencrypt is unable to find a corresponding vhost. However, I double-checked my vhost files (unencrypted and encrypted) and they do not contain the typo. I also grep’ed the whole server and did not find any file containing the misspelled ServerName.

  1. If I use “letsencrypt-auto renew --apache --dry-run” I get a dialog about which names I would like activate HTTPS for. It gives me all my five subdomains (spelled correctly) and my domain and I choose all of them. Then I get a list of my vhost.conf files together with the corresponding ServerNames (or “Multiple Names” when a ServerAlias is present in the vhost.conf file). Here “subdomain.domain.tl” is misspelled again. In the dialog I get here I am asked to choose a virtual host for each (sub)domain. Then I get the following error message (all with server names spelled correctly):

    Failed authorization procedure. domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld’, subdomain3.domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld’, subdomain4.domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld’, subdomain0.domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld’, subdomain2.domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld’, subdomain1.domain.tld (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found ‘subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld’

    IMPORTANT NOTES:

    • The following errors were reported by the server:

      Domain: domain.tld
      Type: unauthorized
      Detail: Correct zName not found for TLS SNI challenge. Found
      ’subdomain1.domain.tld, subdomain2.domain.tld,
      subdomain4.domain.tld, subdomain0.domain.tld, domain.tld,
      subdomain3.domain.tld’

      Domain: subdomain3.domain.tld
      Type: unauthorized
      Detail: Correct zName not found for TLS SNI challenge. Found
      ’subdomain1.domain.tld, subdomain2.domain.tld,
      subdomain4.domain.tld, subdomain0.domain.tld, domain.tld,
      subdomain3.domain.tld’

      Domain: subdomain4.domain.tld
      Type: unauthorized
      Detail: Correct zName not found for TLS SNI challenge. Found
      ’subdomain1.domain.tld, subdomain2.domain.tld,
      subdomain4.domain.tld, subdomain0.domain.tld, domain.tld,
      subdomain3.domain.tld’

      Domain: subdomain0.domain.tld
      Type: unauthorized
      Detail: Correct zName not found for TLS SNI challenge. Found
      ’subdomain1.domain.tld, subdomain2.domain.tld,
      subdomain4.domain.tld, subdomain0.domain.tld, domain.tld,
      subdomain3.domain.tld’

      Domain: subdomain2.domain.tld
      Type: unauthorized
      Detail: Correct zName not found for TLS SNI challenge. Found
      ’subdomain1.domain.tld, subdomain2.domain.tld,
      subdomain4.domain.tld, subdomain0.domain.tld, domain.tld,
      subdomain3.domain.tld’

      Domain: subdomain1.domain.tld
      Type: unauthorized
      Detail: Correct zName not found for TLS SNI challenge. Found
      ’subdomain1.domain.tld, subdomain2.domain.tld,
      subdomain4.domain.tld, subdomain0.domain.tld, domain.tld,
      subdomain3.domain.tld’

      To fix these errors, please make sure that your domain name was
      entered correctly and the DNS A record(s) for that domain
      contain(s) the right IP address.

Since the webserver and the current certificate (expiring soon) are working fine, my A record is not the problem. Also my (sub)domain names seem to be entered correctly since in every instance the “Domain” is included in the list of (sub)domains given under “Details”. It also doesn’t seem to be a problem of order, since in the last instance (subdomain1…) the domain corresponds to the first domain in the list.

What then is the real problem? Is this a DNS, SAN, Apache or spelling problem? Any suggestions appreciated! Thank you very much in advance!

Well, for the tls-sni-01 challenge, Apache needs to serve a temporary certificate with (a part of) the challenge response as the SNI host.. So apparently, when requesting a "random" hostname on your server, it responds with your "standard" certificate. For some reason, your Apache doesn't answers to that random hostname with the challenge.

So the fact you see your "wanted" hostnames isn't good, it's bad actually :stuck_out_tongue:

Would the redirect commands in the vhosts (from HTTP to HTTPS) cause this behaviour?

No, I don’t think so.

The Apache authenticator would generate a separate vhost configuration file for the tls-sni-01 challenge. Most likely, I think, is that this configuration file isn’t properly read/implemented in your Apache.

If you run the client with -vv you’ll get a lot of extra data. Somewhere in that bunch of extra lines (look carefully!), there’s a debug message about the generation of that separate vhost configuration file I mentioned earlier.

Okay, this is what the log said after “certonly” in verbose mode (took out the time stamps and my identity and present here only one round of the tls-sni-01 challenge). I can’t read this, but maybe you can?

DEBUG:root:Sending GET request to https://acme-staging.api.letsencrypt.org/acme/authz/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq9M1Yzqw. args: (), kwargs: {}
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
DEBUG:requests.packages.urllib3.connectionpool:"GET /acme/authz/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw HTTP/1.1" 200 1278
DEBUG:root:Received <Response [200]>. Headers: {'Content-Length': '1278', 'Expires': 'Thu, 07 Apr 2016 13:31:45 GMT', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Link': 'https://acme-staging.api.letsencrypt.org/acme/new-cert;rel="next"', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Thu, 07 Apr 2016 13:31:45 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'RUQ7T6S71Aowg_GAoVslSPqbdLyjt2J5rqa370C5wtZ'}. Content: '{"identifier":{"type":"dns","value":"subdomain1.domain.tld"},"status":"invalid","expires":"2016-04-13T14:51:21Z","challenges":[{"type":"dns-01","status":"pending","uri":"https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158645","token":"6B6G0CY-b98dlepT12pQqfidqSWJsi2jRq09qQZx1Sg"},{"type":"http-01","status":"pending","uri":"https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158646","token":"pX68wX16kyPE1purl-rRLGIfhr3PZVK9eyvfzI23Zpw"},{"type":"tls-sni-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Correct zName not found for TLS SNI challenge. Found \'subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld\'"},"uri":"https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158647","token":"UVAywj4YMj411Th_0Gl9K_b7JDH-T-mXPdHJoq9TJpc","keyAuthorization":"UVAywj4YMj411Th_0Gl9K_b7JDH-T-mXPdHJoq9TJpc.vMHsPu3A3enVu6o1vBEWmWyHEiV6sVrQbblEH1dEvpk","validationRecord":[{"hostname":"subdomain1.domain.tld","port":"443","addressesResolved":["my.ip.my.ip"],"addressUsed":"my.ip.my.ip"}]}],"combinations":[[2],[1],[0]]}'
DEBUG:acme.client:Received response <Response [200]> (headers: {'Content-Length': '1278', 'Expires': 'Thu, 07 Apr 2016 13:31:45 GMT', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Link': 'https://acme-staging.api.letsencrypt.org/acme/new-cert;rel="next"', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Thu, 07 Apr 2016 13:31:45 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'RUQ7T6S71Aowg_GAoVslSPqbdLyjt2J5rqa370C5wtZ'}): '{"identifier":{"type":"dns","value":"subdomain1.domain.tld"},"status":"invalid","expires":"2016-04-13T14:51:21Z","challenges":[{"type":"dns-01","status":"pending","uri":"https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158645","token":"6B6G0CY-b98dlepT12pQqfidqSWJsi2jRq09qQZx1Sg"},{"type":"http-01","status":"pending","uri":"https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158646","token":"pX68wX16kyPE1purl-rRLGIfhr3PZVK9eyvfzI23Zpw"},{"type":"tls-sni-01","status":"invalid","error":{"type":"urn:acme:error:unauthorized","detail":"Correct zName not found for TLS SNI challenge. Found \'subdomain1.domain.tld, subdomain2.domain.tld, subdomain4.domain.tld, subdomain0.domain.tld, domain.tld, subdomain3.domain.tld\'"},"uri":"https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158647","token":"UVAywj4YMj411Th_0Gl9K_b7JDH-T-mXPdHJoq9TJpc","keyAuthorization":"UVAywj4YMj411Th_0Gl9K_b7JDH-T-mXPdHJoq9TJpc.vMHsPu3A3enVu6o1vBEWmWyHEiV6sVrQbblEH1dEvpk","validationRecord":[{"hostname":"subdomain1.domain.tld","port":"443","addressesResolved":["my.ip.my.ip"],"addressUsed":"my.ip.my.ip"}]}],"combinations":[[2],[1],[0]]}'
DEBUG:acme.challenges:dns-01 was not recognized, full message: {u'status': u'pending', u'token': u'6B6G0CY-b98dlepT12pQqfidqSWJsi2jRq09qQZx1Sg', u'type': u'dns-01', u'uri': u'https://acme-staging.api.letsencrypt.org/acme/challenge/ZBDd_mm5I6tN5sF4eVu1wJnU72FGRcpPIVvq3P4Yzqw/3158645'}

No, that has nothing to do with Apache configuration files. I meant something like this:

2016-04-07 17:10:58,563:INFO:letsencrypt.auth_handler:Performing the following challenges:
2016-04-07 17:10:58,563:INFO:letsencrypt.auth_handler:tls-sni-01 challenge for example.com
2016-04-07 17:10:59,245:DEBUG:letsencrypt_apache.tls_sni_01:Adding Include /etc/apache2/vhosts.d/le_tls_sni_01_cert_challenge.conf to /files/etc/apache2/httpd.conf
2016-04-07 17:10:59,246:DEBUG:letsencrypt_apache.tls_sni_01:writing a config file with text:
 <IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName 74d68ad5aadaabd044995b228057fef8.060689accbedba8fd8339934d04eec69.acme.invalid
    UseCanonicalName on
    SSLStrictSNIVHostCheck on

    LimitRequestBody 1048576

    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /var/lib/letsencrypt/jo-teggxkHYM3cOx9x-XrOJVyEAN1bVSx4uOz7chPZs.crt
    SSLCertificateKeyFile /var/lib/letsencrypt/jo-teggxkHYM3cOx9x-XrOJVyEAN1bVSx4uOz7chPZs.pem

    DocumentRoot /var/lib/letsencrypt/tls_sni_01_page/
</VirtualHost>

</IfModule>

2016-04-07 17:10:59,888:DEBUG:letsencrypt.reverter:Creating backup of /etc/apache2/httpd.conf
2016-04-07 17:11:03,241:INFO:letsencrypt.auth_handler:Waiting for verification...

You should check if those paths are correct and if Apache will include that configuration file properly.

Okay, I got it. The le logs weren’t to helpful. So I played around with my ssl configuration … and broke it. For the meantime, I installed a selfsigned certificate. Uninstalled le, reinstalled it (in a better location). And continued looking for the source of the problem.

I finally remembered reading that le cannot handle multiple vhosts in one file which is how I configured my ssl. I had ignored this because my configuration used to work with my former le certificate and I thought that putting all ssl vhosts into one file was the only way to go with an Apache webserver (which is wrong as I know now). When I divided my vhosts between the same number of files (and left my ssl details within the vhost called something-default-ssl.conf), everything continued working fine. And the le dry-run (and later the real one) finally succeeded.

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