It produced this output: Domain: nas.aruzsi.hu
Type: tls
Detail: Failed to connect to 87.242.16.82:443 for TLS-SNI-01
challenge
(and that the same for all names)
My operating system is (include version): Ubuntu 16.04
My web server is (include version):
nginx, apache, lighttpd
My hosting provider, if applicable, is:
Digital Ocean and Google. Under DO it is working because it is different system than home network.
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
There is a HTTPS->HTTP proxy on my router. It is lighttpd. I want certs for my name based virtual hosts which are behind the router. Again: the HTTPS is on the router.
How can I do this?
I tried --manual and I think this will be the solution for me. Is that right?
That does not quite make sense. There should normally be nothing on your external interface listening on 80/443, unless you have explicitly configured forwarding from those ports to the servers on your internal network. So, with proper forwarding configuration, there should be no problems with the verification.
Alternatively you could just use DNS verification (supported by Perl, bash and go clients, as well as the online Certificate Wizard on ZeroSSL).
I don’t want forwarding because there are some devices which are not supported by HTTPS.
With my HTTPS frontend proxy I can use HTTPS with those devices.
I thing --manual will be usable for me.
Do you agree with me?
So I use --manual parameter.
I had to define one or more vhosts for HTTP serving .well-known/acme-challenge/<given_filename>.
The content of the <given_filename> is the filename.key which can be seen on the screen after --manual command line execution.
The router knows nothing about Letsencrypt scripts that’s why I use a Ubuntu Linux for using the letsencrypt script.
I don’t have any ideas (yet) about auto refreshing.
So I’ve got some A+ ranked encrypted front-end virtual hosts in front of my IoTs.
