Intermediate certificates concatenation

Issuance Tech
1

Hello,

I have written a new python client using only cryptography.io as cryptographic library.
Everything works fine except for the concatenation of intermediate certificates.

First, I think that the schema on Chain of Trust - Let's Encrypt is outdated because it does not mention X3 and X4 certificates.

Then, I don't understand why these certificates are not provided through the ACME protocol. Maybe the official letsencrypt server could offer them as an extension of the protocol, through another URI ?

Finally, I don't understand how I should concatenate them. Is it the following ?

[certificate issued by the ACME protocol]
[lets-encrypt-x3-cross-signed.pem]
[isrgrootx1.pem]

Thanks in advance for any answer,
Aurélien

2

Agreed, although they are mentioned on the page correctly, the diagram needs updating.

They are. If you look at https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md it states "The server can also provide the client with direct access to an SCT for a certificate using a Link relation header" and provides the example;

GET /acme/cert/asdf HTTP/1.1
Host: example.com
Accept: application/pkix-cert

HTTP/1.1 200 OK
Content-Type: application/pkix-cert
Link: <https://example.com/acme/ca-cert>;rel="up";title="issuer"
Link: <https://example.com/acme/revoke-cert>;rel="revoke"
Link: <https://example.com/acme/reg/asdf>;rel="author"
Link: <https://example.com/acme/sct/asdf>;rel="ct-sct"
Link: <https://example.com/acme/some-directory>;rel="directory"
Location: https://example.com/acme/cert/asdf
Content-Location: https://example.com/acme/cert-seq/12345

[DER-encoded certificate]

If you check the headers when you receive the certificate, you should see a link for the Issuer certificate there.

Do you know what application you want to use it for ? i.e. some applications ( such as older versions of apache ) want them in separate files, whereas other applications want them combined.

3

Another thing to note is that you don’t include the root as the relying party needs to already have it, so it’s a waste of bandwidth. In addition if you’re sending the intermediate cross-signed by IdenTrust then the ISRG root is completely irrelevant.

1 Like
4

Small correction: You don't want the SCT link here, but rather the issuer certificate, which is included as the rel="up" link:

In particular, the server MUST include a Link relation header field [RFC5988] with relation “up” to provide a certificate under which this certificate was issued

1 Like
5

A handful of the existing Python clients do not download the signing certificate. If you based your client on one of those, sorry. I made the same mistake.

nginx wants a fullchain like this:

# le_x3 or whatever signed it via `rel="up"` in the headers
fullchain_pem = "\n".join(cert_pem, le_x3_cert_pem)
1 Like
6

Thanks everybody for your answers, my problems are solved (except the diagram part).

I didn’t use let’s encrypt client cause I needed something that I can program (and I wanted to understand the protocol).
I used https://github.com/diafygi/acme-tiny as an inspiration (especially for the base64 encoding and the JWS things) but I rewrite everything into nice python classes (and I check meticulously combinations of challenges). I hope to release this soon. I also need to look at that https://github.com/veeti/manuale.

7

The acme-tiny author refuses to download the intermediate certificate. Many people have constantly brought this up. (i did as well, but somehow my comment got borked)

LetsEncrypt should actually warn people against using the acme-tiny client.

1 Like
8

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