It's arguably true that we set out to build some of the more complicated pieces of the client first, when we could have tried with simpler versions that simply

It's arguably true that we set out to build some of the more complicated pieces of the client first, when we could have tried with simpler versions that simply ignored important parts of the HTTPS deployment task. But the traditional UNIX philosophy has not been working well for TLS to date, and certificates are hard to do right in a simple way. If every web developer and sys admin needs to know about the following things: - how to get a cert from us - how to bind a privileged port (:80 or :443) or reconfigure a webserver to prove domain control - the difference between end-entity certificates, CA certificate chains, "combined" end-entity and CA chains, and the weird heisenbugs you can get by getting them mixed up - how to handle the need to renew certificates periodically - the HTTP secure cookie flag - the HSTS header - redirects from HTTP to HTTPS - the Content-Security-Policy: upgrade-insecure-requests directive - OCSP stapling - the tradeoffs involved in ciphersuite tuning Then we are never going to have a universally encrypted and secure Web. So we set out to build a client that will, as it matures, get all of those things right for you. Meanwhile, the Python client does support console-only (-t) or non-interactive (pass in flags to avoid all questions) modes of operation. As we get to a 1.0 release, we expect those modes will be more robust and documented / discoverable for those who want them. But we think that many web developers will be happier to not have to know the difference between a cert, a cert chain, and a full chain.