Redwax Server – Configuration

Configuring the Redwax Server

Configuration of a Redwax Server is identical to the configuration of any Apache HTTP Server, however the following will give you an approach to turn a generic Apache HTTP Server into a Redwax Certificate Authority.

Installing Apache HTTP Server and Redwax Server

Start with an installation of the Apache HTTP Server on your platform, then add Redwax Server.

Install Apache

Different platforms have different methods for installing the Apache HTTP Server. Instructions for common platforms can be found below:

Install Redwax

Different platforms have different methods for installing extra packages like the Redwax Server. Redwax packages from common platforms can be found below:

Install binary RPMs on Redhat / Fedora / Mageia / OpenSUSE.
On NixOS include a dependency in the apache extra modules section to any of RedWax packages (e.g. see this example this timeserver, a revocations or by via OCSP or signing certs).
On Apple MacOSX see the ports mod_ca, mod_crl, mod_ocsp, mod_csr, modPkcs12, mod_scep, mod_timestampmod_ca and so on in MacPorts.
Install from source on your chosen platform.

Configure a Virtual Host

There is no "correct" way to lay out a server. In this guide we use the following virtual host configuration from the Interop / Demo site, but others are possible, including the use of no virtual hosts at all.

SSL Virtual Host

As a baseline, ensure that you have a running Apache HTTP server able to respond to web requests. One such way is to configure a virtual server as below. In this virtual host we configure a digital certificate that matches the default name of the machine. We include additional configuration if present from the /etc/httpd/conf.d/secure/machine/ directory.

<IfModule !dir_module>
  LoadModule dir_module modules/mod_dir.so
</IfModule>

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#
<VirtualHost *:443>

    DocumentRoot /var/www/secure/machine/web-docs
    ErrorLog /var/log/httpd/secure/machine-error_log
    CustomLog /var/log/httpd/secure/machine-access_log ssl-combined

    SSLEngine on
    SSLStrictSNIVHostCheck on
    SSLCertificateFile /etc/pki/httpd/machine-hostCert.pem
    SSLCertificateKeyFile /etc/pki/httpd/machine-hostKey.pem
    SSLCertificateChainFile /etc/pki/httpd/machine-hostChain.pem
    SSLCACertificateFile /etc/pki/httpd/machine-caCert.pem

    <Directory "/var/www/secure/machine/web-docs">
      Options +Indexes +FollowSymLinks
      AllowOverride None
      Require all granted
    </Directory>

    IncludeOptional /etc/httpd/conf.d/secure/machine/*.conf

</VirtualHost>

Virtual Host

Some SCEP clients paradoxically do not support connection to a secure webserver, as the SCEP protocol has it's own built security protections. For this reason, you might want to deploy a normal virtual host, as per the following example from the Interop / Demo site. It is possible to host a certificate authority at both a secure and insecure URL at the same time, by including the same configuration in both the secure and normal virtual hosts.

<VirtualHost *:80>

    DocumentRoot /var/www/virtual/machine/web-docs
    ErrorLog /var/log/httpd/virtual/machine-error_log
    CustomLog /var/log/httpd/virtual/machine-access_log combined

    <Directory "/var/www/virtual/machine/web-docs">
      Options +Indexes +FollowSymLinks
      AllowOverride None
      Require all granted
    </Directory>

    IncludeOptional /etc/httpd/conf.d/virtual/machine/*.conf

</VirtualHost>

Configure a Redwax Backend Server

Your first choice to make is where you will receive your certificates, serial numbers and time sources.

Simple Configuration

In this example, we've decided to use the mod_ca_simple module to issue certificates signed by a CA certificate and private key stored on local disk.

We have also decided to issue serial numbers based on the local machine's random number generator, and have decided to use the system time.

We have also, if required of us, decided to generate RSA keys with a size of 4096 bits.

Any certificates we issue will be leaf certificates (basicConstraints CA:FALSE), and will contain specific keyUsage and extendedKeyUsage fields. We also include a subjectKeyIdentifier and an authorityKeyIdentifier to our certificates.

Other choices are available as documented in the list of backend modules.

<IfModule !ca_module>
  LoadModule ca_module /usr/lib64/httpd/modules/mod_ca.so
</IfModule>
<IfModule !ca_simple_module>
  LoadModule ca_simple_module /usr/lib64/httpd/modules/mod_ca_simple.so
</IfModule>

<Location /test/simple>

  CASimpleCertificate /etc/pki/interop/ca-cert.pem
  CASimpleKey /etc/pki/interop/private/ca-key.pem
  CASimpleDays 1
  CASimpleTime on
  CASimpleAlgorithm RSA rsa_keygen_bits=4096
  CASimpleSerialRandom on

  CASimpleExtension basicConstraints CA:FALSE
  CASimpleExtension keyUsage critical,nonRepudiation,digitalSignature,keyEncipherment
  CASimpleExtension extendedKeyUsage OID:1.3.6.1.5.5.7.3.2
  CASimpleExtension subjectKeyIdentifier hash
  CASimpleExtension authorityKeyIdentifier keyid,issuer

</Location>

Configure a Redwax Frontend Server

Your second choice to make is how you will respond to requests for certificates, certificate revocation lists, online certificate status protocol requests, and time stamp requests.

You may choose just one of these, or all of these, as per your requirements.

Certificate Sign Requests

In this example, we've decided to use the mod_csr module to issue certificates to anybody in response to a certificate sign request provided by a browser.