<commit_before>---
layout: page
title: ACME Protocol Updates
permalink: /docs/acme-protocol-updates/
top_graphic: 1
date: 2016-07-27T00:00
---

Last updated: {{ page.date | date: "%B %d, %Y" }} \| [See all Documentation](/docs/)

The ACME protocol is the cornerstone of how Let's Encrypt works. As the protocol specification evolves over time Let's Encrypt will implement updated versions of ACME. When doing so, security will be our primary concern, followed closely by backwards compatibility.

# Currently Implemented ACME Version

We currently have the following API endpoints and associated ACME version implementations:

* [Production] `https://acme-v01.api.letsencrypt.org/directory`
  * ACME Version: [draft 04](https://tools.ietf.org/html/draft-ietf-acme-acme-04), with [some tweaks](https://github.com/letsencrypt/boulder/blob/release/docs/acme-divergences.md)
* [Staging] `https://acme-staging.api.letsencrypt.org/directory`
  * ACME Version: [draft 04](https://tools.ietf.org/html/draft-ietf-acme-acme-04), with [some tweaks](https://github.com/letsencrypt/boulder/blob/staging/docs/acme-divergences.md)

# New Backwards-Compatible ACME Features

From time to time Let's Encrypt may implement new backwards-compatible features for existing API endpoints. Typically new backwards-compatible features are introduced because we've decided to implement a part of the ACME spec that we hadn't implemented before.

When new features are introduced to existing API endpoints, the features will always be clearly specified in a public ACME specification and will not break properly implemented clients.

# ACME Security Fixes

If we become aware of a serious security issue with the ACME protocol (rather than simply our implementation of it) we may be forced to make compatibility-breaking changes to our API endpoints, or to cease operation of existing endpoints and introduce new ones.

ACME has been reviewed by many parties and used successfully in production, but there is always the possibility of undiscovered vulnerabilities. Systems administrators should maintain the ability to deploy timely updates to their ACME clients in response to such vulnerabilities.

# New Versions of ACME with Breaking Changes
<commit_msg>Clarify that the staging/prod API are not draft-04. (#207)<commit_after>---
layout: page
title: ACME Protocol Updates
permalink: /docs/acme-protocol-updates/
top_graphic: 1
date: 2016-07-27T00:00
---

Last updated: {{ page.date | date: "%B %d, %Y" }} \| [See all Documentation](/docs/)

The ACME protocol is the cornerstone of how Let's Encrypt works. It is currently a draft standard and not yet a finalized RFC. As the protocol specification evolves over time Let's Encrypt will implement updated versions of ACME. When doing so, security will be our primary concern, followed closely by backwards compatibility.

# Currently Implemented ACME Version

We currently have the following API endpoints. They do not implement any one fixed draft of the ACME specificiation as they evolved alongside the draft protocol document. Please see [our divergences documentation](https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md) to compare their implementation to the current ACME draft.

* [Production] `https://acme-v01.api.letsencrypt.org/directory`
* [Staging] `https://acme-staging.api.letsencrypt.org/directory`

# New Backwards-Compatible ACME Features

From time to time Let's Encrypt may implement new backwards-compatible features for existing API endpoints. Typically new backwards-compatible features are introduced because we've decided to implement a part of the ACME spec that we hadn't implemented before.

When new features are introduced to existing API endpoints, the features will always be clearly specified in a public ACME specification and will not break properly implemented clients.

# ACME Security Fixes

If we become aware of a serious security issue with the ACME protocol (rather than simply our implementation of it) we may be forced to make compatibility-breaking changes to our API endpoints, or to cease operation of existing endpoints and introduce new ones.

ACME has been reviewed by many parties and used successfully in production, but there is always the possibility of undiscovered vulnerabilities. Systems administrators should maintain the ability to deploy timely updates to their ACME clients in response to such vulnerabilities.

# New Versions of ACME with Breaking Changes

{'fraction_non_alphanumeric': 0.06554809843400447, 'fraction_numerical': 0.009619686800894854, 'mean_word_length': 4.929708222811671, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 9, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1658083', 'n_tokens_mistral': 1189, 'n_tokens_neox': 1107, 'n_words': 553}