-- DavidBannon - 11 Dec 2007

The APAC-GRID Certificate Authority Complete process

This document migrated here from old APACGrid twiki, 11/12/2007

Updated Jan 2006 when implementing release 1.2 of the CPS, DRB

Intro

The CA uses OpenCA 0.9.2 for the complete certificate handling system. This guide is little more than an OpenCA howto. OpenCA? is a mass of perl, html and javascript that can be difficult to install, especially if you haven't got your head around the ideas of separate nodes, each with a combination of functions installed on it.

PKI Overview

Public Key Infrastructure, the system of using x.509 certificates for security is well described elsewhere. In brief, a user holds a private, secret key. The User's certificate includes the matching public key. The User's Certificate is publically available to the world, but the private key isn't. If that gets out, the User's certificate must be revoked. There is also a signing Certificate for the Certificate Authority. The CA's Certificate is trusted by many users and hosts. The CA's private key is used to sign certificates, which can then be trusted up to the level of security that the CA uses to verify identity.

The basic ideas behind Certificate Authorities is Authentication: if someone has a valid certificate, and can prove they have the private key (cryptographically) then you can trust that they are who the certificate says.

You can easily generate CA certificates and sign normal certificates on any computer, but those certificates couldn't be well trusted.

The way that the ARCS verifies identity gives a high level of assurance that a certificate holder is who they say they are. It is also used to guarantee the identity of hosts and other services in the grid project.

ARCS Handling overview

OpenCA has three distinct functions, and these can be installed all on one machine, all on separate machines, or grouped. Each machine that holds some part of the system is called a node, so there is usually between 1 and three tiers of nodes. The same software is installed on each machine, but configured differently according to the roles that the machine will play. Each install of OpenCA has a web interface that is the sole way of accessing the functions of that node.

The functions can be separated for security reasons by a range of security measures. Separated nodes must be configured to transfer to each other, via whichever means is desired.

The first function is the CA node.

CA Node

This is the highest and most secure level of the system, there is only one CA for each CA certificate (Although CA's can be chained into a hierarchy). This machine should be hard to access, both physically and electronically. It holds the CA private key, and uses it to sign certificates that have been approved. Only CA Operators should have access to the CA machine.

RA Node

The Registration Authority is where requests are approved by Registration Authority Operators (RAOs). RAOs have special certificates. When requests come in, users can go to an RAO, prove their identity, and the RAO will approve their request by signing it with their certificate. The request can then be transferred to the CA machine for signing. On the ARCS CA, only RAO and CAO can connect to the RA node.

There can be many Registration Authority machines for each Certificate Authority.

Public Node

The public node is a web interface for users to request certificates, collect signed certificates and keys and get other information from the certificate system, such as the CA cert.

APAC-GRID Implementation

This is the specifics of the ARCS implementation of OpenCA? and twiki.

APAC-GRID uses two machines for the PKI system.

The first is the CA machine, this is a highly secured pc. Firstly, the CA machine is physically inaccessible to everyone except CA operators, and secondly, it isn't connected to any network, so at the end of each business day, a CA Operator takes the approved requests on a storage device to the CA machine, signs them and brings them back to the RA machine.

The second machine (ca.apac.edu.au) runs the Registration Authority and the Public interface. The Public Interface has a complete menuing system, but it isn't user friendly, so most of the useful functions have been linked from this twiki menu, to make it easier. The actual public interface is at https://ca.apac.edu.au/pub

The Registration Authority side of the machine still uses the inbuilt web menuing system, because RAOs need to log on with their browser loaded certificate. RAOs can then follow the instructions on handling requests to find their way to approving certificates. The Registration Authority uses x509 authentication for login, so RAOs need to have mozilla firefox, and have the certificate loaded into the browser. The other important trick is they must have the CA certificate loaded, and Trusted to verify email users if they don't have this, they won't be able to log in. RAO (and other end users) are discouraged from using Internet Explorer.

Summary of ARCS OpenCA? install

• Two machines, one CA the other RA and Public
• Data Exchange is done by USB disk between the Pub/RA and the CA
• CA login by username/password, RA login by x509, public freely accessible
• Users should be directed to the twiki menu, not the actual OpenCA? public interface
• Some of the javascript error messages have been patched and changed
• Some of the menuing code has been changed slightly in an early attempt to improve usability
• Changes made to configuration must be done in the config repository, pushed out to the openca templates and ~/etc/configure_etc.sh run. Never make changes directly to run time config files or a large blackwinged dragon will appear behind you and devour your liver while you watch, frozen with fear.

Problems for APAC-GRID CA

• Logs difficult to handle.
• Batch processing hasn't been tested and may not work. This will start to become time consuming mainly for CA Operators if lots of users start applying for certificates.
• The version of OpenCA? used should be transportable, that is, you should be able to install a new version of OpenCA? elsewhere, backup the CA machine and restore it on the newly installed machine. This will not work, as the CA key and cert must be generated at install time, and don't go into the database, and are therefore not backed up. The only way to restore OpenCA? therefore, is to backup the complete install of OpenCA? and copy it to a new machine. (Unless you can work out how to replace a CA Cert on a CA node.)

Disaster Recovery and Security Failure

Please refer to the current CPS for details of what to do in the event of the above.

-- DamonSmith? - 04 Jan 2005 -- DavidBannon - 05 Jan 2006