How to combine various certificates into single .pem

Question

I've just finished reading over this great thread explaining the different SSL formats.

Now I'm essentially looking for the opposite of How to split a PEM file

There's 4 files I want to consolidate, originally created for Apache, I'm looking at files specified by

SSLCertificateFile
SSLCertificateKeyFile
SSLCertificateChainFile
SSLCACertificateFile

What I'm mostly curious about is the order of the files in the consolidated dereivative, is that important? EG. if I were to just cat them together in the order they appear above, into a .pem, would it be valid, or should they be ordered a specific way?

FYI, I'm doing this for sake of using these certs as a combined single .pem in SimpleSAMLphp.

The order should be private key, intermediate certs, your certificate. — Zoredache, Feb 07 '13 at 20:23
What about the CA, isn't that the root of the chain, and therefore it would go after the chain in the consolidated file? Or can it be omitted entirely? — quickshiftin, Feb 07 '13 at 20:27
SSLCACertificateFile is completely unrelated to the other directives as it's used for client authentication. — Bachsau, Oct 01 '23 at 01:27

score 85 · Accepted Answer · edited Oct 07 '21 at 06:47

85

The order does matter, according to RFC 4346.

Here is a quote directly taken from the RFC:

  certificate_list
    This is a sequence (chain) of X.509v3 certificates.  The sender's
    certificate must come first in the list.  Each following
    certificate must directly certify the one preceding it.  Because
    certificate validation requires that root keys be distributed
    independently, the self-signed certificate that specifies the root
    certificate authority may optionally be omitted from the chain,
    under the assumption that the remote end must already possess it
    in order to validate it in any case.

Based on this information, the server certificate should come first, followed by any intermediate certs, and finally the root trusted authority certificate (if self-signed). I could not find any information on the private key, but I think that should not matter because a private key in pem is easy to identify as it starts and ends with the text below, which has the keyword PRIVATE in it.

 -----BEGIN RSA PRIVATE KEY-----
 -----END RSA PRIVATE KEY-----

edited Oct 07 '21 at 06:47

Community

1

answered Feb 07 '13 at 21:39

Daniel t.

9,424

11

cat site.crt root.crt site.key > site.pem – curveorzos Feb 10 '17 at 00:14
1

Please do not be mistaken - the information from the RFC does not answer the question. The RFC talks about the TLS protocol, not about the PEM format for storing certificates in a file. – pabouk - Ukraine stay strong May 25 '22 at 15:11
@pabouk Can you elaborate on that? I always thought the order was important as defined in this answer. BUT, I just recently dumped all the certs in my PFX file to a PEM file using openssl and the order of the bundle was as follows: server, Root CA, Intermediate CA. Furthermore, verifying this bundle succeeded with the following command!: openssl verify -show_chain -no-CAfile -no-CApath -untrusted <( { openssl x509 >/dev/nul; cat; } < server.crt ) <(openssl x509 < server.crt). So, I'm a little confused and want to make sure I understand this correctly. Thanks! – fourpastmidnight Feb 22 '24 at 21:12
1

@pabouk (Follow on from previous comment...) And perhaps what I'm seeing is because of exactly what you say, the RFC is about the TLS protocol while PEM is just a (file) format. I would expect openssl to correctly extract a valid PEM-formatted certificate bundle from a PKCS12 (PFX) file. (And, yes, my bundle does not need to have the Root CA cert in it because we add our internal CA to all of our machine's certificate store, but that's beside the point.) – fourpastmidnight Feb 22 '24 at 21:15
Interesting, I just did my own test. Note that when I said my bundle "passed verification", that's because I actually didn't include the -no-CAfile -noCApath parameters originally, so OpenSSL used the Root CA in my computer's store. So, that makes sense. But, verifying that bundle using no-CAfile -noCApath -untrusted ... as shown above actually FAILS verification--is it should. I claimed all certificates after the endpoint entity certificate were untrusted. So it would seem that in the PEM file, order does not matter, but that the endpoint entity cert should come first. (cont'd) – fourpastmidnight Feb 22 '24 at 21:30
After the endpoint entity certificate, the order doesn't matter. If the private key were to be included in the bundle, I'm unsure of whether it's placement matters in the file. But, since I don't require the private key in the bundle, I'm not overly concerned with that right now.
Hopefully someone can verify that my understanding is correct.
– fourpastmidnight Feb 22 '24 at 21:31
1

@fourpastmidnight Unfortunately I cannot give you more details and thank you for providing results of your tests. --- I just wanted to point out that the answer is wrong in the sense that it assumes that RFC 4346 (TLS 1.1) says something about the PEM file format. – pabouk - Ukraine stay strong Feb 23 '24 at 08:47
Thanks @pabouk, I agree with you, even more so after conducting additional research. It seems it really doesn't matter what order the certificates are in inside the bundle. Even the server cert doesn't appear to have to appear first--it just does because it makes using the bundle with OpenSSL much easier. – fourpastmidnight Feb 23 '24 at 14:52
1

I did some more testing. So, along with this other SF Q&A answer here and my comments on it, I'm convinced that the order of certificates in a PEM file is not important. The ordering in the file can, however, make it really easy or really hard to work with using OpenSSL. But that's a different question altogether! So, yes, this question is factually incorrect in its assertions and is really talking about the TLS protocol and not the PEM file, which is just a data container as @pabouk asserts. I'm only not downvoting because of my low rep :(. – fourpastmidnight Feb 26 '24 at 17:35

score 24 · Answer 2 · edited Jun 21 '16 at 00:24

24

Here is the command to combine using cat

cat first_cert.pem second_cert.pem > combined_cert.pem

edited Jun 21 '16 at 00:24

chicks

3,819
10
28
36

answered Jun 20 '16 at 20:31

tidileboss

357

8

It's an answer how to concatenate any two certs, but but not how to consolidate/concatenate certs for Apache. – asdmin Jun 21 '16 at 06:41
1

This is not really to answer the question, the accepted answer is good enough. I just provide additional informations on how to concatenate, as the original poster talked about using cat, I thought it might help others. – tidileboss Jul 04 '16 at 15:37
12

Your answer does not indicate what order the files should be concatenated in (you just have "first_cert.pem" and "second_cert.pem"). The correct answer would be cat my_site.pem ca_chain.pem my_site.key > combined_cert.pem – Doktor J Feb 23 '17 at 19:09
1

@DoktorJ Most of the reliable sources say that the private key comes first, not last in the combined PEM file. – pabouk - Ukraine stay strong May 25 '22 at 15:14
@pabouk-Ukrainestaystrong I'd be less inclined to think that would matter. The order of certificates is important because it gets used in TLS handshake: "here's my certificate, my certificate is signed by this, this is signed by that, ...". The private key does not get relayed in the protocol so won't influence the order of anything in the handshake. – Philip Couling Jan 11 '23 at 12:19

How to combine various certificates into single .pem

2 Answers2