This file:
# Boulder divergences from ACME
While Boulder attempts to implement the ACME specification ([RFC 8555]) as strictly as possible there are places at which we will diverge from the letter of the specification for various reasons. This document describes the difference between RFC 8555 and Boulder's implementation of ACME, informally called ACMEv2 and available at https://acme-v02.api.letsencrypt.org/directory. Boulder's implementation of ACMEv1 differs substantially from the final RFC. Documentation for Boulder's ACMEv1 support is available in acme-divergences-v1.md.
Presently the following protocol features are not implemented:
- Pre-authorization. This is an optional feature and we have no plans to implement it. V2 clients should use order based issuance without pre-authorization.
- The `orders` field on account objects. We intend to support this non-essential feature in the near future. Please follow Boulder Issue [#3335](https://github.com/letsencrypt/boulder/issues/3335).
POST-as-GET: We support POST-as-GET but do not yet mandate it. We [plan to mandate](https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380) POST-as-GET for all ACMEv2 requests in late 2019.
## [Section 6.6](https://tools.ietf.org/html/rfc8555#section-6.6)
Boulder does not provide a `Retry-After` header when a user hits a rate-limit, nor does it provide `Link` headers to further documentation on rate-limiting.
## [Section 6.7](https://tools.ietf.org/html/rfc8555#section-6.7)
Boulder doesn't return errors under the `urn:ietf:params:acme:error:` namespace but instead uses the `urn:acme:error:` namespace from [draft-ietf-acme-01 Section 5.4](https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-5.4).
Boulder uses `invalidEmail` in place of the error `invalidContact` defined in [draft-ietf-acme-01 Section 5.4](https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-5.4).
show original
says:Content-Type value application/pkix-cert instead of application/pem-certificate-chain.”
while POST-as-GET to /acme/cert/ do return (by default):Content-Type: application/pem-certificate-chain
which is correct per RFC.
1 Like
cpu
May 6, 2019, 1:05pm
2
Hi @omascia
omascia:
“Boulder returns certificates with the Content-Type value application/pkix-cert instead of application/pem-certificate-chain .”
while POST-as-GET to /acme/cert/ do return (by default):Content-Type: application/pem-certificate-chain
which is correct per RFC.
Thanks for posting about this. You're correct
I posted a pull-request to clean up this inaccuracy and a couple others I caught at the same time: docs: update acme-divergences for rfc 8555. by cpu · Pull Request #4203 · letsencrypt/boulder · GitHub
3 Likes
Thanks too, for having fixed this documentation quickly.
1 Like
system
June 5, 2019, 5:57pm
5
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
,
I came across this by adapting today our integrated client, from v1 to v2. I implemented using POST-as-GET where appropriate so I’ll not be concerned by the November 2019 deadline. Job done, it works fine. 