With Android defragmentation with every phone manufacturer having their own Android builds, the responsiveness to updates for patches to stagefright etc have been slower.
How will Letsencrypt ensure that 3rd party Letsencrypt client implementations don’t fall behind ? Especially, for critical bugs fixes and security issues ?
@eva2000, I doubt we can control this in general. Hopefully people will be motivated to write some good clients and we can encourage those with publicity. A good path would be having clients officially integrated with TLS server software and/or operating systems.
I think using the webroot plugin and making it very stable is a lot better than integrating it into server software. That way we can easily bundle all efforts into a single solution instead of building another one for each and every server software.
In general, software should follow the single responsibility principle IMO. Certificate issuance and renewal can be clearly separated from servers, so please let’s continue with a separate client and not integrating it everywhere.
actually i agree with such separation and having the webroot plugin take more center stage as it would be alot easier for different web servers/control panels to do what they do and know best web server/control panel wise in automating a https vhost first and just feeding that vhost’s web root via webroot authentication
1st, it would give web servers/control panel users absolute trust in that their own implementation of server side configuration isn’t touched by letsencrypt client itself. I know this would be a concern for some
2nd, it would give letsencrypt folks full control over the issuance side via webroot authentication so that any 3rd party clients don’t fall behind on updates.
3rd, lessens burden on letsencrypt folks to cater and know about every web server type/os configuration out there - of course if you focus on the following you’d have alot covered - debian/ubuntu/rhel/centos apache and nginx + directadmin, plesk, cpanel.
Unfortunately, we need support for different webroots for different domains and things like REST APIs generally don’t have a webroot, so it’s not a solution to all problems. But I think it’s still the preferred method for most users.
yeah multiple domains would be one thing lacking in webroot authentication right now
edit: actually probably can script multiple domain letsencrypt ssl certificates via webroot authentication https://community.centminmod.com/posts/19878/
This is what my Centmin Mod Nginx stack or any scripted SSL vhost script would be able to do via nv command combined with web root authentication
#!/bin/bash
vhostname='le1.http2ssl.xyz le2.http2ssl.xyz le3.http2ssl.xyz'
for v in $vhostname; do
nv -d ${vhostname} -s y -u MYFTPUSERNAME
/root/.local/share/letsencrypt/bin/letsencrypt --renew-by-default -a webroot --webroot-path /home/nginx/domains/${vhostname}/public --email example@example.org --text --agree-tos --agree-dev-preview -d ${vhostname} auth
done
would generate the nginx ssl vhost for 3 domains - le1.http2ssl.xyz, le2.http2ssl.xyz and le3.http2ssl.xyz and run webroot authentication for SSL certs
Sure, I just meant in a single certificate. Different certificates work of course.
yeah single multi-domain SSL certificate is still to come for webroot authentication 
what is webroot authentication?
webroot is a plugin that places a file into your webroot directory to prove ownership of the domain to LE instead of changing config files or using the standalone authenticator.
see examples of webroot authentication plugin at Using the webroot domain verification method and https://community.centminmod.com/threads/letsencrypt-free-ssl-certificates-with-web-root-authentication-method.4635/
official definition
Authenticator plugin that performs SimpleHTTP challenge by saving
necessary validation resources to appropriate paths on the file
system. It expects that there is some other HTTP server configured
to serve all files under specified web root
it was born out of the simplefs plugin SimpleFS plugin (fixes #742) by kuba · Pull Request #757 · certbot/certbot · GitHub which was later renamed to webroot authentication
laymen terms, webroot authentication is an alternate way to obtain letsencrypt ssl certificates and pass the SimpleHTTP challenge by following these steps
so pretty much like veryfying ownership of domain for Google Webmaster tools put a file on the domain and finish.
I didnt think that this was an LE specific term, obvious that I found nothing that makes sense on Google
Yup basically the same
With Android defragmentation with every phone manufacturer having their
own Android builds, the responsiveness to updates for patches to
stagefright etc have been slower.
There are two issues to consider.
First, "early" version of Android suffered the problem. Early versions are versions prior to Ice Cream Sandwich (ICS). These devices also had the certificate store burned into ROM and part of the image, so there was no way to update it. The OEM abandoned the devices after the sale, and there's nothing you can do about it to fix it.
Second, "later" version of Android address the problem. Ice Cream Sandwich (ICS) allows the certificate store to be updated in the field without a new image. For details (and some very good reading), see Nikolay Elenkov's blog Android Explorations and his article ICS Credential Storage Implementation.
A final issue to consider is Apple and Windows Phone suffers this too. They abandon OS'es as quickly as some of the phone manufacturers. Its mentioned as a footnote because this discussion concerned Android.
An interesting facet of the problem on Windows Phone: OEMs are contractually obligated to apply Windows Phone updates. For a discussion, see Alan Meeus' Windows Phone: Security Deep Dive . However, it does not address (1) what Microsoft puts in the store (or omits from the store); and (2) Microsoft abandoning the operating system.
(And sorry about not providing links. This stupid bulletin board software made me take them out).
well win phone maybe but apple? e.g. the iphone 4s came iirc up to ios 9 which is quite some way and a lot longer than most of the androids.
@schoen @kelunik @bmw @jsha @jcjones
I was checking the stats at Let's Encrypt Stats - Let's Encrypt and see last 24hrs still alot of simpleHttp verifications compared to http-01. As i understand it simpleHttp is going away and new LE client uses http-01. So this infers that alot of folks are still running outdated LE clients ?
Any planned mechanisms in place to ensure and inform LE users to update their LE clients to keep updated ?
does the LE client have it's own version number it can report ? maybe add to Let's Encrypt Stats - Let's Encrypt LE client version stats as a reminder for folks to update too
Would be nice to have some kind of user agent logging to know which clients are used. Actually I like the simpleHttp spec currently better, but there’s always an issue for that on GitHub…
actually had a suggestion for a --client-type flag Standalone, Manual, Webroot stats? - #5 by schoen
We don’t need a flag, the client already knows which plugin is used and could report that in the user-agent header.
but a flag for tracking 3rd party client implementations which wish to pass on their identification to LE servers ?