Expanding existing ceritificate fails tls-sni-01


Hi, I originally issued a certificate only for mydomain.xyz. I would now like to expand it to cover www.mydomain.xyz also. However, when I run ./letsencrypt-auto -d mydomain.xyz -d www.mydomain.xyz, and agree to expand the certificate, it errors out saying:

Failed authorization procedure. mydomain.xyz (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, www.mydomain.xyz (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

 - The following errors were reported by the server:

   Domain: mydomain.xyz
   Type:   urn:acme:error:connection
   Detail: Failed to connect to host for DVSNI challenge

   Domain: www.mydomain.xyz
   Type:   urn:acme:error:connection
   Detail: Failed to connect to host for DVSNI challenge

I have replaced all occurrences of the real domain. Honestly, I don’t even know if its a security risk to use the real domain name. I can provide the real output of the command I ran in case that is needed.


The real domain name would be useful for people to check.

Generally the problem indicates that your domain can’t be reached properly via https. Does the https domain work OK for you ? and are you using anything like cloudflare on your domain ?



I have been using my domain just fine for about a week now.
The instance is just a bare Linux machine hosted on Amazon’s cloud with a public IP.

On the DNS side, I just added two DNS A records having twoseven.xyz and www.twoseven.xyz pointing to this public IP.

edit: When I run a normal HTTP webserver, I am able to access both www.twoseven.xyz and twoseven.xyz via curl. My browser fails www.twoseven.xyz because it attempts to redirect me to HTTPS which is not running.

When I run my HTTPS server, curl fails both www and non-www domains. This is probably because letsencrypt’s CA is not part of its CA bundle.
However, I have access to https://twoseven.xyz via browser but not to https://www.twoseven.xyz which predictably throws an error saying the certificate was only issued for twoseven.xyz and not www.twoseven.xyz.

Given that I’m able to access my HTTP page via curl, I don’t think there is a DNS problem.
It might have something to do with the fact that letsencrypt-auto is starting some sort of server on specific ports?

I have the following redirects applied to my server:

80 -> 8080
443 -> 8084


Well, it’s probably not a problem at Boulders end:

osiris@desktop ~ $ openssl s_client -connect twoseven.xyz:443 -servername twoseven.xyz
connect: Connection refused
osiris@desktop ~ $ 

This is the IP address I get: twoseven.xyz. 1799 IN A


This probably happened because I was testing stuff locally.

I will re-enable the HTTPS server now. You should be able to access it with that command line.


OK, good… The TLS-SNI-01 challenge needs to have access to the HTTPS server. The Apache plugin of the official client will generate a self signed certificate with a variant of the challenge token as the common name (and/or subject alt name, I dunno exactly) and serve this (very) temporary certificate… Then, Boulder will access your server and try to access this CN/subAltName… And then revert the Apache configuration back to the original…


I didn’t follow everything you just said…but I think I can summarize my problem in layman terms.

I restarted my machine, commented out the port forwards and then ran letsencrypt-auto certonly -d twoseven.xyz -d www.twoseven.xyz and that worked fine. I now have an extended ceritificate for both twoseven.xyz and www.twoseven.xyz.

To me, it appears that letsencrypt-auto listens on some port for connections and because of my port forwards, this failed.

I’m not sure if this is already documented, but if it isn’t, you may want to add this to your document so that others will know that letsencrypt-auto uses ports 80 and/or 443 as part of its operations :frowning: . I spent considerable amount of time trying to get to the bottom of this.


Depends on the plugin/authenticater you’re using. When using certonly mode, the webroot plugin uses the existing nginx or Apache webserver and the standalone plugin uses a build in webserver (which, ofcourse, can’t run at the same time as nginx or Apache)… The fully automated Apache plugin (so without certonly) uses, which doesn’t come as a surprise, the existing and running Apache…

And this is all pretty well documentated.


Ah, I see.

One of the early commands I used to generate my original certificate was ./letsencrypt-auto --standalone-supported-challenges tls-sni-01 certonly. I guess this updated the /etc/letsencrypt/renewal/mydomain.conf to use port 443.

I guess this meant that when I was attempting to expand my certificate, it tried to use the same authentication mechanism and that failed due to my port forward.


Yes, the tls-sni-01 challenge uses port 443. The http-01 challenge uses port 80.