I expect from RFC 8555 that an ACME
server issues a full chain certificate as a reply body in the PEM format. The media type is 'application/pem-certificate-chain'.I can only guess from RFC 1421, sec. 4.3.1 that the byte encoding of the certificate necessarily uses <CR><LF> line breaks. I get US-ASCII from encguess <file>.pem. Paging PEM files with less does NOT show ^M at the end of each or any line.
Are PEM files, e.g. the private key pair files and certificate files needed by Web servers, necessarily in US-ASCII?
Are PEM files typically/conventionally stored in the line break encoding of the native operating system?
Should PEM files always or normally be transmitted with the <CR><LF> line break encoding?
A file of this type contains one or more certificates encoded with
the PEM textual encoding, according to [RFC7468]. The textual
encoding of certificates in this file MUST use the strict encoding
and MUST NOT include explanatory text. The ABNF for this format is
as follows, where "stricttextualmsg" and "eol" are as defined in
Section 3 of RFC 7468:
> I can only guess from RFC 1421, sec. 4.3.1 that the byte encoding of
> the certificate necessarily uses <CR><LF> line breaks.
The canonical format of a MIME media type on the wire need not match its
local representation on disk. For example, HTTP transmits textual
content with CRLF line endings, but user agents generally store text
with using host platform's line endings.
> I get US-ASCII from encguess <file>.pem.
No need to guess, it is just the base64 (ASCII) payload beween
a simple ASCII preamble and postamble.
> Paging PEM files with less
> does NOT show ^M at the end of each or any line.
None are expected on a Unix system, and on Windows you'd need
to elect to view the content as a binary file.
> Are PEM files, e.g. the private key pair files and certificate files
> needed by Web servers, necessarily in US-ASCII?
See above, but note that "explanatory text" can contain data in some
unspecified local encoding, e.g. UTF-8.