Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

SSH Tectia

Certificate Enrollment

To add a new end entity to a PKI, the end entity has to create a key pair, and a certification authority (CA) has to certify the key pair. This process of an end entity enrolling in a PKI is commonly known as certificate enrollment. In many cases, the CA or a separate RA gives the end entity the certificate on a smart card or a USB token, in which case the end entity certificate enrollment is not needed at all.

Certificate enrollment

Figure 6.1. Certificate enrollment

An example of a certificate enrollment process is shown in Figure 6.1. It consists of the following steps:

  1. The end entity obtains the CA certificate (this is the first step of the enrollment process in most cases).

  2. The end entity generates a key pair and a certification request for the key pair. The public key is included in the request along with the name and other information identifying the end entity.

  3. The end entity sends the request to the CA.

    The CA receives the information, and takes steps to ensure that the identity information is correct. The exact steps depend on the security policy of the CA. For example, the policy could require that the end entity knows a valid pre-shared key (one-time password), or that the CA administrator contacts the end entity offline before manually approving the request.

    The end entity must also prove to the CA that it is the owner of the key pair (proof of possession). Usually this is achieved by signing the certification request with the private key.

    In the certification request, the end entity may define the values wanted for the certificate. The CA, however, considers the request as a wish list, and under its own policies, it can deny the request completely or modify the requested values.

  4. If the identity is valid and can be trusted, the CA creates a public-key certificate and signs it with the CA's own private key.

  5. The CA sends the certificate containing the public key, identity information, and the CA's signature back to the end entity. The CA may also optionally publish the certificate in a directory.

Step 3 in the above process is where the identity establishment in certificate authentication is performed. Depending on the size of the certification authority, it might have one or more registration authorities (RAs) to take care of the identity establishment to further improve scalability. In that case, the user contacts the RA instead of the CA when requesting to enroll a certificate, and the RA performs the identity establishment.

The main difference in the above procedure compared to public-key authentication is that the responsibility of identity establishment is transferred to the trusted third party (CA and its RAs). There is no need to trust individual entities.