Getssl client: verify step not succeeding


first of all, thanks to the Let’s Encrypt initiative and all the thousand hands making it fly!

I’m using getssl because I think it most suits my needs. I’m running a web server with Debian Jessie. The server provides various services on non-standard ports. To get the challenge working, I have set up a vhost which holds only the .well-known/acme-challenge directory, and listens on port 443. (I don’t intend to ever open port 80 to the public).

To get the first challenge check to succeed I have configured the CHALLENGE_CHECK_TYPE to be “https”. This worked ok. (and I can verify using curl or wget the challenge file is there.)

But then, the verification step fails. Using with the -d (debug) switch reveals that the server is trying to connect to port 80.

Did anybody have a similar issue (with this client) and knows how to solve it?



Let’s Encrypt will always try to connect to port 80 for the HTTP challenge (which is the one that uses .well-known/acme-challenge). There’s nothing getssl or any other client can do to change this. I’m not sure what that option is even for… The TLS-SNI challenge works over port 443, but I don’t think getssl supports it. So your options are:

  • Use the DNS challenge
  • Open port 80 (even if only to serve a redirect to HTTPS)
  • Use a different client


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