On 2017-04-25, Adam Thompson <athom...@athompso.net> wrote: > On 2017-04-25 05:27, Stuart Henderson wrote: > >> Firstly, with dns-01 challenge you can get a certificate for a server >> which doesn't allow external access at all (the request and challenge >> can be done with completely separate machines than the certificate >> is for). >> >> Secondly, some environments permit inbound connections but require >> a proxy for outbound access from a DMZ. In a hosting environment, >> restricting outbound access is often more important than inbound. > > While it's possible that this was the case, the fact the OP was even > asking the question in the first place strongly suggests that this is > not his situation. > > I stand by my statement that just buying a cheap SSL cert will, for > anything other than the simple case of an online, directly-connected, > webserver, be cheaper than the labour required to obtain a LetsEncrypt > certificate. > > From what I've read so far, you'd have to be *really* committed to > LetsEncrypt to go to the bother of using any of the alternate challenge > protocols.
It's not that hard with some clients, especially with DNS hosted at a provider that has an API that the client already supports (or with nsupdate). If it's a one-off, I agree a cheap SSL cert is often easier. But the work that's involved is manual and needs doing at renewal (generate key/csr, get payment approval, login to CA's website, order, enter card details, manually handle CA's DNS/email auth, copy cert into place, figure out which chain certs are needed if the CA changed them, fix things if you messed up with the keys). Multiply that by a few domains, especially when they need renewing at different times, and it gets to be a real pain. More so when browsers push harder and the validity of certs gets reduced in length across the board. So with LetsEncrypt and especially non-http challenges it's often more of a faff to setup initially, but that's once only, amortised across multiple domains, in theory the only thing you're likely to need to do later is update the agreement URL. (And you don't have to worry about unscrupulous registrars trying to rip you off by autorenewing at several times the usual cost, hi g*d***y). > In all the situations where one person could complete the > process themselves, that person is highly likely to simply be directly > connected anyway - so why bother? I usually only let webservers connect out to specific IPs, which doesn't work for connecting to letsencrypt's API servers, currently on akamai and moving around. Punting the requests to a proxy lets you to restrict by domain name on the proxy instead. > Once the entire CA industry moves towards ACME (if that happens) then I > can see a number of situations where those alternate challenge protocols > will be useful and/or required, but for a LetsEncrypt certificate? It > just doesn't seem worthwhile. Especially when the cost of a > single-hostname SSL cert (which meets the needs of many users) is now > somewhere below US$5/year! > > And neither of us addressed the fact that for a server that's "behind a > corporate firewall", there's a good chance that it's not even using a > legit gTLD/ccTLD, which means getting an external domain-validated SSL > cert for it will be (or should be!) impossible in the first place. It may well be "www.$somecompany.com" on a DMZ behind a corporate firewall. And/or it may be run on multiple machines for failover and need the cert on all of them, here it's often more straightforward to do the auth from a management host (dns challenge is really needed for this) and push out the cert and keys across from config management. * If you want to do dns-01 challenge with acme-client, you'll need to use Kristaps' version for now, base acme-client only supports the standard http challenge type. The UI isn't the simplest; use '-t dns-01', then it outputs "dns-01 domainname token.key", then you convert token.key into a suitable format for a DNS TXT record: "echo -n token.key | sha256 -b | tr -d = | tr + - | tr / _" Get the record to the nameserver, then send the whole "dns-01 domainname token.key" line back to acme-client, and cross fingers. If there are too many errors you'll lock yourself out for a period, so test with the staging server first.
