3 ms·

But it's wrong to build an giant automated system. Had we completely forgotten the UNIX way? Build a (letsencrypt-nosudo) first. Let it do one task and do it w

But it's wrong to build an giant automated system. Had we completely forgotten the UNIX way? Build a (letsencrypt-nosudo) first. Let it do one task and do it well - obtain a signed certificate. Let it have the simplest interface possible - command-line options and exit status with stderr output for details. Make it fast, small and robust and that'll be pinnacle of usability for those gray-bearded old-fashioned sysadmins. Then build letsencrypt-magic-pixie-dust that'd use the said script to obtain a certificate and then bake cookies, feed the pigeons and wreck your webserver configuration as it seems fit. Let it still have command-line options as the only UI. Then build letsencrypt-ui-{cli,gtk,ncurses,qt,android,wpf,whatever} to control that beast, so even a non-techie grandma could be able to get everything for her blog in a single tap. Why bundle all this in a single giant monolithic[1] project is beyond me. ___ [1] Not in sense of internal stucture, but in sense of how it's facing the end-user. And AFAIK there's single bin/letsencrypt (and letsencrypt-auto shell script wrapper)

pde3 11y ago
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.

pde3 11y ago

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.