Getssl for self-signed Web domains (on port 443)

Please fill out the fields below so we can help you better.

My domain is :

I ran this command: getssl -d

It produced this output:


response {
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:acme:error:unauthorized”,
“detail”: “Invalid response from “\u003c!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”\u003e\n\u003chtml\u003e\u003chead\u003e\n\u003ctitle\u003e404 Not Found\u003c/title\u003e\n\u003c/head\u003e\u003cbody\u003e\n\u003ch1\u003eNot Found\u003c/h1\u003e\n\u003cp””,
“status”: 403
“uri”: “”,
“token”: “BrblHkLOkwUB-YSoQlyvahRXXLyEMTPWOsgGCoU1Hlc”,
“keyAuthorization”: “BrblHkLOkwUB-YSoQlyvahRXXLyEMTPWOsgGCoU1Hlc.2og-NcxwiCz0rsczu1sa6VVfxOyC2-fMybwnpWFDlo0”,
“validationRecord”: [
“url”: “”,
“hostname”: “”,
“port”: “80”,
“addressesResolved”: [
“addressUsed”: “”
My operating system is (include version): Debian Wheezy

My web server is (include version): apache 2.2

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 :wink:
d) I use the getssl and changed the following default (*):

195 CA=“"

Unfortunately, curl insists to use port 80.

Any help is appreciated.


Hi @ErwinHo,

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 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, 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.

P.D. Thanks for the wonderful s/qmail :wink:


Hi sahsanu,

thanks for your reply (and liking s/qmail :slight_smile:

Hm. Maybe I don’t understand what Apache’s ‘redirect’ means. I have several domains serviced by Apache (,, 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.


What I mean with redirect is this.

This redirects tell the client (web browser or in this case, Let's Encrypt validator) that when it connects to it should follow the redirect to

The directive in Apache should look like this:

Redirect permanent /

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:

$ curl -I
HTTP/1.1 301 Moved Permanently
Date: Fri, 21 Apr 2017 19:39:00 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Sun, 09 Apr 2017 19:54:18 GMT
Content-Type: text/html;

Regarding this part, maybe @serverco (getssl's developer) could give you more info.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.