Getssl client: verify step not succeeding

Server
1

Hello,
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 acme-staging.api.letsencrypt.org is trying to connect to port 80.

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

Thanks.

2

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
2 Likes
3

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