CORBA C++ client: Certificate authorities

A certificate authority (CA) is someone that is assigned the responsibility for signing your certificates. The process of signing the certificate is an act that warrants the authenticity of the principal represented by that certificate. In other words, the certificate authority has done whatever it takes to ensure that the requesting principal is who they claim to be, and sealed that authenticity by digitally signing the certificate. The CA signs the principal's certificate with their own (the CA's) certificate.

Anyone can be a certificate authority. Most often you either trust a particular administrative group within your enterprise to be the CA, or in some cases you might prefer to delegate this responsibility to any one of a number of commercial CAs.

In the normal process, if you want to obtain a digitally-signed certificate that represents who you are, you begin by producing a Certificate Signing Request (CSR) using your local software. You then submit this CSR to the CA, along with any accompanying information that is needed to authenticate you. The CA does what they have to do to verify your authenticity and, if this is successful, signs your certificate and returns it to you. Often, this process can be completed electronically through either e-mail or through the world-wide-web.

Each CA has their own process. What the CA does to verify you depends on a number of conditions. Ultimately, the reputation of the CA is absolutely essential to their business success. If they fail to properly authenticate a requesting principal properly, accidentally handing out a certificate that the principal then uses to misrepresent themselves, then the CA's reputation is at stake. You are likely to loose faith in that CA and no longer trust the certificates that they sign. Consequently, principals will soon stop using that CA to sign their certificates, because you have stopped recognizing their authority. As a result, CAs typically go to great lengths to ensure the authenticity of their requesting principals. They may perform background checks, verify credit histories, post office registries, business records, and even criminal histories. This process is in many ways equivalent to obtaining a passport; the Passport Office requires that you provide some proof of your legitimacy, such as a birth certificate before issuing you a passport. Other countries accept that the passport proves who you are, trusting that the Passport Office has provided this assurance through its own validation checks and sealed that validity in the physical packaging of your passport.

If you establish your own internal CA (for example, within your systems management group), then you can use less complicated procedures to authenticate certificates. For example, you can verify the requesting principal in your employment records, or based on a previously defined planning manifest, perhaps by listing all of the server principals that you plan to deploy in your enterprise as part of some major application delivery plan.


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_ssld
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_ssld.html

Library | Support | Terms of Use | Feedback