Certbot: standalone should allow for alternate ports to bind to (but not authenticate to)

I believe the client already has the functionality you want, however, it's not presented in a very user friendly way as it's primarily been used for testing. The client has the following flags:

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

These flags allow you to specify for which ports the client sets up the domain validation challenges. In general, --tls-sni-01 should be the port you've routed incoming port 443 traffic to and --http-01-port should be the port you've routed incoming port 80 traffic to.

You would not need to use both flags, however, standalone by default performs challenges over 443. You can control this behavior by using the following flag:

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

I hope this helps!

Thanks, I'll try this tomorrow.

If this works, it should really be used as an example. It's much easier to restart a server to enable/disable proxy pass those ports than take everything offline to handle the verification process,

On Mar 22, 2016, at 3:16 PM, bmw [email protected] wrote:

I believe the client already has the functionality you want, however, it's not presented in a very user friendly way as it's primarily been used for testing. The client has the following flags:

--tls-sni-01-port TLS_SNI_01_PORT
Port number to perform tls-sni-01 challenge. Boulder
in testing mode defaults to 5001. (default: 443)
--http-01-port HTTP01_PORT
Port used in the SimpleHttp challenge. (default: 80)
These flags allow you to specify for which ports the client sets up the domain validation challenges. In general, --tls-sni-01 should be the port you've routed incoming port 443 traffic to and --http-01-port should be the port you've routed incoming port 80 traffic to.

You would not need to use both flags, however, standalone by default performs challenges over 443. You can control this behavior by using the following flag:

--standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
Supported challenges. Preferred in the order they are
listed. (default: tls-sni-01,http-01)
I hope this helps!

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

@jvanasco most people use the webroot plugin for that use case but yes, a proxy pass nginx example could be good. Feel free to make a PR that adds one to the docs; this is a sufficiently specialised use case that it should probably get a new section at the bottom of this file:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

However you can link to it from the existing Standalone section:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

We never heard back on this so I'm closing this issue. Please comment yelling at me if you'd like me to reopen.

This doesn't seem to work. @bmw

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

I see the authentication come through on port 80, however the python2 server did start up on 8484.

Nginx on Port 80

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

EDIT:
I see --tls-sni-01-port 5001 --http-01-port 5002 are both required!

Edit:
Im still none the wiser about to how have the standalone spin up a server and authenticate it

Also having issues with --tls-sni-01-port being ignored:

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

Note the request actually went to :443; I already have an HTTPS service running on :443 serving a different certificate. This does, however, work with renew.

Also have issue with --tls-sni-01-port:

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port/--tls-sni-01-port does not allow you to specify which port Let's Encrypt will connect to your server on. It will always use 80/443 respectively. All these flags allow you to do is control which ports Certbot listens on for plugins like standalone. This is useful if you're routing all port 80 traffic to port 8080 for example.

Yeah just a heads up you basically have to have port 80 accessible on the public IP address.

Something that is very lacking in the documentation, also means Let's Encrypt is not fit for purpose for a minority who can't control the incoming traffic on 80 (likely China / certain ISPs, Corp firewalls)

I read through a multiple of posts around this, almost seems like the ability to listen on 80 is considered a security gain / trusting measure because it's a privileged port on a Nix box.

Although seems let's encrypt don't recognise a use for certificates outside of web severs.. for example an email server etc, I might just want a quick boot up on port 7722 of a node app to handle the auth then shutdown as I don't run a web server.. but go figure.

Also means if you use automation like Chef for example you need to configure self signed certificates to be able to boot your nginx up given the configuration will have SSL on it must have at least a valid certificate.

Another option though if you run SSL only is to have a different web server serve 80 so it can ensure the certificate is downloaded before nginx try's to boot up. (Annoying setup)

My chef deployments now run through the following:

1. Install a self signed cert.
2. Boot nginx (with self cert)
3. Run cert
4. Symlink certs to my location
5. Reload nginx

Sent from my iPhone

On 15 Sep 2016, at 23:18, Brad Warren [email protected] wrote:

--http-01-port/--tls-sni-01-port does not allow you to specify which port Let's Encrypt will connect to your server on. It will always use 80/443 respectively. All these flags allow you to do is control which ports Certbot listens on for plugins like standalone. This is useful if you're routing all port 80 traffic to port 8080 for example.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

My web server listens on just one port for SSL connections and it's not the default 443. This is because the web server is behind a VPN service which allows for port forwarding, but doesn't allow port forwarding to port 80 or 443.

I'm trying to configure Let's Encrypt on this sever but in the logs I can see the acme client tries to connect on port 80 (which isn't accessible) and fails.

The error I get is a "Could not connect" status 400.

The "addressesResolved" value is correct, it's just that the "port" value is 80 and that all the urls are incorrect, because they should have my custom port specified, e.g. subdomain.domain.tld:1234 where 1234 is my custom port.

Is there a way to get it working with my setup?

From @gsdevme I got the impression I have to have port 80 publicly accessible...

_YOU HAVE TO HAVE PORT 80 PUBLICLY ACCESSIBLE FOR THE ACME SERVER TO VERIFY._

_THIS SOLUTION IS ONLY FOR RUNNING THE SERVER ON AN ALTERNATE PORT INTERNALLY, AND PROXYING FROM PORT80 TO THE ALTERNATE PORT._

_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._
_IF YOU DO NOT HAVE PORT80 ACCESSIBLE, YOU MUST USE DNS VERIFICATION._

Thanks for the reply @jvanasco. Too bad I can't specify custom ports. DNS verification isn't an option, because my Dynamic DNS provider http://freedns.afraid.org/ doesn't have an interface to automatically change TXT records.

@jvanasco Although I know you are totally right in your reply, it would be nice if we all calm down a bit before answering :D

Is there any time estimate when this will be configurable? Because I'm sure there's a lot of people running web servers on custom ports.

It's not configurable by design choice

Sent from my iPhone

On 14 Feb 2017, at 16:16, nvaert1986 notifications@github.com wrote:

Is there any time estimate when this will be configurable? Because I'm sure there's a lot of people running web servers on custom ports.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Same issue here, but for docker purpose.

Problem :
I don't want to package the certbot command with my webserver start command because it would always fail in non-prod environments.
So I want to build a specific image containing certbot which :

• ask for the certificate
• put the certificate inside a volume shared with my webserver

But this solution would work only if I stop my webserver's container, which is already binded on ports 80 and 443.

Solution :
Have the ability to change certbot ports. That would allow both certbot and webserver container to run in parallel.

Using DNS validation might solve the use case.

Sent from my iPhone

On 26 Feb 2017, at 23:32, NilsRenaud notifications@github.com wrote:

Same issue here, but for docker purpose.

Problem :
I don't want to package the certbot command with my webserver start command because it would always fail in non-prod environments.
So I want to build a specific image containing certbot which :

ask for the certificate
put the certificate inside a volume shared with my webserver
But this solution would work only if I stop my webserver's container, which is already binded on ports 80 and 443.

Solution :
Have the ability to change certbot ports. That would allow both certbot and webserver container to run in parallel.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

That could but this validation mode is not possible with standalone mode :/
(from : https://certbot.eff.org/docs/using.html#plugins)

Seems like a sensible middle ground without compromising security would be to allow discovery of the port via DNS SRV record. Letsencrypt could query a record like

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

on the domain and forward verification requests to the resulting address/port combination. This has the same benefits as DNS verification but without the drawback of requiring dynamic updates.

This would also mean users could easily centralise the management of their certificates if they wish, by referencing a central cert server.

How does allowing alternative ports compromise security?

This FOSS utility can help you to automate direct and indirect installs of ACME certificates to hosts that have TCP/443 port busy, or haven't TCP/443 port forwarded to them:

https://www.actiu.net/sesele/

Where is the documentation about how does SeSeLe works to allow to use
ports different than 443?.

On Oct 26, 2017 1:21 PM, "Narcis Garcia" notifications@github.com wrote:

This FOSS utility can help you to automate direct and indirect installs of
ACME certificates to hosts that have TCP/443 port busy, or haven't TCP/443
port forwarded to them:

https://www.actiu.net/sesele/

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

Please, go for SeSeLe forum's issue to allow better documentation coordination. (Answer is written in SeSeLe documentation now)

Perhaps this issue could be revisited? There is still no solution to the underlying issue. Yes, you can bind standalone to different port but that is useless because athority will still connect to 80/443.

If you have a server already running on 80/443 perhaps in production, you sometimes simply can't afford to free those ports. Manually placing challenge files could also be problematic (servers running in Docker).

The real solution here would be to specify a set of ports higher up (10 000+) where the authority would try to connect as a fallback or something like that. Perhaps there are security implications, not an expert.

What is the motivation for LE connecting only to ports 80/443? Is this a
formally documented limitation?

Can anyone point me to the right documents?

On Nov 30, 2017 6:31 AM, "cen1" notifications@github.com wrote:

Perhaps this issue could be revisited? There is still no solution to the
underlying issue. Yes, you can bind standalone to different port but that
is useless because athority will still connect to 80/443.

If you have a server already running on 80/443 perhaps in production, you
sometimes simply can't afford to free those ports. Manually placing
challenge files could also be problematic (servers running in Docker).

The real solution here would be to specify a set of ports higher up (10
000+) where the authority would try to connect as a fallback or something
like that. Perhaps there are security implications, not an expert.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

What is the motivation for LE connecting only to ports 80/443?
Is this a formally documented limitation?

Can anyone point me to the right documents?

It's a current CA/B forum requirement described here:
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

And explained in greater length here: https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100

As I understand with my poor english, in CA/Browser Forum they debated on september 2017 about the possible addition of TCP ports 25, 115, 22.
It seems that proposal was approved and should be effective this november.

A note from the future IF someone come here from Google (like me):

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

If you're using nginx you can use the nginx module with certbot certonly --nginx, it taps into the existing nginx server without any configuration.

Flag --http-01-port is not really intuitive also I could not find it in the help of the command and had to google for the flag --http-01-port. Would be nice to have the flag mentioned in the help.