Upcoming API changes


#1

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.


Renewal using DNS-01
Challenge validity period
About requests and TXT records
Does the renewal of certificate follow the same process as issuing a new certificate?
[SOLVED] DNS problem: SERVFAIL looking up CAA for mit42.de
How to revoke a certificate without account key or email
How to revoke a certificate without account key or email
New API Announcements category
Authorization recycling
Problem with CSR for only one DNS name
Authorization valid only for 3 months
Automatic recycling of pending authorizations
404 Expired authorization
#2

Is there a particular reason for this apart from reducing the resource consumption on the boulder server?


#3

Yes. When all authorizations on an account are long-lived, the impact of a stolen account key is that the attacker can issue for any domain the account has authorized. We’d like to reduce the impact of a stolen account key so only recently authorized domains can be issued for by the attacker.

You can probably see that reducing to the 90 day level doesn’t achieve that goal quite yet, but it’s a step on the road. :slight_smile:


#4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.