Formats of certificates issued by let's encrypt

Issuance Tech
1

Hello, this topic seemed to me the most suitable for this question.

I am interested in which formats: .cer, .crt or .pem "let's encrypt" can issue certificates. What MIME types can be sent in a POST-as-Get request to upload a certificate in the "Accept" field?

Thank you in advance for the answer.

1 Like
2

I'm not quite sure I'm following exactly what your question is, especially as "upload a certificate" isn't really what's happening, but I'll give it a go.

Retrieving the certificate chain from the ACME server is covered in RFC 8555 section 7.4.2, which says the default format is application/pem-certificate-chain, which section 9 describes as being a sequence of PEM-formatted certificates. While 7.4.2 says that "The ACME client MAY request other formats by including an Accept header field," the ACME Divergences document describing how Let's Encrypt's software diverges from the specification says that "Boulder does not process Accept headers for Content-Type negotiation when retrieving certificates." So I think no matter what you pass you're going to be getting a chain of PEM formatted certificates.

You are also asking about file extensions being .cer, .crt, .pem, but there really isn't a standardized meaning for those extensions or their contents. Certbot uses .pem for files that are for a single certificate, a chain of certificates, or a private key, and much other software integrating with ACME follows that convention as well. Windows tends to use .cer for single certificates and .crt for certificates intended to be used as trust anchors, but doesn't care if they're DER-encoded or PEM-encoded, they just have different default behavior when double-clicking on them (as .crt will default to asking if you want to add it to your trust store and .cer will default to just showing you, at least when I last tried them).

I hope that at least kind of answers some of your questions?

10 Likes
3

Thank you! Your answers helped me to verify my guesses.

6 Likes
4

FWIW, I built a "translator" functionality into my client. After combing through many RFCs and Documentation, I ultimately decided on mapping extensions/formats to mime types as follows – as that aligned with most usage patterns across operating systems.

The Certificate Itself:

    cert.pem            PEM     application/x-pem-file
    cert.pem.txt        PEM     text/plain
    cert.cer            DER     application/pkix-cert
    cert.crt            DER     application/x-x509-server-cert
    cert.der            DER     application/x-x509-server-cert

The Certificate Chain:

    chain.pem           PEM     application/x-pem-file
    chain.pem.txt       PEM     text/plain

The Certificate Fullchain

    fullchain.pem       PEM     application/x-pem-file
    fullchain.pem.txt   PEM     text/plain

#### CertificateCA

The CertificateAuthority's Certificate:

    cert.pem            PEM     application/x-pem-file
    cert.pem.txt        PEM     text/plain
    cert.cer            DER     application/pkix-cert
    cert.crt            DER     application/x-x509-ca-cert
    cert.der            DER     application/x-x509-ca-cert

#### CertificateCAChain

One or more CertificateAuthority Certificates

    chain.pem           PEM     application/x-pem-file
    chain.pem.txt       PEM     text/plain

#### CertificateRequest

    csr.pem             PEM     application/x-pem-file
    csr.pem.txt         PEM     text/plain
    csr.csr             PEM     application/pkcs10

#### Account/Domain Keys

    key.pem             PEM     application/x-pem-file
    key.pem.txt         PEM     text/plain
    key.key             DER     application/pkcs8

#### Account/Domain Keys

    key.pem             PEM     application/x-pem-file
    key.pem.txt         PEM     text/plain
    key.key             DER     application/pkcs8
7 Likes
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.