> On Mar 30, 2017, at 10:47 AM, Jacob Hoffman-Andrews <[email protected]> wrote:
>
>> 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.
Ok.
>
> 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.
It’s straightforward. I’ll research it later…if it’s not “straightforward
enough” I can just write a script for you all to take.
>> 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.
Yeah, that’s a problem, you need to be #@($#@ sure that you are validating the
response from the ACME client.
RFC 7468 discusses implementations considerations with multiple textually
encoded crypto items (Section 2, Section 14). If you are ingesting a stream
that has textually encoded items, you need to “hunt-and-pick” exactly what you
are looking for, and validate the contents.
IN PARTICULAR: both Apache and Ngnix may be subject to a private key
substitution attack with naive passing of the ACME response to the web server!
See:
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate
<http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_certificate>
http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile
<http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile>
The SSL Certificate option includes the option of including the private key in
the same input: “A secret key in the PEM format may be placed in the same
file.”
What this means is that a malicious ACME server can serve a certificate per the
client’s request, but substitute the server’s specified private key with the
ACME server’s own choice of private key by including -----BEGIN RSA PRIVATE
KEY----- in the response. Then when put into production, the ACME server
operator will be able to decrypt all of the traffic. WHOOPS. (Obviously the
ACME server can impersonate the web/TLS server, since it’s a CA component, but
this is not what you want.)
Different implementations may behave differently: the moral lesson is to
validate your inputs, and in this case, that means to deal with the certificate
chain response with a lot more finesse than is contemplated with
“application/pem-certificate-chain”.
>
> 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.
Check out the above. :-)
>
>> 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.
Right, but “PEM” is not the format that you are actually looking for in this
case, despite its apparent ease of use. What this draft is calling
application/pem-certificate-chain boils down to text/plain, and at least
text/plain makes the security issues more obvious (because the ACME client is
ingesting arbitrary inputs).
Let’s address the issue raised above first…
Sean
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
