PKCS#10

PKCS#10 is a standard format for requesting X.509 certificates from the certification authorities.

The following are the steps involved from requesting a certificate to certificate issuance :

  • Applicant generates a key pair i.e. private and public key.
  • Applicant stores the private key at some secure location. The secure location could be a hardware crypto device (HSM or USB token etc) or software (PKCS#12, JKS, Windows key store or MAC key chain etc).
  • Applicant generates a PKCS#10 structure. It mainly includes the subject information, public key generated in the above step and optionally PKCS#9 attributes.
  • The applicant signs the PKCS#10 using the private key generated in the above step.
  • CA receives the PKCS#10. The transport mechanism used to send the PKCS#10 to the CA could either be a standard request/response protocol (CMP, CMC, EST, SCEP, XKMS or CA proprietary interface etc) or it could involve sending PKCS#10 to CA using the SMTP protocol.
  • CA first verifies the PKCS#10 signature with the public key placed in the PKCS#10. If the signature is verified successfully then it is a proof that the applicant has a possession of the corresponding private key.
  • It depends on the CA policy, how much subject information and optional PKCS#9 attributes from the PKCS#10 is to be used in the final issued certificate.
  • CA sends the final issued certificate along with the certificate chain to the applicant.

Structure

The structure of the PKCS#10 in ASN.1 format is shown below. You must be capable of reading the ASN.1 in order to fully understand the below PKCS#10 structure.



1) in red specifies the version number. 2) specifies the subject information. There are three RDNs (Relative Distinguished Names) currently visible in this structure i.e. CN, OU and O. Other RDNs could also be placed. 3) specifies the subject public key information. As RSA key is used, you can see the public modulus and exponent. 4) specifies the optional PKCS#9 attribute i.e. challenge password 5) specifies another optional PKCS#9 attribute i.e. extension request. In this section, currently key usages and extended key usages are placed. The CA could use all of these key usages or extended key usages in the final issued certificate or completely ignore it. It depends on the CA policy. As per extension request structure, one can place any of the X.509 certificate extensions including subject alternative name under this structure 6) specifies the signature algorithm used. In this case 1.2.840.113549.1.1.11 is used which is an OID of SHA256WithRSAEncryption algorithm. 7) specifies the signature value.

I used BouncyCastle library for the creation of the above PKCS#10.