My hosting provider, if applicable, is: server4you
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
a) The Web site uses a self-signed cert.
b) The challenge is easy accessible vi https.
c) curl is using port 80 as default, which is of course not helpful
d) I use the getssl and changed the following default (*):
As far as I know, getssl client doesn’t support TLS challenge, it only supports HTTP and DNS challenges so if you want to use getssl you need your apache listening on port 80 to get your certificate, well, the web server can listen on port 80 but you could have your domain redirected via apache directives to your secure site on port 443, Let’s Encrypt will follow the redirect and will accept your self-signed cert but it needs to connect to port 80 first.
The other option is to use DNS challenge, no need to have a web server, just be able to create a TXT record on your DNS server. If you use a DNS server that doesn’t support some kind of API to automate the process could be a pain.
If you still want to use TLS with some bash client, you could try acme.sh but again, as far as I know, this client only supports TLS challenge in standalone mode, this means that your web server should be down, acme.sh will start its own “web server” to resolve the challenge and once done it drops this “web server” and you should start your own web server again.
Hm. Maybe I don’t understand what Apache’s ‘redirect’ means. I have several domains serviced by Apache (fehcom.de, fehcom.net, aqmail.org) with different DNS A records pointing to same IP (unfortunately, my provider does not support IPv6).
Thus there is NO http redirect. DNS TXT records need to be created by a Web panel only.
But actually: I don’t see the use case. Why should this domain to be reachable only via port 80? Curl does not allow to include a port number on call (I tried this; however the --port =https does not work; IMHO a major failure):
1921 # check that we can reach the challenge ourselves, if not, then error
1922 if [[ ! “$(curl --proto =https -k --silent --location “$wellknown_url”)” == “$keyauthorization” ]]; then
1923 error_exit "for some reason could not reach $wellknown_url - please check it manually"
1924 fi
1925 fi
I guess, with some more flexibility, we are able to overcome this situation.
This redirects tell the client (web browser or in this case, Let's Encrypt validator) that when it connects to http://fehcom.net it should follow the redirect to https://fehcom.de
The directive in Apache should look like this:
Redirect permanent / https://www.fehcom.net/
When Let's Encrypt try to validate your domain with http challenge it will reach your web server and your web server will show the Redirect and the Location (pointing to your https site) that the client should follow, something like this: