Originally taken from The GILDA AfricaGrid CA guide
The Africa Grid Certification Authority Template allows one to configure and operate a fully-operating Certificate Authority (based on OpenSSL), capable of signing X509 certificates valid for one year, for hosts, users and robots The template also provides a basic configuration of the tools needed to operate the CA, such as
The CA is managed via a script
runCA which has a graphical frontend (zenity); an ncurses version is also under development.
The installation assumes a LAMP setup :
Ansible is used to execute the configuration
the AfricaGrid CA Template is available in this repository. You can install the CA with the provided Ansible playbooks. Previous versions of software are distributed via rpm.
If you have already installed an older version of the CA Template (<1.14), and you want to preserve the existing configuration, issued certificates, etc use the update script in the top-level directory. This will update the internal database to allow for the creation of RA's, which can bed done at this point.
An Ansible playbook is provided to make basic configuration changes:
Once you've run the Ansible pre-config, the first-time configuration of the CA is done. This is currently done with runCA, but could be done with Ansible as well. There are a few important variables which need to be set in order to complete first-time configuration:
Insertion of email will trigger the creation of the CA root certificate and configures the website and webserver. Once the CA has passed initial configuration, you will be presented with an RA code. The RA code shown at this stage is associated to the email of the CA manager inserted above, which is also the first certificate created, immediately after the CA configuration. Save this code and use it to apply for the first certificate using the email previously inserted.
You should be able to see the newly configured CA running at http:///CA
In order to trust the certificates issued by your CA, you need the clients to have access to the public key; if included in the IGTF roll, the CA cert will also need to be distributed in RPM format. The
runCA script creates this RPM and pushes the public keys, CRL and signing policy to
/var/www/CA, which makes them available via the webserver as well. The RPM created takes the form:
ca_<OU Name>-<version number>.noarch.rpm The RPM is noarch because it only contains the following files:
.0is the CA public key.
.crl_urlit is needed by the sites accepting the CA in order to get the CRL updates
.r0is the Certificate Revocation List file. This file is updated automatically by scripts that, reading periodically the CRL URL, and downloading the latest CRL version issued by the CA.
.signing_policycontains some general info about the CA, like subject prefix, conditional subjects.
The Certificate Revocation List (CRL) is a file that lists all the certificates revoked by the CA. The CRL is authenticated by the CA public key signature. It has to be publicly available, so the CRL file is created under
/var/www/CA/crl, which corresponds to the URL
http://IP address/CA/crl/crl.crl This file is updated every time a certificate is revoked.
A very basic template of a website is provided for you to get started, based on PHP. This consists of a front page and a side menu which helps the user or RA to use the CA. The sections should be self-explanatory, but we provide a brief outline below.
Go to the home page, where general CA information is shown.
This allows the user to download the CA public key and/or import in the browser. Before requesting a Personal or a Robot certificate, users have to import the CA certificate, so that the request can be properly generated. *** Note that this may not work automatically on Chrome/Chromium browsers - in this case, download and import the file manually (in PEM format).
This section contains user information and instructions for requesting user, robot and host certificates.
This section allows for the generation of a request for a personal certificate. In order to successfully submit this form, requestor must have been identified by a Registration Authority, who will generate the code to be inserted in the
RA code field. The code created by the RA is sent via email by the CA itself to the requestor. Users are also required to insert the following information:
In order to successfully submit this form, the requestor must have been identified by a Registration Authority, who will generate the necessary RA code The code created by the RA via the form is again sent via email to the requestor. Users are requested to insert
Certificates issued are valid for one year. When a personal or a robot certificate is close to expiration, the certificate owner receives an email reminding them of this deadline. While the certificate remains valid and loaded in the owner's web browser, they can use the
Renew Personal or Robot certificate section for the certificate renewal.
Host certificate renewal reminders are generated in the same way, via an email to the owner, however the renewal should be requested with a signed email to the RA, containing the certificate renewal request in
Registration Authorities (RA's) are individuals which hold delegated authority with the CA to identify individuals. This identification should take place face-to-face with the user. The user should produce national ID or passport in order to prove their identity, a copy of which should be stored by the RA safely. Once this identification has taken place, the RA fills out a form - only available to RA's, identified by their personal certificates - in this section of the website, in order to generate the RA code for the user. The RA code is automatically generated and sent to the user independently of the RA via email.
The CA should provide public access to the list of issued certificates. In this section of the web site, visitors can check if certificates have been issued for a given Common Name and email. Both arguments have to be specified. This search function does not require a certificate loaded on the web browser.
Operation of the CA essentially consists of executing a few tasks, via the runCA script. These are described below.
This is the most common task done by the CA. Upong selecting this option, you are presented with a choice to sign user or server certificates. This brings up a dialog to the file manager, showing the related pending requests. Note that only User/Robot certificate requests are automatically included in the directory, since host certificates have to be sent by email and are not possible via the website.
/etc/pki/CA/htdocs/CAtmp/servers/<hostname req>.pemand the request will appear in the Server directory when launching runCA.
In the future, this will be done with an Ansible playbook.
When a request is signed, the submitter is informed via mail that the certificate requested is ready. The same email contains also a link for the certificate download, and related instructions.
In order to revoke a certificate, choose Revoke a Certificate. This will take a certificate serial number and remove it from the roll; the serial numbers can easily be checked via the Certificate Repository section of the website (** note that you have to remove the
0x prefix, shown on the web page*). If the serial number inserted is valid, complete the certificate revocation by inserting the CA private key password. A cron job, running every hour, updates the CRL file.
This is self-explanatory: a new CRL is generated and published to the website.
This option manages the Registration Authority identities. Users are of course identified by their personal certificates, so an RA candidate must already have a certificate issued. The email address of the user in question is required to match the serial number in the database, after which this is added to the db as an accredited RA.
Conversely, if an RA is to be deleted, insert the email address and the certificate serial number will be removed from the database.
Clearly, you do not want to touch this unless WWIII has broken out.