I seem to forget which order concatenated .pem certificates go in. I only do this kind of thing every so often.
The short answer is:
Private key on top.
Certificate from the signing authority in the middle.
Certificate Authority Chain file next.
https://github.com/bradchesney79/make-concatenated-ssl-pem
I have seen people refer to both the Certificate Authority Chain file and the file my script creates as a bundle. That is wrong-- the bundle is all two or three things (sometimes the chain file is optional).
If you want to know more about why and how certificates work, keep reading.
You start by generating a private key, this is a string that can be used mathematically to modify data in a way that it is not easily read by conventional means. This key is generally used to make a certificate signing request (CSR)-- it is a block of text based upon the private key that allows a Certificate Authority to issue an SSL certificate without you giving them your private key.
A Certificate Authority(CA) signs and distributes SSL certificates. SSL certificates are used in a similar manner as a public key and has meta data about your site such as the domain name secured, where the 'owner' of the site says the site is based, what level of 'reversible entropy(chaos)' is used to encrypt the data, what type of encryption to use, and sometimes less commonly used factoids. You will see 2048-bit or SHA256 for current levels and types of encryption for instance.
There is one root Certificate Authority in a chain-- which is conceptually shaped more like a tree in reality. The next top most Certificate Authorities are all verified as trusted by the root Certificate Authority. And layer upon layer so on and so forth so that the demonstration CA "Deering" and CA "Dunkirk" are trusted by CA "Catskills" who in turn is trusted by CA "Bridgeport". CA "Bridgeport" is trusted by none other than the root CA, CA "Alpha".
The Certificate Authority Chain file allows the browser to identify which signing authority said the site in question can be trusted. Due to it being a chain of trust, there may be more than one block. Some CA Chain files have more blocks to facilitate verifying trust for web 'agents' (usually a browser) in case the parent entity issuing the certificate isn't one your browser inherently trusts.
Certificates that are inherently trusted happen because the entities publishing the browser software may decide to include portions of the chain to bypass certain lookups and speed up verification of trust. Say a website is being provided by CA Eastwood. The browser asked Dunkirk about Eastwood, Dunkirk says yes Eastwood is good. Your browser asks Catskills if Dunkirk is trusted, Catskills affirms Dunkirk is trusted. Your browser then asks Bridgeport if Catskills is trusted, which it says Bridgeport is trusted. Finally, your browser asks Alpha if Bridgeport is on the up & up, and it is so your webpage you asked for shows up on the screen instead of an SSL warning screen.
Much of this is silly, the publisher decides Catskills is as far down as it will be asking, instead of going to the Internet and verifying up and down the chain every little detail-- many of the bits and pieces are installed right in the browser reduces a 5 entity request process by three requests, lessening load times and network traffic.
On a sort of related note, these preinstalled certifications are a good reason to keep your browser updated. Changes in which certs are sanctioned for good or bad happen with browser application updates.
And at a high level, that is how it works.
Protip for getting to the bottom. After installing the browser-- you can install the certificates your favorite sites use with the publisher installed certs and it can help load times-- more for smaller sites that may be paying bottom dollar for SSL certificates from a CA in the nosebleed seats of the chain of trust.
The short answer is:
Private key on top.
Certificate from the signing authority in the middle.
Certificate Authority Chain file next.
https://github.com/bradchesney79/make-concatenated-ssl-pem
I have seen people refer to both the Certificate Authority Chain file and the file my script creates as a bundle. That is wrong-- the bundle is all two or three things (sometimes the chain file is optional).
If you want to know more about why and how certificates work, keep reading.
You start by generating a private key, this is a string that can be used mathematically to modify data in a way that it is not easily read by conventional means. This key is generally used to make a certificate signing request (CSR)-- it is a block of text based upon the private key that allows a Certificate Authority to issue an SSL certificate without you giving them your private key.
A Certificate Authority(CA) signs and distributes SSL certificates. SSL certificates are used in a similar manner as a public key and has meta data about your site such as the domain name secured, where the 'owner' of the site says the site is based, what level of 'reversible entropy(chaos)' is used to encrypt the data, what type of encryption to use, and sometimes less commonly used factoids. You will see 2048-bit or SHA256 for current levels and types of encryption for instance.
There is one root Certificate Authority in a chain-- which is conceptually shaped more like a tree in reality. The next top most Certificate Authorities are all verified as trusted by the root Certificate Authority. And layer upon layer so on and so forth so that the demonstration CA "Deering" and CA "Dunkirk" are trusted by CA "Catskills" who in turn is trusted by CA "Bridgeport". CA "Bridgeport" is trusted by none other than the root CA, CA "Alpha".
The Certificate Authority Chain file allows the browser to identify which signing authority said the site in question can be trusted. Due to it being a chain of trust, there may be more than one block. Some CA Chain files have more blocks to facilitate verifying trust for web 'agents' (usually a browser) in case the parent entity issuing the certificate isn't one your browser inherently trusts.
Certificates that are inherently trusted happen because the entities publishing the browser software may decide to include portions of the chain to bypass certain lookups and speed up verification of trust. Say a website is being provided by CA Eastwood. The browser asked Dunkirk about Eastwood, Dunkirk says yes Eastwood is good. Your browser asks Catskills if Dunkirk is trusted, Catskills affirms Dunkirk is trusted. Your browser then asks Bridgeport if Catskills is trusted, which it says Bridgeport is trusted. Finally, your browser asks Alpha if Bridgeport is on the up & up, and it is so your webpage you asked for shows up on the screen instead of an SSL warning screen.
Much of this is silly, the publisher decides Catskills is as far down as it will be asking, instead of going to the Internet and verifying up and down the chain every little detail-- many of the bits and pieces are installed right in the browser reduces a 5 entity request process by three requests, lessening load times and network traffic.
On a sort of related note, these preinstalled certifications are a good reason to keep your browser updated. Changes in which certs are sanctioned for good or bad happen with browser application updates.
And at a high level, that is how it works.
Protip for getting to the bottom. After installing the browser-- you can install the certificates your favorite sites use with the publisher installed certs and it can help load times-- more for smaller sites that may be paying bottom dollar for SSL certificates from a CA in the nosebleed seats of the chain of trust.
