The Redwax Server must allow someone to build a certificate authority without requiring anyone to roll their own crypto.

While some modules may offer more power and flexibility than other modules, the most straightforward certificate deployment cases need to be covered with simple code that is difficult to misconfigure.

It must be possible for an administrator to build their certificate authority in a reasonable amount of time, and without the need to read an encyclopaedia or understand every nuance of certificate deployment.

The Redwax Server is based on a set of modules for the Apache HTTP server, which is itself widely deployed, widely understood and well documented.

The bones that make up Redwax Server need to be battle tested and proven.

Redwax Server consists of a series of modules for Apache HTTP server, which at the time of writing is over 20 years old. In this time the code has been tested, verified and battle hardened.

A certificate authority must expose only the code needed to make the certificate authority work, and no more.

Both Apache HTTP server and Redwax Server consists of a series of modules that provide required functionality, and functionality that is not required can be physically removed from a running server.

Redwax Server offers alternative implementations at different levels of security, such as the mod_ca_simple module offering a straightforward level of functionality, or the mod_ca_engine module offering an elevated hardware based level of security. It must be possible to ensure that non desired functionality be removable so that it cannot be enabled by accident.

Redwax Server is written in C only. While hook implementations might choose to call out to scripts or other languages, this is not required to implement a complete certificate authority.

While the World Wide Web gives significant flexibility over the technologies and deployments used, from the original CGI protocol to the application servers of today, this flexibility comes at a cost. Many systems need application firewalls and the sanitisation of inputs, and significant auditing of deployments.

The modules that make up the Redwax Server are designed to handle input sanitisation in their default configurations, handing over complete security structures such as certificates and certificate sign requests, with all inputs safely escaped by default.

The code implementing a certificate authority needs to have no gaps in functionality.

Many languages or bindings are general in nature, and leave gaps open in funcionality. SQL allows for SQL injection attacks. Scripting allows for misquoting, unescaped parameters and significant whitespace. The people implementing a certificate authority using Redwax Server must be able to take for granted that these gaps are closed.

The Apache HTTP server hook mechanism offers a well defined low level interface between modules in the system. Modules share well defined data structures between them such as DER encoded ASN.1, and all data is properly wrapped and escaped before transfer between modules. All user provided data is sanitised and properly escaped by the protocol modules before passing the data through the Redwax Server.

The code implementing a certificate authority needs to have no side effects.

Many crypto implementations have default or fallback behaviour when a particular functionality is not available or fails. In the case of Redwax Server, each hook implementation must provide a single well defined behaviour that either performs a discrete action, or fails that action. For example a hook implementation that returns the time via a hardware clock must by default fail if the hardware clock is unavailable.

Should failover behaviour be present, this should be there because the behaviour has been explicitly chosen by the certificate authority, and not through implicit behaviour of the code.

It must be possible for the crypto engine implementing a certificate to be realistically swapped out for another one.

While the current implementation of Redwax Server depends on OpenSSL, none of the hook interfaces published by mod_ca may contain any crypto library specific data structures, but instead rely on open formats such as DER encoded ASN.1. mod_ca itself must not be linked to any crypto library.

This ensures that it is possible in future to swap out a crypto library with another library, or run multiple libraries concurrently.

All error paths must be handled, every error response must be unique, and the errors themselves must be sensible.

Redwax Server returns most errors in the response to the caller, as well as logging the errors with additional private information for the administrator. This makes Redwax Server significantly easier to troubleshoot without the need for administrator access to the underlying server.

All errors are unique, such that there is always an unambiguous record of how a particular module responded to a request.

Modules in Redwax Server are divided into two types.

Frontend modules are implemented as Apache HTTP server handlers, and each implements a specific cryptographic protocol like SCEP or OCSP. Each handler receives an HTTP request and generates an HTTP response in return.

At key points during the protocol handling, the frontend modules call out to hooks that are expected to perform discrete tasks, such as signing a certificate sign request, or verifying whether a certificate has been revoked.

Backend modules contain hook implementations that are chosen by the administrator to build the certificate authority that is required. These backend modules hook into the frontend modules to fulfill the requested task. Some hook implementations call other hooks, for example the simple certificate signing hook implementation calls further hooks to provide the time of signing and the serial number of the resulting certificate.

While a particular hook implementation might choose to call another hook that does not mean all hook implementations of the same type have to call the same hooks. A hook implementation that saves a certificate sign request to disk may choose not to call the get time hook, or the make serial hook, where it makes no sense for the application.