As part of our goal of providing a centralized solution for client certificate authentication, we need a Certificate Authority--and since it has to be public facing, we need a Certificate Authority Server that can both sign certificates and handle revocation. This will be implemented with a modular approach, where the frontend website is not, as such, part of the server but the server does provide the backend where user's certificates are issued, managed, and revoked.
Both the OCSP responder and backend certificate manager will be independent programs. They will both use the same backend database (certificate store) but they will have the option of being operated independently should someone so desire.
This README will function also as a specification document: the needed and planned functionality will be listed here, below.
Required to properly run the application:
- Ruby >= 2.4.1 (earlier versions may, but are not guaranteed to, work)
- Rails >= 5.1.1 (same note regarding earlier versions)
- Postgresql
- Redis
There's some configuration required in order to get up and running. You'll want to create your secrets.yml with your secret_key_base; see config/secrets.yml.example for more information. You also need to define other config settings; see config/settings.yml and config/settings/#{Rails.env}.yml for instructions.
Note that you will probably want to create local (i.e. not checked in to git) config files, and these should go in config/settings as well.
This section left out until there's actually something to install.
You'll need a recent version of Ruby and Rails. This was developed on Ruby 2.4.1 and Rails 5.1.1, so any version equal to or greater than that should hopefully work.
The backend has the more complicated specification, as it does most of the work. The frontend (out of scope for this codebase) is simply an interface to the backend, which handles:
- Certificate management:
- Certificate issuance
- Certificate renewal
- Certificate revocation
- Maintenance of the CRL
- User management:
- User creation
- Validation of user email addresses
- Updating user's profile information
The backend will not have any public-facing interfaces; it will be designed to work solely with a frontend server. It will listen on either a local port or a Unix Socket for communication with the frontend and the OCSP responder. The frontend will be responsible for displaying the CRL.
Despite there being better ways of achieving inter-process communication, we will use an HTTP API for communication here. As such, it is important that the backend not be publicly exposed. A secret key will be used, however should that key be compromised somehow, an attacker would be able to manage certificates arbitrarily. This API will be properly defined an another document.
So that websites can vaildate certificates easily (as they should attempt to validate each certificate before trying to use it for authentication; indeed, a website using client certificate authentication but not our API has a duty to validate each certificate lest one be compromised), we need to provide an OCSP responder. As this is to be used for clients only, we need not implement RFC 6961, however we do need to implement RFC 2560. That RFC outlines our requirements nicely.