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.
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.
Start with an installation of the Apache HTTP Server on your platform, then add Redwax Server.
Different platforms have different methods for installing the Apache HTTP Server. Instructions for common platforms can be found below:
Different platforms have different methods for installing extra packages like the Redwax Server. Redwax packages from common platforms can be found below:
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.
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.
LoadModule dir_module modules/mod_dir.so
#
# 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.
#
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
Options +Indexes +FollowSymLinks
AllowOverride None
Require all granted
IncludeOptional /etc/httpd/conf.d/secure/machine/*.conf
]]>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.
DocumentRoot /var/www/virtual/machine/web-docs
ErrorLog /var/log/httpd/virtual/machine-error_log
CustomLog /var/log/httpd/virtual/machine-access_log combined
Options +Indexes +FollowSymLinks
AllowOverride None
Require all granted
IncludeOptional /etc/httpd/conf.d/virtual/machine/*.conf
]]>Your first choice to make is where you will receive your certificates, serial numbers and time sources.
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.
LoadModule ca_module /usr/lib64/httpd/modules/mod_ca.so
LoadModule ca_simple_module /usr/lib64/httpd/modules/mod_ca_simple.so
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
]]>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.
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.
Other choices are available as documented in the list of frontend modules.
LoadModule csr_module /usr/lib64/httpd/modules/mod_csr.so
Require all granted
SetHandler csr
CsrParamChallenge challenge
CsrSubjectRequest CN
CsrSubjectRequest O
CsrSubjectRequest C
CsrSubjectAltNameRequest rfc822Name
]]>In this example, we've decided to use the mod_pkcs12 module to issue a private key and a certificate signed by that key to anybody in response to a parameters submitted by a form in a browser.
When the generation of the private key is requested, the backend module in our example above will supply us with a 4096 bit RSA public / private key pair.
Other choices are available as documented in the list of frontend modules.
LoadModule pkcs12_module /usr/lib64/httpd/modules/mod_pkcs12.so
Require all granted
SetHandler pkcs12
Pkcs12SubjectRequest O
Pkcs12SubjectRequest CN
Pkcs12SubjectRequest C
Pkcs12SubjectAltNameRequest rfc822Name
]]>In this example, we've decided to use the mod_scep module to issue a certificate to anybody in response to a parameters submitted by SCEP client.
Some SCEP clients will only work over a non-SSL connection. This backend configuration, along with the frontend configuration may be repeated in a non-SSL virtual host or webserver.
Other choices are available as documented in the list of frontend modules.
LoadModule scep_module /usr/lib64/httpd/modules/mod_scep.so
Require all granted
SetHandler scep
ScepRACertificate /etc/pki/interop/scep-ra.cert
ScepRAKey /etc/pki/interop/private/scep-ra.key
ScepSubjectRequest O
ScepSubjectRequest CN
ScepSubjectRequest C
ScepSubjectAltNameRequest rfc822Name
]]>In this example, we've decided to use the mod_spkac module to issue certificates to anybody in response to an SPKAC request provided by a browser.
This may be done using the HTML5 keygen tag, or through
functionality provided by OpenSSL.
Other choices are available as documented in the list of frontend modules.
LoadModule spkac_module /usr/lib64/httpd/modules/mod_spkac.so
Require all granted
SetHandler spkac
SpkacSubjectRequest CN
SpkacSubjectRequest O
SpkacSubjectRequest C
SpkacSubjectAltNameRequest rfc822Name
]]>In this example, we've decided to use the mod_cert module to return CA certificates that are currently in use by the backend modules in response to a browser request.
Other choices are available as documented in the list of frontend modules.
LoadModule cert_module /usr/lib64/httpd/modules/mod_cert.so
Require all granted
SetHandler cert-ca
]]>In this example, we've decided to use the mod_pkcs7 module to return CA certificates that are currently in use by the backend modules as DER or PEM encoded PKCS7 responses in response to a browser request.
Other choices are available as documented in the list of frontend modules.
LoadModule pkcs7_module /usr/lib64/httpd/modules/mod_pkcs7.so
Require all granted
SetHandler pkcs7-ca
]]>With the configuration in place, it is time to test your server.
The Redwax Interop / Demo site provides a number of examples that could be used to test your server configuration.
In this example, we provide a number of ways to test a SCEP server on various SCEP clients.
In this example, we provide a number of ways to test a time stamp service using OpenSSL.
In this example, we test against an instance of a Redwax Certificate Sign Request server based on mod_csr.