Configuration Issues with TLS-SNI-01 Challenge on Apache Using certbot-auto

[grepnerd]

My domain is: www.an.org.uk

I ran this command: ./certbot-auto -d www.an.org.uk

It produced this output:
…
…
Domain: www.an.org.uk
Type: connection
Detail: Failed to connect to 80.67.93.213:443 for TLS-SNI-01
challenge

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. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

My operating system is (include version): Debian wheezy

My web server is (include version): Apache/2.2.22 (Debian)

My hosting provider, if applicable, is: not applicable

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

I tried this first when I had old Apache config with expired and wrong-domain certs. https://www.an.org.uk worked after adding a security exception in Firefox, so the address resolved and ssl worked.

The documentation seems to say that only port 80 is required to run certbot, so I removed all SSL config and reran certbot. But it still enabled SSL and used TLS-SNI-01, and fails in the same way. Running certbot-auto without -d is the same.

At various stages in the process I ran
me@remote:~$ openssl s_client -connect www.an.org.uk:443 and always got:
CONNECTED(00000003)
3073504960:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 7 bytes and written 305 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1489492584
Timeout : 300 (sec)
Verify return code: 0 (ok)

Obviously certbot can’t require a fully configured SSL. That’s what it’s there to create. But does it require some Apache SSL config to exist? Does it require an existing keypair to certify, or will it create one if not found?

[ahaw021]

hi @grepnerd

what is your understanding of how the TLS-SNI challenge works

Andrei

[grepnerd]

Thanks for reply Andrei. None at all. Happy to be sent to the right documentation page, if that will explain what is needed.

[grepnerd]

Well to keep the dialogue going, I understand that the TLS-SNI challenge is a way to show that I have control over the domain docroot, via the app I downloaded writing a file there. Obviously, with SSL, it could also show that I can encrypt it, i.e. that I can read my private key. I didn’t want to assume that you need a keypair first, so removed all SSL config on the assumption that certbot would then default to http port 80. Certbot is re-enabling SSL and then is unhappy in some way with what it does.

My main question is therefore: Does certbot create a keypair, or should I create one, uncertificated either by a CA or self? If the latter, how do I make the public key available, i.e. do I specify it in the Apache config?

[schoen]

@grepnerd

Well to keep the dialogue going, I understand that the TLS-SNI challenge is a way to show that I have control over the domain docroot, via the app I downloaded writing a file there. Obviously, with SSL, it could also show that I can encrypt it, i.e. that I can read my private key. I didn't want to assume that you need a keypair first, so removed all SSL config on the assumption that certbot would then default to http port 80. Certbot is re-enabling SSL and then is unhappy in some way with what it does.

Hi @grepnerd,

I'm going to work on some improved official documentation for this, but the HTTP-01 challenge is the one that works the way you've described. The TLS-SNI-01 challenge instead tries to configure a special certificate for a special hostname on your HTTPS listener. The apache plugin (which is used by default) can only use TNS-SNI-01.

To use port 80 with a created file for validation, you should be using the webroot plugin instead.

You can use -a webroot -i apache to try to use webroot to obtain the certificate and then apache to install it by editing your Apache configuration files for you. If you want to specify the web root directory on the command line, you can do so with -w.

[ahaw021]

hi @grepnerd

Almost there. Certbot will create a temporary server (based on python) and will create the SSL certificate using openssl.

Usually when using the TLS-SNI challenge the process is:

Turn off any web servers running (free port 443)
Run the TLS-SNI challenge
Once the challenge is complete start up the web server again

There are also HTTP and DNS challenges.

I usually specify one of these as they are less disruptive

Syntax:

Standalone

Use standalone mode to obtain a cert if you don’t want to use (or don’t currently have) existing server software. The standalone plugin does not rely on any other server software running on the machine where you obtain the cert.

To obtain a cert using a “standalone” webserver, you can use the standalone plugin by including certonly and --standalone on the command line. This plugin needs to bind to port 80 or 443 in order to perform domain validation, so you may need to stop your existing webserver. To control which port the plugin uses, include one of the options shown below on the command line.

    --preferred-challenges http to use port 80
    --preferred-challenges tls-sni to use port 443

It must still be possible for your machine to accept inbound connections from the Internet on the specified port using each requested domain name.

Manual

If you’d like to obtain a cert running certbot on a machine other than your target webserver or perform the steps for domain validation yourself, you can use the manual plugin. While hidden from the UI, you can use the plugin to obtain a cert by specifying certonly and --manual on the command line. This requires you to copy and paste commands into another terminal session, which may be on a different computer.

The manual plugin can use either the http or the dns challenge. You can use the --preferred-challenges option to chose the challenge of your preference. The http challenge will ask you to place a file with a specific name and specific content in the /.well-known/acme-challenge/ directory directly in the top-level directory (“web root”) containing the files served by your webserver. In essence it’s the same as the webroot plugin, but not automated. When using the dns plugin, certbot will ask you to place a TXT DNS record with specific contents under the domain name consisting of the hostname for which you want a certificate issued, prepended by _acme-challenge.

For example, for the domain example.com, a zone file entry would look like:

_acme-challenge.example.com. 300 IN TXT “gfj9Xq…Rg85nM”

Additionally you can specify scripts to prepare for validation and perform the authentication procedure and/or clean up after it by using the --manual-auth-hook and --manual-cleanup-hook flags. This is described in more depth in the hooks section.

Andire

[schoen]

Hi @ahaw021,

I believe you’re missing a big piece there, which is that the TLS-SNI-01 challenge is also supported by the apache plugin, not just by the standalone plugin! If you use apache (which may be suggested by default), it tries to reconfigure your existing Apache server to pass the TLS-SNI-01 challenge. Only standalone creates a separate temporary web server.

[ahaw021]

thanks @schoen

will review the docs a bti more

Andrei

[ahaw021]

@schoen

so the apache plugin is an authenticator and installer?

is there a way to run this plugin for installing only and authenticating using other methods? Not TLS-SNI?

Andrei

[schoen]

Yes, for example -a webroot -i apache can be used to authenticate using webroot and install using apache. (For people with an existing HTTP site, that might be a little more reliable than --apache, which tries to use Apache for both, at least if recent problems that people have had around --apache's TLS-SNI-01 support are an indication.)

[grepnerd]

Many thanks both.

So it seems that certbot will create a new keypair as well as certify it. I tried ‘preferring’ http but I only have the apache plugin.

Now I understand that certbot creates a temporary python server, I need to stop my webserver. Clearly this will be in the documentation and I should have read it more carefully. I’ll try it and report back with results.

[grepnerd]

Well, I stopped Apache and ran again, and got this.

./certbot-auto -d www.an.org.uk

-bash: ./certbot-auto: No such file or directory
root@grepnik:~# cd /usr/local/bin
root@grepnik:/usr/local/bin# ./certbot-auto -d www.an.org.uk
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for www.an.org.uk
Enabled Apache ssl module

We were unable to find a vhost with a ServerName or Address of www.an.org.uk.
Which virtual host would you like to choose?
(note: conf files with multiple vhosts are not yet supported)

1: default-ssl | | HTTPS |

Press 1 [enter] to confirm the selection (press ‘c’ to cancel): c
No vhost exists with servername or alias of: www.an.org.uk (or it’s in a file with multiple vhosts, which Certbot can’t parse yet). No vhost was selected. Please specify ServerName or ServerAlias in the Apache config, or split vhosts into separate files.
Falling back to default vhost *:443…
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.an.org.uk (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 80.67.93.213:443 for TLS-SNI-01 challenge

IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: www.an.org.uk
  Type: connection
  Detail: Failed to connect to 80.67.93.213:443 for TLS-SNI-01
  challenge

  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. Additionally, please check that
  your computer has a publicly routable IP address and that no
  firewalls are preventing the server from communicating with the
  client. If you’re using the webroot plugin, you should also verify
  that you are serving files from the webroot path you provided.

Offering default-ssl is presumably because I’ve removed all SSL config. So I should create a vhost for www.an.org.uk, with no SSL values? Or do you mean I need to use standalone.

And I still fail to connect. The TLS-SNI challenge requires that domain to be recognized on port 443, so I imagine that requires that minimal Apache config first. Will try that and report back.

Not expecting a reply due to timezone diffs but will go as far as I can.

[grepnerd]

No, that doesn’t work. Still only offers default-ssl. And Apache won’t start with an SSL config with all SSL keys missing. Trying standalone next.

[grepnerd]

Right, ran ./certbot-auto --standalone certonly -d www.an.org.uk
That ran and generated all required files as in https://certbot.eff.org/docs/using.html#where-are-my-certificates. I changed private key perms and set the SSL paths in Apache config. Bingo, I now get a nice green lock in my browser location bar!

I still don’t know what went wrong originally. You imply that Apache’s TLS-SNI-01 is flaky. Or was my Apache SSL config, or remains of previous config, or lack of required config, interfering?

So to run the python mini-server with Apache stopped, I now understand requires the standalone or manual option, and for the browser to be stopped when running. Is this the way you need to go when starting from a non-SSL-enabled browser? My questions are not now important but may help you see things from the POV of someone with a hazy grasp of the concepts, and maybe a different environment from the usual.

Lastly, can you confirm what I need to crontab a periodic renew command? I’m guessing it’s
certbot-auto renew --pre-hook “apachectl stop” --post-hook "apachectl start"
or does it need to include --standalone etc? It looks like I have to briefly suspend the webserver. I’d prefer not to, but if Apache is failing to do the TLS-SNI-01 challenge correctly I may have no option.

Many thanks to all, small donation has gone to Let’s Encrypt.

[schoen]

@grepnerd

Bingo, I now get a nice green lock in my browser location bar!

Great, congratulations!

I still don't know what went wrong originally. You imply that Apache's TLS-SNI-01 is flaky. Or was my Apache SSL config, or remains of previous config, or lack of required config, interfering?

All of these are possibilities. If you'd like to post these config files and log files, we could try to debug it. Development is still continuing on the Apache parser, so we might be able to contribute to making it more reliable.

So to run the python mini-server with Apache stopped, I now understand requires the standalone or manual option, and for the browser to be stopped when running. Is this the way you need to go when starting from a non-SSL-enabled browser? My questions are not now important but may help you see things from the POV of someone with a hazy grasp of the concepts, and maybe a different environment from the usual.

Most people are able to use webroot successfully if they have an existing web server. That might be the most popular option. apache probably works over 90% of the time if people are using configurations that are similar to the default suggested by Apache, but often has trouble with things like control panels, sharing hosting providers' setups, or heavily customized configurations.

Lastly, can you confirm what I need to crontab a periodic renew command? I'm guessing it's certbot-auto renew --pre-hook "apachectl stop" --post-hook "apachectl start" or does it need to include --standalone etc? It looks like I have to briefly suspend the webserver. I'd prefer not to, but if Apache is failing to do the TLS-SNI-01 challenge correctly I may have no option.

I think this can work this way. Some people make their own shell script like

`#!/bin/sh

apachectl stop
certbot renew
apachectl start`

or they use multiple commands in their crontab, separated by &&, something like

apachectl stop && certbot renew && apachectl start

[grepnerd]

Thanks Seth.

I’m happy to send you logs and config if they’re useful to you, but don’t need to know for my own sake. Let me know. One problem, probably not the main one, was that I had the domain as a single vhost, which certbot can’t yet parse. Even when I’d removed all SSL config it was a vhost in the default http config.

apachectl stop && certbot-auto renew && apachectl start is working. (Wouldn’t apachectl stop && certbot-auto renew; apachectl start be better?) I have to use certbot-auto as I didn’t install certbot. I’ve also tried it with -dry-run and that seems to show the TLS-SNI-01 challenge is now working.

Thanks once again!

[schoen]

Cool! Yes, I think the semicolon makes more sense than the second && there.

[grepnerd]

I thought coming from the EFF you might prefer the second &&, a hard-line “SSL or nothing”! Thanks again for your help.