Hi all,
I wanted to announce some small upcoming changes to the Let’s Encrypt API. 99%of people won’t notice these changes.
Shorter authorization lifetimes
Estimated date: August 3.
Right now, when you complete a challenge, your account gets a validated authorization object that can be used for certificate issuance for 10 months. That’s much longer than necessary. We’re going to change the lifetime for new authorization objects to 90 days. Existing, validated authorization objects will keep their same lifetime.
Eventually, we’d like to make authorization objects much shorter than certificate lifetimes, probably 7 days. However, we’re taking this intermediate step to ensure a smooth transition. We don’t yet have an estimated date for further reduction, but roughly speaking it may be this fall. Thanks to @pfg for the pull request making this configurable.
Automatic recycling of authorization objects
Estimated date: August 3, in staging as of July 14
Clients can reuse existing, validated authorization objects, but this is difficult, in part because Boulder doesn’t yet offer the list of authorizations specified in ACME. Most clients create a new authorization object for each issuance. This is generally fine.
However, a tiny handful of misconfigured instances attempt validation and issuance every minute. The issuances fail due to rate limiting, but each attempt creates a new authorization object, cluttering up our database.
We’ve found a backwards-compatible way of making authz reuse possible without client changes. If a client creates a new authorization object, and we already have a valid authorization object with more than 24 hours until expiration, we’ll return the URL of that new authorization object. Clients are free to POST to that authorization object and Boulder will return 200, but will not re-attempt validation. On polling, clients will immediately see status = valid. We’ve tested Certbot and found it works great with this setup, and we expect other clients will have no problems either.
This change is now live on the staging server. To test your client, generate two certificates in a row for the same hostname, on the staging server. If your client succeeds, it works fine with automatic recycling.
Rejection of malformed CSRs
Estimated date: January 2017, in staging as of July 14
Right now Boulder runs on Go 1.5.4. In Go 1.6 the ASN.1 parser was made stricter. It now rejects zero-length integers. Zero-length integers are generated by OpenSSL versions <1.0.2 if the CSR version is not explicitly specified. This has been fixed in Certbot since version 0.4.1. About 0.34% of current certificate issuances are made with CSRs containing zero-length integers.
We’ve collected a list of all accounts that exhibit this problem and will notify the account owners using their registered email address. Boulder will look for this specific problem before attempting to parse CSRs and will return a meaningful error message. We’re also working on a change to provide a temporary whitelist of accounts that have recently issued certificates with malformed CSRs. If this change works, we’ll be able to give a nice long deprecation window. If it turns out to be impractical we may need to end the deprecation window earlier.
We’re making this change to unblock our upgrade to Go 1.6 (and subsequently to Go 1.7). Keeping up to date with recent versions of Go is important so that we continue to get security updates.
Rejection of CAA SERVFAIL responses
Estimated date: September 14 with whitelist. Whitelist estimated to be removed January 2017. Estimated to be in staging by July 15.
When Let’s Encrypt first launched, some large DNS providers would return SERVFAIL for any CAA queries. Since CAA was relatively new, we worked around this by treating SERVFAIL as a successful, empty CAA response. However, this problem has gotten much better since then. Today, only 0.1% of FQDNs that Let’s Encrypt has issued for return SERVFAIL for CAA. So we’re planning to remove this hack.
To minimize disruption, we’ve made a whitelist of FQDNs for which we’ve already issued, where their DNS server consistently returns SERVFAIL for CAA queries. When we flip the flag for this feature, those FQDNs will still be able to issue, but new FQDNs will not be able to issue unless their DNS server returns a successful response to CAA queries.
We’ll notify each account holder with FQDNs on the whitelist that they need to fix their DNS responder or switch DNS providers by January 2017.
