Caddy git trunk on Linux. Caddyfile:
rendezvo.us {
bind 2001:470:8a59::27
root /srv/http
tls admin@rendezvo.us
}
Obviously, it’s defined as an IPv6-only site. However, when I try to start Caddy with no ACME files…
[root@igor caddy]# caddy Activating privacy features...2016/08/17 00:18:51 [rendezvo.us] failed to get certificate: acme: Error 400 - urn:acme:error:connection - Could not connect to http://rendezvo.us/.well-known/acme-challenge/Gk4rVaw8EM6tue8L7S7V_ztOIrE2A6kV9D_-eGck7hI Error Detail: Validation for rendezvo.us:80 Resolved to: 70.21.201.174 2001:470:8a59::26 Used: 70.21.201.174
It’s true that the connection failed - because despite resolving to both IPv6 and IPv4, the acme connection inexplicably chose (only) IPv4, when the site is running on only IPv6. (Ignore the fact that the target IP doesn’t match the one I’m binding to…this is being front-ended by sslh @ 2001:470:8a59::26 which transparent proxies to 2001:470:8a59::27.)
Even more interesting, if you force the site to IPv4 and let it get through Automatic HTTPS setup via ACME, you can then start it up as IPv6-only just fine (which goes without saying, I suppose, except I wonder what will happen when the cert expires… 
This is an issue because I spent 6 hours jumping through IPv6 NAT hoops trying to get a proper dual-stack configuration behind sslh going…unsuccessfully. I finally figured out that the best current solution is to run two instances of Caddy, one on IPv4 bound to a specific address and another on IPv6 bound to another specific address. This can be done pretty cleanly by using an environment variable in the Caddyfile like so:
rendezvo.us {
bind {$ADDRESS}
root /srv/http
tls admin@rendezvo.us
}
Set ADDRESS in your startup process (I use systemd’s [Service]Environment= method) and voila - as clean as you’re going to get until Caddy can natively bind to multiple addresses.
Rodney