Chapter 6. Functionality Descriptions

Table of Contents

1. CA Initialization
1.1. Phase I: Initialize the Certification Authority
1.2. Phase II and III: Create the initial administrator and RA certificate
2. Node Initialization
3. CSR Handling - a request HOWTO
3.1. Ways to request a certificate
3.2. Edit a certificate signing requests
3.3. Approve certificate signing requests
3.4. Issue a certificate from a certificate signing request
3.5. Certificate enrollment
3.6. Delete certificate signing requests
4. Certificate Handling
4.1. Find a certificate
4.2. Download
4.3. Start revocation
4.4. Write an email to the owner
4.5. Informational messages and their meaning
5. SCEP
5.1. SSCEP
5.2. NetScreen ScreenOS
5.3. F-Secure VPN+
5.4. Cisco PIX

1. CA Initialization

The initialization of the CA consists of three phases and can only be executed once. The first phase is mandatory. It initializes the CA itself. The second and third phase are optional. They create the first two certificates. Phase two creates the first certificate for an operator and phase three creates the certificate for the online web server. First we describe phase one and then we describe phase two and three in one section because they are nearly identical.

Figure 6.1. Phases of the CA initialization

This is OpenCA's screen of the different phases of the CA
                        initialization.

1.1. Phase I: Initialize the Certification Authority

The first phase of the initialization of OpenCA is used to setup all the cryptographic mechanism which are necessary to run a CA. This include things like a private key, a certificate signing request (CSR), a CA certificate and the certificate chain of the CA. If you completed this phase successfully then your CA is ready for operational usage. The other phases only do some optional tasks.

Figure 6.2. Phase I of the CA initialization

This is OpenCA's screen of the first phase of the CA
                            initialization.

1.1.1. Database Setup

This link initializes the database. If you use OpenCA::DB then the backend consists of DBM files. If you use OpenCA::DBI then the backend consists of an SQL database. Today we support MySQL, PostgreSQL, IBM DB2 and Oracle. If you need another database then please contact us.

1.1.2. Key pair setup

Here we do the keygeneration for the CA. You have to enter the algorithm for the key itself, the algorithm for the encryption of the key and the length of the key. If you entered all the cryptographic paramters then you must enter the passphrase if you use an software token from OpenSSL. If you use a hardware token then you must active this token by the appropriate action.

1.1.3. Request setup

If you start creating a new certificate request for the CA certificate then you will be prompted for several informations which will be needed to create a certificate of the style “emailAddress=...,cn=...,ou=...,o=...,c=...”. After you entered all the data OpenCA will display the complete subject of the request. This is the last time when you can modify the subject. If you need another style e.g. dc style then you can enter in this field a subject of your kind. After you entered all parameter for the request the private must be activated (usually via a passphrase).

1.1.4. Certificate setup

There are two general options for a CA certificate in OpenCA. You can use the CA as a root CA then you have to create a selfsigned certificate or you can setup a sub CA then you have to go to another CA and let it sign your request. Both variation need a different handling.

1.1.4.1. Selfsigned CA certificate

If you want to create a new root CA then you have simply to create a new selfsigned CA certificate. This is much more simple then to setup a new sub CA but it is more dangerous. Before you create a new CA certificate please check OPENCADIR/etc/openssl/openssl.cnf. The extension are in the section v3_ca. It is highly recommend to set the option subjectAltName explicitly. If you click on the link then you have only to activate the private key and the rest will be done automatically.

1.1.4.2. Signed by another CA

We talk about a “root CA” in this section but the CA which issues the CA certificate for the new CA which is a sub CA has not to be a root CA. We only use this term to have to different unique namespaces for the CAs in this section.

First you have to export the request to the root CA which has to issue your CA certificate. OpenCA will create a tar file on your export media. This tar file contains a file careq.pem. This file is your request in PKCS#10 format. The encoding is PEM (base64). Please go with this request to the root CA and follow its instruction for request processing.

If the root CA issued a certificate for the new sub CA then you have to create a new tar file on your import media. The tar file must contain the file cacert.pem which is the new CA certificate. If you click on the link for th import of the new CA certificate then OpenCA copies the file to all necessary places.

1.1.5. Final setup

The last steps can also be done on the interface for the nodemanagement but it is a good idea to do it during the intialization to get a consistent state. The rebuild of the CA chain is necessary to verify digital signatures correctly. If you want to setup a sub CA then you must add all CA certificates of the CA chain in PEM format to the directory OPENCADIR/var/crypto/chain/ before you rebuild the chain.

The really last step is the export of the configuration to the online server(s). The most OpenCA users ignore this step and handle all the communication between the different nodes of the PKI hierarchy via the interface for the node management. If this is you first OpenCA usage then you should export the configuration and import it into the online server.

1.2. Phase II and III: Create the initial administrator and RA certificate

These two phase are used to create the first certificates of the infrastructure. You can create these certificates via a seperate RA and public interface too but usually the people want only to setup one online RA and this RA should run with https. So they need at minimum a certificate for the RA's web server. If they use an online RA and it should be a secure solution then the operators must sign a request if they approve a request. So they need an initial user certificate. If the operators have to login via a digital signature and not with login and passphrase then the first user certificate is mandatory. If you compare the two screenshots then you will see that only the names of the forms differ.

Figure 6.3. Phase II of the CA initialization

This is OpenCA's screen of the second phase of the CA
                            initialization.

Figure 6.4. Phase III of the CA initialization

This is OpenCA's screen of the third phase of the CA
                            initialization.

Both phases use the same process like for every normal certificate signing request. Sou can simply read the user guide section where the different requests and their handling will be described. The phases consists of four steps:

Create a new request

This link uses the automatic browser detection of OpenCA so the key and request will be generated by the browser. If you want to use smartcards for the user certificates then you can create the first keypair on a smartcard too if you use the PKCS#11 or CSP drivers of the vendor. It is recommended to use the role “CA operator” for the first user certificate.

Edit the request

Like editing on the RA. See Section 3, “CSR Handling - a request HOWTO” for more details.

Issue the certificate

Like the issue link if you view a certificate on the CA. See the request handling in the user guide.

Handle the certificate

See Section 4, “Certificate Handling” for an explanation of the options.