SSL protocol mandates authenticating the Server before establishing the session and this is done within initial SSL handshake. Every resource which is serving any content or service on SSL must have its Server certificate which is used for authentication with client. This may sound little odd to begin with that while client initiates the connection still Server has to mandatorily authenticate its identity to Client. This is how the SSL trust model was defined and is successful today…
Now the question is where do you get the Server certificate from? Well, you can create your own certificate using openssl based tools and use for the service. But then how does client authenticates and trusts the certificate?? A certificate created by self has an issuer (local) which is certainly not known to the client and thus the trust chain cannot be established. Thus we have global certificate authorities who issue the end certificates and build up trust model as the clients trust these certificate authorities. If you check your client browser, there is a trusted certificate store where you will find ROOT and Intermediate CA certificates which the client trusts.
So what is a trust chain? This is the key ingredient to the complete SSL authentication model. A client says that unless I know and trust the issuer of Server certificate, I cannot establish the trust chain thus cannot trust the Server certificate. A client can chose to ignore the trust chain but then you end up compromising the whole value offered by SSL protocol. Anyone can forge a certificate for a different service and get clients to connect to it if the trust chain is not validated.
You must be wondering why I am calling it trust “chain” all the time. When the trust model initially began every certificate was issued by Root or top level Intermediate CAs. Thus the client can trust your Server certificate if it was issued by one of the top level CAs as it has the CA in trust store. As the need and requirement of Server certificates grew, most of the key Authorities created multi-level Intermediate CAs and the end Server certificate can be issued by Intermediate CA at any level. Now clients only have top level certificates and your certificate was issue by an Intermediate CA which is five levels down in the trust chain. Unless you present the Server certificate along with the Intermediate CAs which can complete the chain with what Client has, the trust will not be established. This is becoming a common scenario and use case given the certificate demand.
On NetScaler you can add the Server certificate and all the Intermediate CA certificates manually and then link them to create a chain. This chain needs to be created manually which most of the time runs into configuration issues like:
– Separating Server and Intermediate CAs from the flat file
– Certificates not in proper PEM format
– One of the Intermediate CA is placed in wrong order
Moreover it is a tedious exercise to do the certificate linking on NetScaler. What we have done recently is to let you specify a certificate bundle which has the Server certificate along with all Intermediate CA certificates to complete the trust chain. This enhancement makes it very easy to get all the certificates together in single flat file and then you chose to bundle them together with new option “-bundle YES” in “add ssl certkey” command. This new option reduces the effort and combines following steps:
– Adding Server certificate and Key
– Adding multiple Intermediate CA certificates
– Linking Server certificate to issuer Intermediate CA
– Creating further link in between the Intermediate CAs
More than configuration, it takes lots of effort to ensure that you build the correct chain so that the trust check passes on client end. This enhancement helps you to get this complicate configuration done in easy and simple steps…