Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Difference between Root Cert, Intermediate Cert and SSL Cert

Hello Every one,

Can any one please help me with difference between Root Cert, Intermediate Cert and SSL Cert?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

1.If the server sends only its own certificate and the intermediate one then there’s no need to send the root CA certificate, as the client should already have this – otherwise the whole point of the PKI is defeated. why should we include root CA in the chain?

You're absolutely correct that the server should (normally) send all certs in the chain up to but not including the root CA. To your question, the chain or trusted certificate authorities options are for validating the client certificate and have nothing to do with the server certificate.

2.As it is mentioned each certificate is trusted by the parent one i.e server is trusted by intermediate CA and intermediate by root and finally root is trusted(cryptographically),then why can't we send root alone?

Because PKI is based on a "CHAIN OF TRUST". To your first point, the root CA cert is never sent because it requires an explicit trust mechanism - you have to manually assign trust.

0
Comments on this Answer
Comment made 06-Nov-2013 by sundeep 0
Thanks very much for the response .Then how is this different when using RootCA in a web browser vs LDAPs authentication (requiring full chain certificate).
0
Comment made 06-Nov-2013 by Kevin Stewart
It shouldn't be any different. Both protocols are layering SSL.
0
Comment made 06-Nov-2013 by sundeep 0
Hi Kevin, I really appreciate your response.But I am confused little or may be completely :( 1.I have server A that uses RSA cst library for ldap authentication and RSA says we need to give a full certificates in chain in order to successfully authenticate.i.e. root->intermeditae ca->server ca..But usually in web browsers we use only root CA.Confusion for me here is why I cannot use only root in my cst library like how I use in browsers?How RSA certificate chain trusting PKI dynamically everytime is different than the browser
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Perhaps wikipedia has a better explanation for the whole thing.
Here is a quick answer for the BIG-IP related part.

  1. a private key is generated on the big-ip and kept in the filestore (will be used later in your clientssl profile as 'key')
  2. a certificate signing request will be created for the specific hostname and with some specific attributes
  3. you will submit the certificate signing request to a certficate authority (CA)
  4. the CA with return a signed certficate. You will import it into the TMOS filestore and use it in your clientssl profile as 'certficate'.
  5. the CA will also provide a so called intermediate CA file or chain certificate. It proves, that your choosen CA is trusted by one of the root CAs. You will need the intermedidate CA certificate as 'chain' certificate in your clientssl profile

The root CAs are already trusted CAs in the clients browsers. By presenting an intermediate certificate you prove the full chain of trust between the signed certficate, the signing CA and one of the root CAs.

Makes sense?

0
Comments on this Answer
Comment made 23-Sep-2013 by Amit V Chavan 86
Hi Stephan, Thanks for your reply. You explained very well process of installing SSL Certs in LB, but I am looking for more specific meaning of root cert, intermediate cert and SSL Cert. Can you please help me to understand this. Thanks again.
0
Comment made 24-Sep-2013 by Stephan Manthey 3737
It will be hard to top Kevin´s reply. There is nothing to add. Just to stick with the BIG-IP: The Root CA is one of the top level certificate authorities, i.e. Verisign. Your web browser already trusts Verisign and will get updates on trusted CAs by regular browser updates. A Root CA signs certificates for other certificate authorities. To prove the authenticity of a certificate signed by one of these 2nd or 3rd level CAs an intermediate CA file is required. It contains the necessary information to demonstrate, that these CAs are really authorized to sign a server certificate for you. The server certificate and it´s private key are the most interesting files for you. The private key should never ever be given to somebody else. Make sure not to export it in a .ucs archive to be provided to somebody else (i.e. F5 support). The server certificate instead is provided during the SSL handshake along with the intermediate certificate. This way the client can verify, that your server certificate was signed by a 2nd or 3rd level certificate which was certified by one of the root CAs.
0
Comment made 07-Jun-2017 by m1978 67

Hi Stephan,

We want F5 to do offloading. So client to F5 is https and F5 to the server is http. Now in relation to clientssl profile as per your comment (correct me if I am wrong) F5 needs to have CA signed certificate and chain or intermediate certificate. Now question is root certificate and CA signed certificate same thing ? also on client side what certificate they need to install to trust the root. For example if they dont have root certificate in their browser, how can they trust it ?

I have read your answer. So it means client SSL profile have two sort of certificate

0
Comment made 09-Jun-2017 by Stephan Manthey 3737

Hi m1978,
the chain of trust works as follows:

A root certificate authority (Root CA; btw, there is a lot of them) signs certificates of intermediate certificate authorities (intermediate CAs). An intermediate CA may signs certificates of othere intermediate CAs or sign server certificates or client certificates.

Certificate signature:
Signing means to add create a hash value for elements of a certificate signing request (CSR; provided by you) and to encrypt it with the signing CAs private key. The mathematical relationship of public and private keys allows to decode the signature based on the signing CAs public key. The signing CAs public key is provided in the signing CAs certificate.

If a party provides a server certificate and the certificate of the signing intermediate CA, the client will use the public key of the signing intermediate CA to decode the server certificates signature and verify matching hash values for the server certificate elements. In case the hash values do not match, the trust is broken.

Exactly the same mechanism (validating hash values by decoding signatures using the public key of the signing CA) works for validating the certificate of the intermediate CA and the CA which signed the intermediate CA (could be another intermediate CA or finally a Root CA).

The client (i.e. the web-browser) holds a list of trusted Root CAs. It will be updated with new browser versions.

The server has to provide the server certificate and all involved intermediate CA certificates (containing each the specific intermediate CAs public key) to the client during the SSL- handshake.

This enables the client to validate each certificate by going up the chain step-by-step: In the first step it will validate the server certificate by decoding its signature using the public key of the signing intermediate CA (i.e. Foo). In the second step it will validate the intermediate CA by decoding its signature using the public key of CA (might be a root CA or another intermediate CA) which signed the Foo intermediate CA.

That´s why it will be required to provide the server certificate and the so called chain, which contains the certficates of all involved intermediate CAs. These are two text files. Both files will be provided by the intermediate CA which signed the server certificate.

One more thing one the public key of your server certificate. There is the same mathematical relationship as described above between the public key and private key of your server certificate. It will be used during the SSL handshake. The client encrypts some key material servers public key (retrieved by the client out of the server certificate) and sends it to the server. It can be decrypted by the server using the private key. If the server does not have the matching private key it cannot decode the key material and the handshake brakes.

That´s why the cert-key-chain configuration of a client-ssl profile contains a server certificate, the matching private key (which never ever has to leave your site) and the certificate chain of all involved intermediate CAs.

If the Root CA directly signs the server certificate (as in your example) by using exactly the same mechanism as described above, it will not be necessary to add a chain because there are no intermediate CAs involved. But as well the client has to have this particular Root CA in its list of trusted Root CAs. If the signing Root CA file is not in the list, the client wont trust the server certificate. No way around to brake this chain.

Otherwise someone else may create an own Root CA, sign whatever certificates he wants and spoof whatever website he wants.

You can create an own "private" Root CA by using tools like OpenssL, Microsoft server or whatever. You can add this new Root CA manually to the list of trusted Root CAs of browsers in your environment. Now they will trust server certificates which are signed by your own Root CA.

This underlines the importance of making sure private keys of CAs (and your "private" Root CA) dont get lost. Retrieving the complementary public key is easy for an attacker and from now he can intercept the chain by issuing valid and trusted server certificates or client certificates.

Cheers, Stephan

1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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:

  1. 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.

  2. 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.

0
Comments on this Answer
Comment made 23-Sep-2013 by Amit V Chavan 86
WOW! That's what the magical words I was looking for! Very nicely explained. Thank you very much Kevin for this wonderful answer. Appreciated your comment!
0
Comment made 06-Nov-2013 by sundeep 0
Hi Kevin I have below 2 quetions on certification chain issue 1.If the server sends only its own certificate and the intermediate one then there’s no need to send the root CA certificate, as the client should already have this – otherwise the whole point of the PKI is defeated. why should we include root CA in the chain? 2.As it is mentioned each certificate is trusted by the parent one i.e server is trusted by intermediate CA and intermediate by root and finally root is trusted(cryptographically),then why can't we send root alone? Root CA certificate | \--Intermediate CA (issued by the root CA) | \--AD server certificate (issued by the Intermediate CA)
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I would be willing to bet that you don't have to send the root CA for this to actually work. It doesn't make sense and, as you pointed out earlier, would completely invalidate the intent of PKI.

There are certainly exceptions to this rule based on the types of clients and/or services involved in evaluating these certificates, but a core function of The PKI trust establishment process is validating the chain of certificates up to a self-signed "anchor" - a root certificate that has been explicitly trusted by the client and/or server.

0
Comments on this Answer
Comment made 07-Nov-2013 by sundeep 0
Thanks very much for the response.Now I am more clear on this.
0
Comment made 25-Apr-2014 by Mike 0
Kevin and everyone, thank you for the great answers. You've made things much clearer.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Please help me out all of you experts. I have configured client side SSL profile and uploaded certificate, also put CA bundle of all certificates uptill root in Trusted certificate authorities. The problem i am having is that still the SSL secure handshake is failed. And Open SSl shows that there is a self signed certificate in the chain which is root certificate. How to tell F5 that root certificate will always be self signed and ignore it. I did all the need full in browser. Please help

0
Comments on this Answer
Comment made 09-Nov-2014 by Stephan Manthey 3737
Hi Muhammad, it will be necessary to add the intermediate CA / intermediate CA chain to the client-ssl profile. During the handshake the the client will now receive the server certificate and all certificates in the single cert or bundle chain as specified above. This way the client can verify the chain of trust from the server certificate up to a root CA he trusts. If you request / require a client certificate it will be necessary to validate the chain of trust up to the root CA which validates the client certificate. As there may also be intermediate CAs involved it will be necessary to verify the full chain as well. But for this part the virtual server has to trust a root CA and needs to know, which intermediate CAs are involved. This is a bundle you want to configure in the context of "client authentication" of your client-ssl profile. A nice tool to monitor the certificate exchange is ssldump as provided on the BIG-IP: ssldump -AdenN -i any host (your_client_ip) Using the command above may help you to troubleshoot the issue. Thanks, Stephan
0
Comment made 13-Jul-2016 by shubhank 1

We have an weird situation. While set upping a connection our application perform a bunch of security checks. One of these is to check if the chain length is correct. We know that it should be 3: Root, intermediate and server.

When we are connecting to a server using Android application we get as a response only two certificates intermediate and server - no root(anchor). But when we perform checking thought web browser we see 3 and on Android see two of them. Connection form iOS results in 3 certificates.

Is it a server or Android? What we can do to get also root certificate? Presently pinning in Intermediate only, will it be fine ??

0