[rs-commit] r346 - in /rs-manual/trunk/src/site/xhtml5: architecture.xhtml5 index.xhtml5 introduction.xhtml5
rs-commit at redwax.eu
rs-commit at redwax.eu
Thu Mar 19 23:24:51 CET 2020
Author: minfrin at redwax.eu
Date: Thu Mar 19 23:24:50 2020
New Revision: 346
Log:
Add an introduction to the Redwax Server docs.
Added:
rs-manual/trunk/src/site/xhtml5/introduction.xhtml5
Modified:
rs-manual/trunk/src/site/xhtml5/architecture.xhtml5
rs-manual/trunk/src/site/xhtml5/index.xhtml5
Modified: rs-manual/trunk/src/site/xhtml5/architecture.xhtml5
==============================================================================
--- rs-manual/trunk/src/site/xhtml5/architecture.xhtml5 (original)
+++ rs-manual/trunk/src/site/xhtml5/architecture.xhtml5 Thu Mar 19 23:24:50 2020
@@ -121,6 +121,26 @@
<section>
<header>
+ <h3>Input Sanitisation</h3>
+ </header>
+ <div class="content none">
+ <p>
+ 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.
+ </p>
+ <p>
+ 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.
+ </p>
+ </div>
+ </section>
+
+ <section>
+ <header>
<h3>No Gaps</h3>
</header>
<div class="content none">
Modified: rs-manual/trunk/src/site/xhtml5/index.xhtml5
==============================================================================
--- rs-manual/trunk/src/site/xhtml5/index.xhtml5 (original)
+++ rs-manual/trunk/src/site/xhtml5/index.xhtml5 Thu Mar 19 23:24:50 2020
@@ -15,6 +15,9 @@
The Redwax Server is a modular certificate authority consisting of an
interconnecting set of modules for the <a href="https://httpd.apache.org">Apache HTTP server</a>.
</p>
+ <ul class="alt">
+ <li><a href="introduction.html">Introduction and Goals of the Redwax Server</a></li>
+ </ul>
</div>
<div class="image">
<img src="images/candles-red.jpg" alt="" />
Added: rs-manual/trunk/src/site/xhtml5/introduction.xhtml5
==============================================================================
--- rs-manual/trunk/src/site/xhtml5/introduction.xhtml5 (added)
+++ rs-manual/trunk/src/site/xhtml5/introduction.xhtml5 Thu Mar 19 23:24:50 2020
@@ -0,0 +1,170 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html>
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
+ <head>
+ <title>Introduction</title>
+ <meta name="description" content="Introduction and Goals of the Redwax Server." />
+ <link rel="canonical" href="https://redwax.eu/rs/docs/latest/introduction.html" />
+ </head>
+ <body>
+
+ <section class="spotlight style2 orient-right content-align-left image-position-left" id="introduction">
+ <div class="content null">
+ <h2>Introduction to the Redwax Server</h2>
+ <p>
+ Over time, a significant number of protocols, technologies and mechanisms have been
+ developed in the security landscape, and security has become more difficult than it
+ needs to be.
+ </p>
+ <p>
+ One common thread has emerged with many of the security technologies - they all rely to
+ some extent on the World Wide Web and HTTP protocol for their design.
+ </p>
+ <p>
+ Many of the available security products have been built to serve a very particular security
+ niche, and when the need does not quite fit the product, security can be difficult to
+ deploy.
+ Many of the available products have been built with an extensive set of features. When
+ those features are not needed, it can be very difficult and expensive to navigate around
+ unwanted features to deploy just the needs you have.
+ </p>
+ <p>
+ The Redwax Server attempts to bridge these gaps by allowing you to understand, configure and
+ deploy as much or as little of the server as you require.
+ </p>
+ </div>
+ <div class="image">
+ <img src="images/candles-cyan.jpg" alt="" />
+ </div>
+ </section>
+
+ <section class="wrapper style1 align-center inner"
+ id="modularity">
+ <header>
+ <h2>Modularity and the Apache HTTP Server</h2>
+ </header>
+ <div class="content index align-left">
+
+ <section>
+ <header>
+ <h3>Modularity</h3>
+ </header>
+ <div class="content none">
+ <p>
+ The Apache HTTP Server has very similar goals to Redwax, in the webserver space. Many
+ webserver products have been built to serve a particular niche, however Apache's
+ modular architecture allows you to just deploy the parts of the server you need,
+ while physically removing the parts that you don't.
+ </p>
+ <p>
+ As a result of these common goals, Redwax Server has been implemented as an extended
+ set of modules for the Apache HTTP Server.
+ </p>
+ </div>
+ </section>
+
+ <section>
+ <header>
+ <h3>Deploy What You Need</h3>
+ </header>
+ <div class="content none">
+ <p>
+ It is time consuming and overwhelming to be presented with features and capabilities
+ that go beyond what is needed.
+ </p>
+ <p>
+ Deploy the features you need, and ignore the features you don't. If you don't
+ load the module, the feature will not exist.
+ </p>
+ </div>
+ </section>
+
+ <section>
+ <header>
+ <h3>Hardening</h3>
+ </header>
+ <div class="content none">
+ <p>
+ You cannot hack what isn't there.
+ </p>
+ <p>
+ Through the modular architecture of both Apache HTTP Server and the Redwax Server
+ modules, you are able to deploy the modules you need, and ignore the modules you
+ don't.
+ </p>
+ </div>
+ </section>
+
+ </div>
+ </section>
+
+ <section class="wrapper style1 align-center inner"
+ id="frontback">
+ <header>
+ <h2>Where do certificates come from, and how do they get here?</h2>
+ </header>
+ <div class="content index align-left">
+
+ <section>
+ <header>
+ <h3>Backend Modules</h3>
+ </header>
+ <div class="content none">
+ <p>
+ Certificates can be generated in a host of different ways.
+ </p>
+ <p>
+ Certificates might be generated immediately, or might be generated after some time
+ has passed, including with human intervention.
+ </p>
+ <p>
+ Certificates might be <a href="mod/mod_ca_simple.html">signed by a key local to the
+ machine</a>, or might be signed by a <a href="mod/mod_ca_engine.html">hardware device
+ like a smartcard</a>.
+ </p>
+ <p>
+ Redwax Server gives you <a href="mod/mod_ca.html#backend">backend modules</a> to pick
+ and choose the behaviour you are looking for.
+ </p>
+ </div>
+ </section>
+
+ <section>
+ <header>
+ <h3>Frontend Modules</h3>
+ </header>
+ <div class="content none">
+ <p>
+ Certificates can arrive at the client in a number of different ways.
+ </p>
+ <p>
+ The client might generate a public / private key pair, and then send proof of
+ possession of the private key to the server using protocols like the
+ <a href="mod/mod_scep.html">Simple Certificate Enrollment Protocol (SCEP)</a>,
+ <a href="mod/mod_spkac.html">Signed Public Key and Challenge (SPKAC)</a>,
+ or the delivery of a <a href="mod/mod_csr.html">Certificate Sign Request</a>.
+ </p>
+ <p>
+ The client may choose alternatively to allow the server to generate the public /
+ private key pair for the client, and deliver both together in a
+ <a href="mod_mod_pkcs12.html">PKCS12 bundle</a>.
+ </p>
+ <p>
+ The client may need to take advantage of additional services, like the serving
+ of a <a href="mod/mod_csr.html">Certificate Revocation List</a>, or the
+ verification of a certificate via the <a href="mod/mod_ocsp.html">Online
+ Certificate Status Protocol</a>.
+ </p>
+ <p>
+ Redwax Server gives you <a href="mod/mod_ca.html#frontend">frontend modules</a> to pick
+ and choose the behaviour you are looking for.
+ </p>
+ </div>
+ </section>
+
+ </div>
+ </section>
+
+ </body>
+</html>
+
More information about the rs-commit
mailing list