|The Open–source PKI Book: A guide to PKIs and Open–source Implementations|
|Prev||Chapter 7. Open-Source Implementations||Next|
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.
We describe the CA structure as used currently in OpenCA.
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.
Throughout the documentation we use the following terminology.
Table 7-1. OpenCA Abbreviations
|Term||OpenCA Object Name|
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.
This is the basic software used to implement OpenCA. Current (May, 2000) versions are depicted in the table following the list.
Compatible Operating system like Linux ®, available from http://www.linux.org
OpenSSL, available from http://www.openssl.org
Apache WWW Server, available from http://www.apache.org
mod–ssl Apache module, available from http://www.modssl.org
OpenLDAP, available from http://www.openldap.org
We subsequently install the OpenCA software. At the time of writing, the latest version is 0.2.0, available at http://www.openca.org/download.shtml
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.
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.
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.
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.
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.
This shows all Certificates ever issued by the Certification Authority.
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.
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.
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 the approved requests to the CAServer.
Show Certificate Signing Requests waiting for approval by the RAServer Administrator. Approval can be based to Identification Documents or other credentials.
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.
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.
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.
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.
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.
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.
Initiate the procedure to request a 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.
This option presents a list of the issued certificates of this Certification Authority.
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.
This section describes the future work needed for OpenCA.
The current layout of OpenCA (see Figure 7-1) is not yet scalable to support multiple CAServers or RAServers. Currently this is not a high–priority issue as it is more important to come up with a simple, secure, and clean implementation of a CA.
Do more work on the LDAP support.
Also, there are scalability issues with high usage of OpenCA. The current implementation uses Perl CGI scripts. These scripts invoke the openssl application. The overhead of invoking these two big executables (perl and openssl) is considerable. Depending on the hardware configuration, there is a limit where the physical memory becomes exhausted. The system starts swapping heavily and the load goes high.
Possible solutions here would be to make use of mod-perl for the Apache WWW Server. This adds a new component that needs to be included in a future security review.
Calling the OpenSSL library would be much more efficient than invoking the openssl application. Both Perl and C support library function invocation.
In the current OpenCA layout (see Figure 7-1) the CAServer is shown to not be networked. It communicates with the RAServer using removable media. There could be a solution that allows a networked configuration and maintains a high degree of security.
A test–suite is needed to test the installation for correctness and provide an estimation of thoughput capabilities. For the current implementation of OpenCA applications like cURL could be used to write a test–suite. cURL supports SSL/TLS connections. It is an open–source command–line application. It is found at cURL - Client to fetch URLs link.
OpenCA software and its components require a security review.
Smart cards could be used in The OpenCA Project. Linux® supports smart cards. Information is at MUSCLE Smartcard Home Page. MUSCLE supports PC/SC and OCF (through JNI). The PC/SC support is more complete and could provide the necessary performance needed. Also, it can be accessed through Perl and C.
OpenCA could be implemented in various other languages. The decision for this should be the weighing of the benefits and the source–code fork problem.
Internationalisation of OpenCA. This could be accomplished with the gettext support that perl has. However, this should wait until the software has been stabilised.