> Therefore the “receiver” is the ACME client, which also is the web/TLS server that incorporates the chain into its operations.
Note that in common deployment today, the ACME client is separate from the web server. On 03/30/2017 08:27 AM, Sean Leonard wrote: > Contents: DER-encoded certificates, concatenated in RFC 5246 Section > 7.4.2 order Is there a straightforward OpenSSL command to convert this entity into a PEM file containing multiple certificates? I don't think there is but I could be wrong. > This is easier and better than stringing the textual encoded versions because > you don’t have to deal with text metadata issues, charsets, line endings, and > extra processing. Specifically, an ACME server is going to have to take the > certificate bytes and base64-encode each one, followed by ASCII armoring. > Then the ACME client is going to have to reverse this. No point and confusing. Our expectation is that many ACME clients will *not* reverse the base64 and ASCII armoring, but will write out the entire contents to a file for ingestion by a web server. The two most popular web servers, Apache and Nginx, consume PEM-formatted certificate chains. You're right that an ACME client would have to decode this format if they wanted to change it to something else, but what we are seeing in practice is clients that simply convert the end-entity certificate from DER to PEM and don't bother with the intermediates, resulting in end-user pain. > For those who don’t like binary, ACME is JSON-based, so you can just have an > application/json response that is just an array: > > [“MIICAS...base64 of end-entity cert”,“MIICAS…base64 of second cert…”…to root] For me, "don't like binary" isn't the issue. If CMS were the most common certificate chain input format for web servers, I would be fine with returning binary CMS. Unfortunately, it is not. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
