| The OpenCA Book: A guide to OpenCA, the Open Certification Authority | ||
|---|---|---|
| Prev | Chapter 4. The structure of OpenCA | Next |
This is the functionality of the Certification Authority Server.
While perusing the source code, you will see the CA server is described as CAServer.
The following sections and subsections are the options presented to the user, when using the WWW interface. It is recommended that she administers the CA with this interface. We shall get into each option and discuss it.
Note: The content of this section is subject to change in the future.
Generate new CA private key
This is the procedure described in the section called Generate the RSA key–pair for a user/server in Chapter 3. Generating a new secret (usually called private) key for a CA and overwriting the old one is a very important procedure since certificates already issued, will become invalid. The user is warned that the current CA private key will be overwritten.
Note: In fact, with the current version of OpenCA, the previous of the current key is overwritten, as the software saves the current key in a file with an extension of .old, overwriting possible previous backups.
If the user wishes to continue, she is prompted with a dialog box for a CA secret key. This CA secret key is in fact the pass–phrase that will be used to protect the CA private key. For example, if we use RSA as the public key algorithm, the key generation procedure will generate a set of very large numbers. A part of them constitutes the private key. It is important that this information is not 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 makes use of it.
Note: 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 keep in mind that using high–grade encryption, does not mean that the system is secure. All the components need to be secure in order to have a secure system. In the case of OpenCA, there are a lot of components.
Note: 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 to be used, the application should ask for it. This makes it more secure but requires human intervention when there is a need for the private key. For example, when we need to restart the server.
Subsequently, 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 obviously 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 a very secure choice with current (Jan2000) information about factorisation.
Note: The user should consider that while the size in bits 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 while for 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 life span. Other operations like the signing and verification of digital signatures take place more frequently and remain to be benchmarked.
Note: With Pentium® II or better computers, the size of 2048 bits is both a fast and secure choice. Once we click ok, the procedure of the key generation takes place. This may take several seconds and the user should wait for it to be completed.
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 Request
This is the procedure described in the section called Generate a Certificate Signing Request (CSR) in Chapter 3. Essentially, the Certificate Signing 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 Signing Request that was generated with the above option. A file is created in the file system that corresponds with the CSR.
Generate Self Signed CA Certificate
Unlike the title, this option uses the generated CSR to create the CA Certificate. In fact, 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.
Note: 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 removed physical 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.
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.