LE client needs to bind to port 80, which I'm already using

Help
1

I just set up Let's Encrypt for the first time, using the instructions provided:
./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory auth

During the install process, I got this error:

The program apache2 (process ID 31582) is already listening on TCP
port 80. This will prevent us from binding to that port. Please stop
the apache2 program temporarily and then try again.

I had to stop Apache, run LE, and start Apache again. This isn't acceptable in a production environment.

If there's another method I can use to generate the certificates, it should be the default behaviour.

Paul

2 Likes
3

Using ./letsencrypt-auto -d paulschreiber.com auto gives the same port-in-use warning as before.

4

You could use the docker version and change your apache configuration to proxy the verification requests to the webserver running in the docker container.

I described something similar with nginx in another topic

Also take a look at the webroot and manual modes in the documentation

webroot: (–webroot-path should be pointed to your public_html) you specify a directory where the files for verification are added by the client without starting a webserver at all

manual: (-a manual) Requires to copy and paste commands into a new terminal session. Allows to run client on machine different than target webserver, e.g. your laptop.

2 Likes
5

i see same error/problem with nginx, on old git (28-october)
webroot is the way.

6

Small typo, you use at the end of your line: ‘auto’. That must be ‘auth’.

7

@let’s encrypt dev-team:
why not using a less essential port (e.g. 81 or 82) to provide the challenge code?
Sure this will need some firewall and routing config, but in that case we could use the well-working standalone client for cert renewal while keeping our e.g. apache running for ports 80 and 443.

2 Likes
8

Or let us specify a port to issue the challenge code, so we could use these on NATed servers by setting up port forwarding appropriately.

4 Likes
9

Just generated my first cert and this is really intrusive, it doesn’t bind to a single IP either so if you have multiple webservers bound to different IPs then it forces you to close those too.
Having the ability to bind to another port would be a great idea.

2 Likes
10

I propose to solve this issue as follows:

Note: you may want to change 9999 to a different value

 

  1. make sure apache modules mod_proxy and mod_proxy_http are enabled

a2enmod proxy proxy_http

  1. add the following to the mod_proxy config file (usually /etc/apache2/mods-enabled/proxy.conf)

<IfModule mod_proxy.c> ProxyPass "/.well-known/acme-challenge/" "http://127.0.0.1:9999/.well-known/acme-challenge/" retry=1 ProxyPassReverse "/.well-known/acme-challenge/" "http://127.0.0.1:9999/.well-known/acme-challenge/" <Location "/.well-known/acme-challenge/"> ProxyPreserveHost On Order allow,deny Allow from all Require all granted </Location> </IfModule>

  1. if you have a local firewall running: make sure it won't block access from localhost to localhost:9999

  2. run letsencrypt-auto with the http port set to 9999

letsencrypt-auto --agree-dev-preview --agree-tos --renew-by-default --standalone --standalone-supported-challenges http-01 --http-01-port 9999 --server https://acme-v01.api.letsencrypt.org/directory certonly -d your-domain-here.tld

 

That way your standard apache will recognize the request from the letsencrypt server and forward it to the letsencrypt client if it's running.

Note: if the letsencrypt client is not running your local apache will recognize that during the proxy call and re-try to contact the local letsencrypt client only after a timeout of a minute. You can find a corresponding error message in the log. So if you try to "test" the setup using your browser make sure to wait a minute before actually running the letsencrypt client.
Again: If you manually call an url beginning with /.well-known/acme-challenge/ without having a letsencrypt client running at that moment and you then do not wait for a minute afterward => then the letsencrypt server may not be able to contact the letsencrypt client.
So just don't manually try to load an url beginning with /.well-known/acme-challenge/ and apache won't block the request from the letsencrypt server.
Added parameter retry=1 so this should not be an issue anymore :innocent:

9 Likes
11

Thank you for your help.
But in my case, I have to use 2 servers because LE is not supported by my nas so.
My nas (syno) has a reverse proxy and redirects http requests on the port 9999 of my second server (ubuntu)
On this server, I execute LE with your paramaters.
But it doesn’t work and failed with :
“Failed authorization procedure. www.domaine.fr (http-01): connection :: The server could not connect to the client for DV :: Could not connect to http://www.domaine.fr/.well-known/acme-challenge/Ktk5ca5PLu7IZi2Uh4Duo1grTt9_0P8g406b7gTnx48”

:cry:

12

@mafiaman42:

please don’t hijack this thread
in your specific case you probably need to make sure that your nas does the proxy redirection mentioned in step 2 above => but of cause not with http://127.0.0.1:9999/.well-known/acme-challenge/ as the target but with http://put-the-name-of-your-second-server-here:9999/.well-known/acme-challenge/

1 Like
13

+1 for this improvement!

It’s very inconvinient that you have to stop your web server to use acme.

IMHO this improvement is must do before going public.

14

[quote=“c0ba, post:13, topic:2739”]
It’s very inconvinient that you have to stop your web server to use acme.
[/quote] that’s why i use webroot authentication plugin

For letsencrypt client’s webroot authentication plugin see

15

After following this, LE stops complaining about port 80 but still complains about 443. How can this be improved, so that I can use LE without stopping apache on port 80/443?

16

did you add the parameters

--standalone --standalone-supported-challenges http-01 --http-01-port 9999

when calling letsencrypt-auto ?

17

I did only used --http-01-port 9999. I tried webroot now and it worked without any problems. Thx anyway.

18

@thomas @mikeskril That option is not supported yet by the spec and the server always uses 80 / 443.

https://github.com/letsencrypt/letsencrypt/issues/1357#issuecomment-153940848

1 Like
19

Below is what I do now to get certs without stopping apache.

in /etc/letsencrypt/cli.ini I have:

authenticator = webroot                                                                                                                        
webroot-path = /var/www/                                                                                                                       
server = https://acme-v01.api.letsencrypt.org/directory                                                                                        
domains = mydomain.foo                                                                                                                       
renew-by-default                                                                                                                               
agree-dev-preview

running LE:

./letsencrypt-auto --config cli.ini auth

I will let cron run every 60 days to renew the certs.

I think thats the best solution for me at the moment.

2 Likes
20

That’s fine, yeah. :+1:

1 Like
23

guys.
this is meant as an howto so that people can easily find out how to go on if they receive the error message “LE client needs to bind to port 80, which I’m already using”

you’re now writing about totally different things but that’s just not fair for other users.
they will have a hard time now to find the guide above in this thread now.

if you have questions, ask them publicly on a new thread.
if you want to have a private chat, i propose to start one with each other.
you may want to delete your messages above to clean up this.
thanks.

1 Like