Synopsis
How do I download what I expect to download and have the chain files I want to have?
RFC 8555, part 7.4.2 “Downloading the Certificate” has normative standing with indefinite expression of the certificate-chain span of the certification data provided by the ACME2 server. What certificate-chain spans are standardized and what spans are provided in practice by Let's Encrypt and other Certificate Authorities (CAs)? What and how can an ACME2 client specify for certificate chain span?, what span can an ACME2 client reasonably expect?, and what should an ACME2 client do to request and process the certification data provided by the ACME2 server? Can I rely on a big-chain download from the ACME2 server of any compliant CA? How do the alternative certificate chains ‘fork’ from the end-entity certificate?
I am not aware of a reasonably direct and definitive source of information about my certificate-chaining-span concerns. I am trying to cobble together a practical understanding. What are the fundamentals to be grasped and how definitive are they?
As it stands now, I would probably assume, and moreover enforce by trimming, the DV certificate alone and try to download the higher certificates one by into a cache directory until I get the root certificate. Should I validate the chain? Seems daunting; have not studied it seriously yet. Then I would concatenate the PEM encoding formats as most completely appropriate for nginx and Postfix.
Thanks.
My Chain File Use Cases
nginx Web server current in 2025, module ‘ngx_http_ssl_module’, directives ‘ssl_certificate’ and ‘ssl_certificate_key’ require references to files in Privacy-Enhanced Mail (PEM) format. The use of ‘ssl_certificate_key’ to specify the key file can be obviated by putting the private keypair data in a PEM chain file with its certificate one of the files referenced by ‘ssl_certificate’. As I understand it, the provisioning of the root certificate by the Web server is superfluous because a root certificate is not trusted except as determined by the Web client with its cache of trusted root CA certificates.
Postfix email server current in 2025, configuration file ‘main.cf’, parameter ‘smtpd_tls_chain_files’ requires reference to files in PEM format. Each file should have a certificate's private keypair and the corresponding certificate and possibly more up to the root. It won't hurt to include it (as far as I know).
It is my understanding that nginx and Postfix servers start or otherwise ‘configure’ with root privileges and have access to not only the configuration files owned by their dedicated, respective non-root users but also the key and certificate files, wherever they may be located and however they may be owned in the relevant file system. I run my client software without root privileges. The http-01 challenge requires the provisioning of particular resources. I put those resources in to a dedicated directory without root privileges, and I believe that nginx Web server does not have root privileges to access the content of that directory.
How much do I need chain files for nginx Web server and Postfix email server? I feel bad if I don't score at least an A on the SSL Labs test for my Web server configuration, but I'm tired of this ACME client coding and might just skip it. I have been manually building my chain files. That is not practical with 6-day certificates. When will that become mandatory?
Chain-Nonspecific Certificate Data
RFC 8555, part 7.4.2 “Downloading the Certificate” simultaneously supposes the download of a single certificate with singular expression and the download of a nondescript certificate chain with plural expression. The section further refers to a default format ‘application/pem-certificate-chain’ without indication of a standardized way to get any other format, which without further clarification may or may not indicate specification of which chain certificates to include. If a chain is provided, does it include the root certificate? Is chain validity a security risk that the ACME2 client should address with chain validation before bundling into a chain file?
The part of the standard also identifies that ACME2 servers MAY provide ‘alternative certificate chains starting with the same end-entity certificate’. That's not literally possible without some inexplicit critical information. Certificates follow the X.509 (structure and encoding?) standard. I have never seen an end-entity certificate signed twice, which would provide a ‘fork’ for two alternative certificate chains from the very same end-entity Domain Validation (DV) certificate. Perhaps there are instead alternative certificates with the same end-entity domain validation (i.e. ‘certification’)?
Certificate Span in Practice
My experience with my personal Python 3-based client is entirely with Certificate Authority (CA) Let's Encrypt (LE) 2020–present (May 2025) and Buypass 2020–circa February 2025. I have only observed that the single Domain Validation (DV) certificate in PEM format is provided, after all the authorizations have been completed for the domains in question as is usual. However, threads of this forum composed just prior to 2020 indicate that LE supplied a certificate chain of some sort. The forum thread “ACME Account Registration in Python”, ACME Account Registration in Python , 20 March 2025 eventually digresses to the issue of certificate chain span. The author of the initial thread post wrote in a later post that his CA, Sectigo/InCommon, ‘included the whole chain in the response’.
Chain Validation
How important to security is certificate chain validation? Do alternative chains fork from a single certificate (in X.509), and should software code be able to detect the alternatives in a single certificate? If so, what are the ways to do it, and how do they compare? Does certbot validate the chain?
Certificate Processing Alternatives
For some reason, the online record shows that some people or some uses cases find the use of child processes (or subprocesses) with Python to invoke OpenSSL to be unacceptable. Why is that? I can guess industrial speed for high volume processing, but that's only a guess. I don't know if I should be worried about it. I currently use OpenSSL via subprocesses.
Specifically, I compare the output of ‘openssl pkey -text’ to a large regular expression to determine key type and public key values. With certificate chaining using the same brittle (and light, simple) technique I would compare the output of ‘openssl x509 -text’. Can there be two URIs to the next certificate. It seem to me that checking the signature or key information of chained certificates would be a good idea. I am ignorant of these specifics. I am comfortable using OpenSSL manually to generate keys and certificate signing requests and to inspect keys, certificate signing requests, and certificates. As you may know, OpenSSL will only inspect the first (should be of the end-entity) key or certificate of a chain file in PEM encoding format. I know to cut and paste to expose the non-first entities of a chain file to inspection with OpenSSL -text.
I am aware that ‘certbot’ has recently transitioned from 'pyOpenSSL' to 'pyca/cryptography'. My current workload just to get my client code into working condition is daunting without another little mountain to climb. I am not sure how necessary the chain bundling feature is, but the PyPI package 'pyca/cryptography' looks like it should facilitate it easily enough. I can't be sure I can navigate the ‘dinosaurs with lasers’ without a commitment of weeks. I don't see how the library package is useful without plunging into the ‘hazardous material’.