Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add alternate hostname for http challange #242

Closed
axos88 opened this issue Nov 25, 2016 · 9 comments

Comments

@axos88
Copy link

@axos88 axos88 commented Nov 25, 2016

As you (LE) seem to be strongly concerned over adding the option to adding the possibility to do the challange over alternate ports (some of which I are valid, but all of which can be handled in a secure way nonetheless - such as using a DNS record and other solutions to address have been already stated in here), I propose to add at least an alternate hostname for the http challange.

This would enable us to add a specific virtual host, answering to *.acme.invalid and redirect that to a specific wwhost, which can be used by the certbot to place the necessary files to complete the challange.

It is currently not possible to add global aliases in nginx for example, so this way it would be possible to issue certificates without having to either have certbot modify the nginx config (yes, it's possible to do that in a zero-downtime way, but it makes my sysadmin inner self scream - my software reconfiguring my other software...), or have to add the location redirect to all vhosts, which is not as easy as it sounds when they get generated by different software components.

If we'd say that the challange has to respond for the Host header of example.com.acme.invalid OR example.com (current) that would make all our lives easier, while maintaining a) backward compatibility b) ease of use for the average joe.

Not as easy as with a custom port, but still a lot more easy to automate.

@axos88

This comment has been minimized.

Copy link
Author

@axos88 axos88 commented Nov 25, 2016

@kelunik

This comment has been minimized.

Copy link

@kelunik kelunik commented Nov 26, 2016

@axos88 You can redirect /.well-known/acme-challenge/* to another (virtual) host at any time. The validation authority will follow any redirects. You could also use includes to define a common web root just for /.well-known/acme-challenge, that's what I usually do.

@axos88

This comment has been minimized.

Copy link
Author

@axos88 axos88 commented Nov 26, 2016

As stated, this is not that easy to do when the server configuration is generated by different software components (chef cookbooks) that one does not have control over. Unfortunately there are no global aliases / redirects in nginx, only per server.

This would also mean that in order to use letsencrypt, one has to MODIFY the current configuration, rather than ADD a new virtualhost declaration. Modifying something generated by some other actor is always a bad idea (this is one of the reasons conf.d directories exist btw).

@axos88

This comment has been minimized.

Copy link
Author

@axos88 axos88 commented Nov 26, 2016

For example: I have an automated installer for an web application, running over let's say ruby on rails. The application is obviously unaware, and should NEVER be aware how it's exposed to the internet. Thus it is unaware of how its SSL certificate is obtained and installed (normally it wouldn't even run on https, but would rely on a forward proxy to terminate the ssl connection, and forward it using http, but that's another matter).

Now my automated installer installs this software, and also installs and configures nginx for forward proxying. It will configure the nginx vhost, and other things that are needed. I don't know that LE exists, my installer just asks for the path to a certificate and a key.

Now I sell my software to a third party, who uses my installer (chef cookbook) to install my software on THEIR infrastructure. THEY are smarter then me, and know that LE exists, and want to use it to create the certs.

Current options:

  1. They start hacking around the nginx configuration generated by my installer and add the alias - not good, the next update will overwrite their changes, and they won't be able to renew
  2. They stop nginx every time they need to upgrade the certs for the duration of the verification - unacceptable
  3. They use dns challenge if they can - usually it cannot be automated, or is a great effort to add dns records automatically.
  4. They use the tls challenge (although it doesn't supprot nginx yet), and they modify its configuration during every verification, reloading its configuration, etc. Can easily create problems if someone is maintaining the server at the same time, etc.

OR: They also create a virtualhost accepting connections for *.acme.invalid once during installation, redirect it to a webroot, and have the verification client drop files into that webroot. Configure it once, and it works. Unnecessary to modify configuration files generated by other installers, unnecessary to keep reloading the nginx configuration all the time, less possibility for failure.

@axos88

This comment has been minimized.

Copy link
Author

@axos88 axos88 commented Nov 26, 2016

And let's face it, validation requests to a vhost have NOTHING to do with the software who serves the content on that server. They are intended for a totally different actor (certbot), thus they should be routed to a different vhost, not be mingled into all the other ones as locations and aliases, and such.

@kelunik

This comment has been minimized.

Copy link

@kelunik kelunik commented Nov 26, 2016

unnecessary to keep reloading the nginx configuration all the time

You have to do that anyway for Nginx to use the new certificate instead of the old one.

Anyway, this is something that should be in the official repository instead and on the ACME mailing list.

@axos88

This comment has been minimized.

Copy link
Author

@axos88 axos88 commented Nov 26, 2016

unnecessary to keep reloading the nginx configuration all the time
You have to do that anyway for Nginx to use the new certificate instead of the old one.

True true, but at least you are not modifying configuration.

@mvdkleijn

This comment has been minimized.

Copy link

@mvdkleijn mvdkleijn commented Nov 29, 2016

hmmm.. its not a huge issue for me (anymore). I've simply decided that all visitors to my sites are redirected to 443, except for the challenge which is still available on 80. A script then refreshes the certs once every 90 days automatically via port 80 and does a graceful restart of Apache.

@cpu

This comment has been minimized.

Copy link
Member

@cpu cpu commented Apr 4, 2017

This repository is deprecated & un-maintained. Closing this issue. If applicable, please move discussion to the replacement IETF owned repo and the mailing list.

@cpu cpu closed this Apr 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.