intermediate SSL certificates

[Shivkumar]

Hi,

In SSL what is purpose of intermediate certificate ?

Thanks,
Shiv

[Raj D.]

Shiv ,

You can check this link:


http://h20338.www2.hp.com/hpux11i/downloads/5981-2796EN.pdf


http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=994087&admit=-682735245+1153108931173+28353475




Cheers,
Raj.

[Raj D.]

Shiv,

Also check this link for :
Open SSL Certificate authority setup:

http://sial.org/howto/openssl/ca/


Cheers,
Raj.

[Arunvijai_4 · Accepted solution]

Hi Shiv,

Here it is,


What is an intermediate certificate?
Last Updated: April 27, 2006 12:18 PM
Print This Article

In order to enhance the security of the Root certificate we have created an intermediate certificate from which SSL certificates are signed and issued. An intermediate certificate is a subordinate certificate issued by the trusted root specifically to issue end-entity server certificates. The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. Such certificates are called chained root certificates.

Creating certificates directly from the CA root certificate increases the risk of root certificate compromise, and if the CA root certificate is compromised, the entire trust infrastructure built by the SSL provider will fail. The usage of intermediate certificates for issuing SSL certificates to end entities, therefore, provides an added level of security. You must install the intermediate certificate in your Web server along with your issued SSL certificate.

Using intermediate certificates does not cause installation, performance, or compatibility issues.

http://help.godaddy.com/article.php?article_id=868&topic_id=235&&

-Arun

[Matti_Kurkela]

If you are a Certification Authority (CA), any change to your primary certificate is a big deal: the primary certificate needs to be re-distributed to *all* the users of the CA before the change is complete. If the CA's primary certificate on the user's computer expires before he/she has got an update for it, the entire CA and all the certificates verified by that CA become useless for him/her. An emergency renewal for a CA's primary certificate is by far the most painful action a CA may need to perform.

This is why a CA prefers to have a long expiration time (several years at least, often a decade or more) on its primary certificate.

However, the CA wants to keep the private key for its primary certificate under lock and key (and away from a running computer) as much as possible. People make mistakes.

So, instead of using the primary certificate's private key to certify customers' certificates, the CA can choose to use its primary certificate for the creation of intermediate certificates only.

The intermediate certificates will still be CA certificates, but they have a more limited validity time. They may have other restrictions on them too: the intermediate certificate assigned for certifying SSL sites can be marked as invalid for certifying Java applets and vice versa.

After the system of intermediate certificates is designed and set up, the personnel of the CA will normally use only the intermediate certificates. The private key for the CA's primary certificate can then be kept locked in a vault: it should be needed only once or twice a year or so. The only reason for unplanned need for the primary key will be the compromise of one of the intermediate certificates. In that situation, the primary key is needed to create a revocation certificate for the intermediate certificate, and to create a new intermediate to replace the compromised one.

To validate a SSL certificate created in this way, the client needs to get only the primary certificate from a trusted source. Often, the primary certificates of the major CAs are bundled with the client software.

If a SSL server is certified using an intermediate certificate that is unknown to the client, the server can deliver the public part of the CA's intermediate certificate as an appendix to its own certificate. The client will hopefully have the CA's primary certificate and will use it to verify the CA's intermediate certificate. After that, the client can trust the intermediate certificate came from the CA and can be used to verify the server's certificate.

It is possible (and recommended) to set up a limit to the allowed number of intermediate certificates and build it into the primary certificate, so this "chain of trust" should never be indefinitely long.