From valid status to invalid. (tls-sni-01): urn:acme:error:connection

During setup and testing of letsencrypt, I stopped receiving status “valid” and now receive status “invalid.” I did clone server images back and forth between 2 servers with different IP addresses, and I made an adjustment to DNS to redirect DNS for one host (eg: from one server to another while testing in an attempt to minimize risk to my production server. Here are details of the error messages:

(Log info) Response when I got certificate:

“status”:“valid”, <— VALID

(Log info) Response from CA, now that I cannot get certificate:

“status”:“invalid”, <— INVALID
“detail”:“Failed to connect to host for DVSNI challenge”

Error message at running letsencrypt:

Type: urn:acme:error:connection
Detail: Failed to connect to host for DVSNI challenge
2016-02-12 10:52:40,415:INFO:letsencrypt.auth_handler:Cleaning up challenges
Failed authorization procedure. (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge

As additional note, I am able to generate a certificate by using the manual plugin with the command

$ letsencrypt --manual

and following instructions. I tried installing it in the appropriate virtual host of the apache server using the same configuration generated automatically by the apache plugin. Steps taken

  1. created an ssl virtual host listening on port 443
  2. added the certificate/key
  3. included the ssl config file from letsencrypt

Although I was able to generate the certificate and the config was the same, the https site was still not working. I wonder if it is possible that the CA could have lost trust in my domain, and therefore stopped issuing certificates.

Any advice on how to correct this issue? Is there any way to “reset” the account? Should we move on and try to use a different CA? Could it be possible that having several hosts in different servers for the same DNS could affect the process of obtaining the certificate?

  • I am not using a CDN.
  • I am using goddady for DNS only.

Thanks for the help.

Hi @spanish_worker, maybe the DNS changes didn’t propagate yet? Do you know how long your DNS TTL value is?

Hi @schoen,

My TTL time is 1 hour. Like you, I initially though it could be a propagation problem, but I’ve had problems since Thursday. I’m starting to think it’s something else.

Also, I cannot generate an SSL cert for any subdomain (,, etc) from the server on which I initially installed letsencrypt.

I’m not sure what else to try, but I can tell you that the scenario of the CA losing trust in your domain doesn’t make sense to me. Maybe you could let us know more about how the HTTPS setup didn’t work for you and someone can try to help you debug that, because if the cert was issued successfully with manual, it should be possible to use it!

Hi @schoen,

I used 2 servers from the same domain ( I took the following steps:

  1. Using our hosting tools (Linode), I cloned the file system of production server A ( to server B

  2. On server B, I upgraded system software to Debian 8.0 and thoroughly tested critical LAMP-stack applications

  3. On server B, I installed LetsEncrypt using apt (I know Let Encrypt is in testing / stretch, but I preferred to use the package manager for convenience)

  4. Using DNS tools (GoDaddy), I created a DNS host record of type A which resolved to server B’s IP ( -> Server B’s IP)

  5. Using this new DNS host record ( and Lets Encrypt, I generated a new certificate and installed it on server B, with the following command:
    $ sudo letsencrypt --apache

  6. I tested it, and saw it running perfectly. I could connect to https//, and http// was redirected to https for the domain without problems.

  7. Then I performed the reverse of step 1: I cloned the file system of server B back to server A.

  8. After some DB config (not related with SSL), I tried obtaining a certificate using letsencrypt for my DNS ( I received the error descibed above.

To solve the problem, I’ve tried the following:

  • I modified the DNS A host record created in step 4 to point to server A ( -> Server A’s IP). That didn’t work, and when I pointed the DNS host record back to server B it didn’t work either. One interesting thing I noticed: the error which appears is ERR_CONNECTION_TIMED_OUT. This is what made me think something could be wrong with the SSL certificate or the CA trust. The URL http// loads in less than 0.3 secs, while requests for https// time out.

  • I tried to obtain a new certificate manually on Server A using a configuration similar to the one created automatically on Server B by the apache plugin.

  • I tried revoking the certificate in case it was corrupt or somehow interfering with obtaining new certs. I’m not sure this worked correctly.

  • I also tried removing and re-installing the letsencrypt package on Server A. This completed successfully, but did not solve the problem.

Thank you for you time. If you have any ideas on how to resolve this issue, I would be grateful.

Is server A also running Apache? Does Apache log any errors related to the configuration change attempts?

Can you connect to server A under the name? In HTTP, HTTPS, or both?

Hi @schoen,

Thanks for taking the time to reply to our questions. Your advice was helpful. It gave us some good starting points from which we dug deeper into our system configuration. In the end we discovered the problem was in our firewall setup. Everything is running well now.

Thanks again,


Cool, I’m glad you figured it out!