From f3a989707fddcd39982289bc0b01d4ef29bdcba8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Richard=20K=C3=B6rber?= Date: Mon, 9 May 2022 17:13:24 +0200 Subject: [PATCH] Link to more help --- src/doc/docs/faq.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/doc/docs/faq.md b/src/doc/docs/faq.md index d073c8cf..5f4bef17 100644 --- a/src/doc/docs/faq.md +++ b/src/doc/docs/faq.md @@ -31,3 +31,8 @@ **Cause:** Unfortunately [RFC 8823](https://tools.ietf.org/html/rfc8823) has an ambiguous specification about how to concatenate the two token parts. The text permits two different interpretations that may give different results. _acme4j_ uses an implementation that corresponds to the [intention of the author of RFC 8823](https://mailarchive.ietf.org/arch/msg/acme/KusfZm3qC50IfcAAuTXtmbFK0KM/). If the CA is implemented following the other interpretation, the ACME e-mail response will not match (see [this issue](https://github.com/shred/acme4j/issues/123)). **Solution:** It is a difficult situation that is caused by an ambiguous specification, but it is like it is now. Since _acme4j_ follows the intention of the RFC author, I take the position that the _acme4j_ implementation is correct. Please open a bug report at the CA, and refer to [this issue](https://github.com/shred/acme4j/issues/123). If the two tokens are split at a position so the first token won't have trailing base64 padding bits, the CA service can be implemented in a way that is compatible to both interpretations. + +## Where can I find more help? + +* [Let's Encrypt Documentation](https://letsencrypt.org/docs/) +* [Let's Encrypt Community](https://community.letsencrypt.org/) - If the question is _acme4j_ related, please mention it in your post. \ No newline at end of file