How Certificates Are Created

  • [アーティクル]

The following text is a simple copy/paste from the TechNet article How Certificates Work (section How Certificates are Created). Why am I posting this information to the blog? Quite simple: I recognize that it is often overlooked that the key pair generation is always the very first step of a certificate creation.

Certificates are issued by a CA, which can be any trusted service or entity willing to verify and validate the identities of those to whom it issues certificates and their association with specific keys. Companies might issue certificates to employees, schools might issue certificates to students, and so on. Of course, a CA’s public key must be trustworthy or the certificates it issues will not be trusted. Because anyone can become a CA, certificates are only as trustworthy as the authority that issues the underlying keys.

The following six steps describe the process of requesting and issuing a certificate.

  1. Generate a key pair - The applicant generates a public and private key pair or is assigned a key pair by some authority in his or her organization. (at a command-line, this part is covered by any certreq –new command)
  2. Collect required information - The applicant collects whatever information the CA requires to issue a certificate. The information could include the applicant’s e-mail address, birth certificate, fingerprints, notarized documents — whatever the CA needs to be certain that the applicant is who he or she claims to be. CAs with stringent identification requirements produce certificates with high assurance — that is, their certificates generate a high level of confidence. CAs themselves are said to be of high, medium, or low assurance (at a command-line, this part is covered by any certreq –new command).
  3. Request the certificate - The applicant sends a certificate request, consisting of his or her public key and the additional required information, to the CA. The certificate request, which is signed with the client’s public key, can also be encrypted by using the CA’s public key. Many requests are made by using e-mail, but requests can also be sent by postal or courier service — for example, when the certificate request itself must be notarized. (at a command-line, this is done with certreq –submit)
  4. Verify the information - The CA applies whatever policy rules it requires to verify that the applicant should receive a certificate. As with identification requirements, a CA’s verification policy and procedures influence the amount of confidence generated by the certificates it issues.
  5. Create the certificate - The CA creates and signs a digital document containing the applicant’s public key and other appropriate information. The signature of the CA authenticates the binding of the subject’s name to the subject’s public key. The signed document is the certificate.
  6. Send or post the certificate - The CA sends the certificate to the applicant or posts the certificate in a directory, as appropriate (at a command-line, this is done with certreq –accept)

Comments

  • Anonymous
    September 28, 2010
    Well explained. I have a question. Who is responsible for the quality of the key pair? Suppose I generate a weak key pair, will the CA sign my poor public key or not? This could happen because applicants usually are not security experts, and they may make any mistakes.