Forum Discussion
Difference between Root Cert, Intermediate Cert and SSL Cert
If I may expand, PKI or "Public Key Infrastructure" is a multi-layered system that uses cryptography to establish relationships between entities, and it depends on an understanding of the term "trust". A "root" authority is a certificate issuer that parties choose to trust (explicitly). It is usually self-signed (self-issued) and very highly protected. An intermediate authority is a certificate issuer that has itself been issued by a root or another higher level intermediate authority. There are a few reasons why an intermediate authority might exist:
-
Because the root authority's security is so important, its exposure is limited. It's turned on just long enough to issue intermediate authority certificates, and then turned off and put in a vault.
-
A certificate authority's job is essentially to issue certificates - both client certificates and server certificates, and because an authority may be in business to issue lots of certificates, putting that kind of load on a single authority is unwise. A root authority can issue several intermediate certificates, and those authorities can then issue client and server certificates.
An SSL cert, in the context of PKI, is just a certificate issued by some authority that is used in SSL communications.
Again, the relationship between these entities is based on cryptography, specifically digital signatures. PKI is also a "two-key" system where an entity will possess a "public" certificate that it can share with the world, and a "private" key that it must keep safe and hidden. The public certificate and private key are cryptographically paired such that one can only decrypt a message encrypted by the other. (Message) encryption therefore is the process of encrypting something with a recipients public certificate so that only the recipient (the holder of the private key) can decrypt it. Digital signature is the reverse of that - encrypting something (usually a hash of some data) with a private key so that a remote party can 1) decrypt it with the sender's public certificate, and 2) know that the sent message is verifiably from the sender (because no one else would have the sender's private key). A certificate authority issues a certificate and digitally signs that certificate so that anyone validating that certificate will know that it was issued by that authority (a process called "non-repudiation").
In any case, when a root authority creates an intermediate authority (and that intermediate authority optionally creates another intermediate authority), which then creates a user or server certificate, a "chain" has been built. Example:
root CA -> intermediate CA -> server certificate
When a client and server communicate via SSL, the server will initially send its certificate to the client. The client then must be able to build a chain of trust from that certificate to an explicitly trusted root authority (by virtue of its presence in a local "trust store"). Consequently, when the client sends its certificate to the server (if client certificate authentication is enabled), the server must be able to build a chain of trust between the client's certificate to an explicitly trusted root authority (by virtue of its presence in a local "trust store"). In the case of BIG-IP as the server, the authority certificates must be in a "bundle" file and applied to the "Trusted Certificate Authorities" option in the client SSL profile. This is simply a text file that contains the PEM-encoded version of ALL of the authority (public) certificates needed to build a complete chain of trust between the client's certificate and the self-signed root.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
