-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC8823: acme4j response does not match CA expectation #123
Comments
S/MIME is supported since acme4j v2.12. You need to add the The More about S/MIME support is documented here: https://shredzone.org/maven/acme4j/challenge/email-reply-00.html Thank you for the test server link. It supports both S/MIME and STAR, so I can use it to end the experimental state of both extensions, finally. I'm closing the issue because it seems that everything you need is already present. If something is missing, feel free to reopen it. |
acme4j does not seem to be compatible with the latest development version of There seems to be a disagreement about the SHA256 hash value of the ACME reply Public key generated by acme4j as seen by CA:
Creation of an email challenge
CA outgoing email subject:
Reply by acme4j:
Computed hex from response:
Expected reply by CA:
The testcode used can be found here: Full trace of the failed certificate generation can be found here: |
First of all, thank you for the detailed explanation! It was really helpful for reproducing the problem. Actually, I have anticipated this issue... According to RFC-8823, the CA needs to generate two tokens (Token Part 1 and Token Part 2). Unfortunately the RFC is not very clear about how the two parts are then supposed to be concatenated by the client. Section 3 only says:
There are two possible ways of concatenation.
Both ways give different results, because of the padding bits that may be appended by base64 encoding. Sadly the RFC gives no concrete example of a concatenation so one could compare the own implementation with an expected result. I had already raised this question in the ACME mailing list in June: https://mailarchive.ietf.org/arch/msg/acme/mOtPJpJHmmJeuzGBIaHuDcX8LBI/ Brian Sipos then gave good arguments for the string concatenation, and deemed the RFC-8823 text sufficient to explain this: https://mailarchive.ietf.org/arch/msg/acme/suw60485gKpcP9Cx5tl9gE1SQQI/ I got no other answers that were relevant. For this reason, acme4j uses string concatenation for computing the key-authorization value. Assuming that, like in your example:
The string concatenation gives:
This is what acme4j gives as response to your CA. Your CA however seems to expect a byte array concatenation:
Note how It is a difficult situation now, because in my oppinion it is unclear whether your CA or acme4j implements that RFC incorrectly. There are good arguments on both sides, and personally I would even favor byte array concatenation. But the RFC itself (sadly) gives no further clues. I have just contacted the author of RFC-8823 and asked him for clarification. I will report back as soon as I got an answer. |
Thanks for your in depth explanation and the link to the threads regarding this topic. To me this is confusing as well, and I tend towards the
This says, that the decoded |
As Brian Sipos said in his response:
So actually, Well, I guess we can agree that RFC8823 leaves a lot of room for interpretation, as we are both (independently) not certain about how to do proper concatenation. 😃 I hope that Alexey Melnikov (as the author of the RFC) can shed some light on it. |
Alexey Melnikov has answered in the mailing list: https://mailarchive.ietf.org/arch/msg/acme/KusfZm3qC50IfcAAuTXtmbFK0KM/
This means that acme4j handles the challenge according to the intention of the RFC author, and (sorry to say that) the bug is on the CA side. 😉 However, I am glad that we can close this issue with certainty. |
This is not a bug on the CA side, but an interoperability issue caused by an ambigous / incomplete specification. Whatever ... The server side implementation has been tweaked for maximum interoperability. It was able to generate a certificate using acme4j as a client: https://gitlab.com/platynum/certification-authority/flows/-/jobs/1510875646#L5488 This issue can be closed now. PS Using |
I agree. But it seems that in the ACME mailing list no one sees a need to further clarify that problem, e.g. in an RFC8823 errata. I am quite sure that I will be having this discussion again some day. Anyway, thank you for your report! |
Currently only
dns
identifiers are supported. Please add support foremail
identifiers, too. See RFC8823 (https://datatracker.ietf.org/doc/html/rfc8823) for more information.A server implementation for testing can be found here: https://gitlab.com/platynum/certification-authority
The text was updated successfully, but these errors were encountered: