CORBA C++ client: Certificate chains

Often a certificate authority (CA) obtains its authority to sign certificates from another CA. This is particularly common for in-house CAs. In other words, you might deem a certificate signed by a particular CA to be legitimate, not because of who the CA is, but by virtue of that CA having been authenticated by another CA. In this case, the certificate of the requesting principal is signed with the certificate of its CA. That CA's certificate is signed with the certificate of the authorizing CA; the CA that authorized the first CA to sign the certificate for the requesting principal. This is referred to as a certificate chain. A certificate chain can be long.

Each successive certificate in a certificate chain represents the next higher certificate group. You can even create arbitrary, intermediate CA certificates that you use to sign such groups of principal certificates. Certificate groups are an important element in the organization of hierarchical trust relationships. For example, you can combine a set of servers into a server group. Assuming you assign each server its own certificate (each representing the server principal of each server) you can sign each of those server certificates with the same common group certificate. The certificate of that server group can then be combined with the signing certificates of other server groups, and all signed with another common certificate representing the super-group. This can go on until eventually there is one or more certificates that are self-signed. These self-signed certificates are referred to as root-certificates; they basically represent the root of the certificate hierarchy below them.

When verifying the validity of a certificate, you must decide who in the certificate chain you are going to trust. You could form your trust in individual certificates, in some intermediate Certificate Authority, or the root authority. We refer to this as the trust-basis for validating certificates. If your trust basis is in individual certificates, then you must retain a list of each individual certificate that you want to recognize. If your trust basis is in the root authority, then you only have to retain the certificate of that authority.

If you ever lose trust in the certificate authority, basically if any certificate issued by that authority is compromised, then you must change the certificate of that authority, and reissue every certificate issued by that authority previously. If your trust was in the root authority, this can be a major exercise. Alternatively, you can reach some balance by establishing your trust-basis in some intermediate authority. (This reduces the impact from losing the trust-basis in that intermediate authority to only the certificates issued by that authority.)


Related tasks
Supporting SSL for CORBA C++ clients
Enabling SSL certificate security between a CORBA C++ client and an EJB server



Searchable topic ID:   ccor_ssle
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/corba/concepts/ccor_ssle.html

Library | Support | Terms of Use | Feedback