[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Certbot, Ring in Debian Stretch



On Tue, Nov 22, 2016 at 08:23:59AM +0100, Daniel Pocock wrote:
> 
> I'd like to suggest an additional point relevant to all of the options: how
> well does the certbot client react when it is no longer usable?  Does the
> protocol include a mechanism to check the version?  Does the client give an
> explicit error telling the user to update the client and can it be tweaked
> so that Debian users are shown a message about getting the latest package
> from stable-backports?  Or will the user see some random error that doesn't
> mention the client version at all?
>

ACME includes an explicit versioning mechanism for inherently-breaking
protocol changes, and also a User Agent string that an be employed for
finer-grained conditional responses.

To date, we have never incremented the explicit versioning mechanism, but
there have been a couple of incompatibilities that could be characterised as
Certbot bugs which the Let's Encrypt servers initially tolerated, but
eventually stopped tolerating.

In this case: https://github.com/certbot/certbot/issues/2528 the server will
today send an error message, and buggy clients would print that error
instructing the user to upgrade Certbot and/or OpenSSL to fix the problem.
Note, however, that if Certbot is running in a renewal cron job, the sys admin
might miss that message.

In this case: https://github.com/certbot/certbot/issues/2768
the server was able to use the User Agent string to avoid sending incompatible
messages to older Certbot versions.

For cases in the future where ACME is intentionally being revised in an inherently
incompatible way, we would change the protocol's endpoint URI, and begin a 6-12
month compatibility window with the previous version.

In all cases we do have the option of sending email to the registered account
email addresses associated with older clients that are about to be
incompatible, provided that sys admins chose to give us an email address when
they created their Let's Encrypt accounts.


 
 

-- 
Peter Eckersley                            pde@eff.org
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993


Reply to: