The OpenCA Project[TODO]

OpenCA is a collaborative effort to create a public–key infrastructure. Programmatically, it resembles pyCA with the exception of using Perl instead of Python for the CGI scripts. It uses OpenSSL for the underlying cryptograpgic infrastructure. OpenCA is distributed with an Apache–style license.

OpenCA Layout

We describe the CA structure as used currently in OpenCA.

Figure 7-1. Current OpenCA Layout

The Certification Authority –– for security reasons and in accordance with the current layout –– should not be networked. It manually communicates with the Registration Authority, perhaps using removable media.

The Registration Authority should not have direct access to the Internet but be accessed through the RA Operator.

The RA Operator is the interface of OpenCA between users and the Internet.

OpenCA Abbreviations

Throughout the documentation we use the following terminology.

Table 7-1. OpenCA Abbreviations

TermOpenCA Object Name
Certification AuthorityCAServer
Registration AuthorityRAServer
RA OperatorRAOperator


The reader should notice the difference between the CA as an organisation or a company and the CA as CAServer. Currently, we do not differentiate explicitly and the user has to identify the correct meaning by the context.


In several parts of the documents we use the terms Certificate Signing Request and requests to describe the same thing. The latter term is common in programming contexts.

Software packages

This is the basic software used to implement OpenCA. Current (May, 2000) versions are depicted in the table following the list.

  1. Compatible Operating system like Linux ®, available from

  2. OpenSSL, available from

  3. Apache WWW Server, available from

  4. mod–ssl Apache module, available from

  5. OpenLDAP, available from

We subsequently install the OpenCA software. At the time of writing, the latest version is 0.2.0, available at

Table 7-2. Current Versions of OpenCA prerequisite software

SoftwareCurrent version
OpenSSL SSL/TLS software0.9.5a
Apache WWW Server1.3.12
modssl SSL/TLS Apache module2.6.4
OpenLDAP LDAP software1.2.10
Perl interpreter5.6.0

Functionality of the CA Server (CAServer)

The functionality of the Certification Authority Server is:

The source code describes the CA server as CAServer.

The following sections and subsections are the options presented to the user by the WWW interface to administer the CA. This interface is the recommended method of administration.


The content of this section is subject to change in the future.

Initialisation / CA Management

  • Generate new CA private key

    This procedure is described in the Section called Generate the RSA key–pair for a user/server in Chapter 4. Generating a new secret (private) key for a CA and overwriting the old one is an important procedure, since previously–issued certificates become invalid. The user is warned that the current CA private key will be overwritten.


    In fact, with the current version of OpenCA, the previous current key is not overwritten, as the software saves the current key in a file with an extension of .old. However, previous any previous keys are overwritten.

    The user is prompted with a dialog box for the CA secret key. This CA secret key is in fact the pass–phrase that protects the CA private key. For example, if we use RSA as the public key algorithm, the key generation procedure generates a set of very large numbers. A part of them constitute the private key. This information must not be compromised. In order to make it more secure, we encrypt this information with a block cipher like DES, Triple–DES or IDEA. Subsequently, when there is a need to have the value of the private key, the application asks us for the pass–phrase, decrypts the encrypted private key, and uses it.


    Safe choices for an encryption algorithm are Triple–DES (3DES or sometimes written DES3) and IDEA. DES is not considered a safe choice, unless key recovery is an issue. :) Apart from the joke, the user should be aware that using high–grade encryption does not mean that the system is secure. All components of a system need to be secure in order to have a secure system. In the case of OpenCA, there are a lot of components.


    It is common practice that once the private key is used by the application, it should not be kept in the computer's memory any longer. When there is a need for the private key, the application should ask for it. This is more secure but requires human intervention when there is a need for the private key. For example, when we need to restart a server.

    Next the user is asked for the size of the CA key in bits. This is the size of N in RSA, the product of the two large prime numbers. This affects the security of the Certification Authority.

    A choice of 512 bits is not considered safe while one of 1024 bits is considered relatively safe. 2048 bits are considered to be a secure choice with current (May, 2000) information about factorisation.


    Consider that when the key length rises, so does the time needed to generate and do operations with the keys. For instance, on a Pentium® Pro computer, generating a key of size 1024 bits requires approximately 3 seconds; 2048 bits requires around 13 seconds. The tests were carried out using the OpenSSL software and running the Linux® operating system. Key generation takes place once in the lifetime of the key. Other operations, like the signing and verification of digital signatures, take place more frequently and remain to be benchmarked.


    With Pentium® II or better computers, the size of 2048 bits is both a fast and secure choice. Once we click OK, the key–generation takes place. This takes several seconds. The user should wait for it to complete.

    You can find a sample encrypted private key in PEM format at the Section called Sample Encrypted Private Key in PEM format (2048 bits) in Appendix B.

  • Generate new CA Certificate Signing Request

    This is the procedure described in the Section called Generate a certificate request in Chapter 4. Essentially, the certificate request is generated to be later self–signed with the public key of the CA, generated with the previous option.

  • Export CA Certificate Request

    This option exports the CA certificate request generated above. A file is created in the file system that corresponds with the CSR.

  • Generate Self–Signed CA Certificate

    This option uses the generated CSR to create the CA Certificate. It signs it with the public key of the CA.

  • Export CA Certificate

    This option exports the generated CA Certificate or as it is sometimes called, the Root CA Certificate. Copies of this Certificate should be given to the public.


  • Import requests

    This imports requests (CSRs) for signing to the CA. The RAServer Administrator has used the Export requests command to export the Certificate Signing Requests to, possibly, a removable medium. With this command, the CAServer Administrator will retrieve them for signing.

  • Pending requests

    This shows the pending requests that reside on the CA. We should note that as request we describe the Certificate Signing Request. Pending requests are the requests that have been uploaded to the Certification Authority and wait to be signed.


    The same terminology, pending requests is used on the Registration Authority with a different meaning. On the Registration Authority, a pending request is a Certificate Signing Request that remains to be approved by the Registration Authority Administrator and be sent over to the Certification Authority.

  • Deleted Requests

    This shows the deleted requests to the CA. A Certificate Signing Request that has been uploaded to the Certification Authority may not be finally granted permission and be signed. With the current layout of the relationship of the CAServer and the RAServer, the RAServer signs each Certificate Signing Request with its own private key. The CAServer checks the signature and if it is verified, it creates the Certificate. Otherwise it deletes it and it is shown here.

  • Remove Deleted Requests

    This removes the deleted requests from the CA. It means that the requests are physically removed from the file system of the CAServer.


  • Issued Certificates

    This shows all Certificates ever issued by the Certification Authority.

  • Export Certificates

    This exports the Certificates to a removable media in order to be delivered to the RAServer. It is the responsibility of the RAServer to distribute the Certificates to the individual owner.

Certificate Revocation List CRL

  • Export CRL

    This exports the Certificate Revocation List to the RAServer. The RAServer has the responsibility to make the Certificate Revocation List known and available to the individual users.

Functionality of the RA Server (RAServer)

This is the functionality of the Registration Authority (RAServer) Server. The various local Registration Authority Operators communicate with this intermediary on behalf of the users' requests, in order to have access to the CA. No user communicates directly with the RA server. The RA server should be placed at a very high security level to prevent unauthorized access. The RA Server is administered by the Registration Authority Administrator. The actions available are listed next.

While perusing the source code, you will see the principal Registration Authority Server to be described as RAServer.


The content of this section is subject to change in the future.


  • Export Requests

    Export the approved requests to the CAServer.

  • Pending Requests

    Show Certificate Signing Requests waiting for approval by the RAServer Administrator. Approval can be based to Identification Documents or other credentials.

  • Approved Requests

    Show Certificate Signing Requests that have already been approved by the RAServer Administrator. These Certificate Signing Requests will be sent to the CAServer using the Export requests function.

  • Remove Exported Requests

    The approved requests, once they are exported to the CAServer, can be removed with this option.


  • Import CA Certificate

    This imports the Certification Authority Certificate and saves it on the local filesystem. This copy of the Certificate will be published using the adjacent commands to the interested parties.

  • Import New Certificates

    This imports the newly signed Certificates from the CAServer. The Certificates are copied to the local file system.

  • Export Certificates onto LDAP

    This command exports the Certificates to the specified LDAP server. The users will retrieve their Certificate by accessing the LDAP server, rather then contacting directly the RAServer.

Certificate Revocation List CRL

  • Import CRL

    This imports the Certificate Signing Request from the Certification Authority so that it can be published.

  • Export Certificate Revocation Requests

    This command exports approved Revocation Requests to the CAServer. Then, the CAServer revokes these Certificates.

Miscellaneous Utilities

  • Send e–mail to users for newly–issued certificates

    This informs the users that the Certificate has been prepared and that they should follow the indicated procedure to collect it.

  • Delete Temp files (After importing certificates).

    This is a clean–up command. With the current implementation of OpenCA, when the users are being sent a notification, temporary files are created to indicate the e–mail to be sent. If these files are not deleted, then, on the next batch mailing, users who have already received a notification are notified again.

Functionality of the RA Operators (RAOperators)

The Public Servers, –– the servers that the users actually have access to –– are securely–configured servers that ask for Certificates, deliver them, and so on. This is the only entry point to the CA infrastructure from the Internet.

The source code describes the local Secure RA servers as RAOperators.


The content of this section is subject to change in the future.

Get Root CA Certificate

This allows the user to import the root Certificate of the Certification Authority into the browser. This is a basic and important procedure. It takes place once in the life–time of the Certification Authority Certificate. Other documentation describes this Certificate as the Root Certificate. It is the starting point to enable the client to communicate securely with the Certification Authority.

Certificate Revocation Lists

This brings up the Certificate Revocation List page. Here the Certificate Revocation List, produced by the Certification Authority is imported into the browser or other application.

  • OpenCA's Certificate Revocation List (DER format)

    With this option, a browser–importable Certificate Revocation List is generated to be automaticaly included in the CRL list of the browser. The CRL is in the DER format.

  • OpenCA's Certificate Revocation List (PEM format)

    With this option, the Certificate Revocation List is generated into the PEM format. Similar to above.

  • OpenCA's Certificate Revocation List (TXT format)

    With this option, the Certificate Revocation List is generated into text format. The file generated by this command can be very big.

Request a Certificate

Initiate the procedure to request a certificate.

Get Requested Certificate

This allows the user to retrieve the issued certificate and subsequently import it to the application. The user has received the notification e–mail from the Registration Authority and is prompted with intructions to retrieve the Certificate. In the e–mail, there is a serial number of the Certificate that has to be presented to the RAOperator in order to retrieve the Certificate. The serial number serves as an identification as to which Certificate will be retrieved. It is not used for authentication purposes.

Issued Certificates List

This option presents a list of the issued certificates of this Certification Authority.

Status of the OpenCA Project

The OpenCA Project is evolving quickly. The current version at the time of writing (May, 2000) is 0.2.0. Latest release information can be found at the OpenCA Status page.

Future OpenCA work

This section describes the future work needed for OpenCA.