A little over a month ago, the folks at LetsEncrypt sent out a blog entry that claimed "Let’s Encrypt is happy to announce full support for IPv6".

"Full support" is a little short on specifics, and I've made some vendors cringe in these last years by asserting that "IPv6 support" means "works perfectly when executed on a single-stacked IPv6 host, with no IPv4 configured". Our use case for IPv6 at $DAYJOB is driven by IPv4 address space exhaustion, so a requirement that a host be dual-stacked doesn't get us where we want to be since the whole goal of the exercise is to be free of the dependency on that pesky now-exhausted IPv4 free pool.

I figured I'd put LetsEncrypt to the test, by attempting to run it on a single-stacked SmartOS SmartMachine. For good measure I decided to run a cacheing nameserver with no forwarders configured on the same (single stacked IPv6) machine, the better to make sure that all the dependencies were not only configured for dual stack, but reachable via a delegation chain that was suitably dual stacked.

Full of optimism, I went to LetsEncrypt's getting started page. I already have a workflow figured out that requires minimal deviation from my established X.509 certificate handling practices, but I figured I'd give it a try using their documented n00b procedures. Cool, they recommend certbot. Bummer, https://dl.eff.org is single stacked IPv4. Guess I won't be downloading it from there (I really expect better of the EFF than to not be serving content over IPv6 in late summer 2016).

Downloaded certbot-auto on a legacy dual-stacked machine and copied it in, then ran it. Cool, it knows about pkgin on SmartOS. Didn't get too far though; while executing pipstrap.py it threw a "node name or service name not known" error.

Well, as they say on the web page, "If certbot does not meet your needs, or you’d simply like to try something else, there are many more clients to choose from below...".

Cool, there's one named GetSSL and it's written in bash(1). Sounds like just the ticket. And it's hosted on Github. Which would be great if github.com had an AAAA record (they don't). Looks like the other bash-based letsencrypt clients (acme.sh, letsencrypt.sh, gheift/letsencrypt.sh) are hosted on github too, so scratch that.

At this point I noticed that a whole bunch of the recommended clients are actually hosted on github, so rather than goofing around further with trying to bootstrap the system software based solely on layer 3 reachability of its hosting provider, I figured I would throw in the towel and copy in the acme-tiny configuration that I use elsewhere for getting letsencrypt certs signed.

Ran my wrapper scripts... and, hurray! Got a cert signed by the LetsEncrypt staging environment (bogus) CA, then repeated the task pointing at the real (production) environment.

So, the LetsEncrypt folks pass the sniff test for "supports IPv6" (congratulations! you make me happy!), even if all the places they recommend you download their software from... don't. How one might solve this problem is left as an exercise to the reader.