[PATCH] removed HOWTO text for openssl

Jeffrey Blank blank at eclipse.ncsc.mil
Mon Sep 2 17:11:29 UTC 2013


This can be handled by external sources.
This will also prevent confusion by those who cannot distinguish
between compliance rules and informative prose.

Signed-off-by: Jeffrey Blank <blank at eclipse.ncsc.mil>
---
 RHEL6/input/system/network/ssl.xml |  144 +++---------------------------------
 1 files changed, 12 insertions(+), 132 deletions(-)

diff --git a/RHEL6/input/system/network/ssl.xml b/RHEL6/input/system/network/ssl.xml
index e518d24..48d9dcc 100644
--- a/RHEL6/input/system/network/ssl.xml
+++ b/RHEL6/input/system/network/ssl.xml
@@ -1,136 +1,16 @@
 <Group id="network_ssl">
-<title>Secure Sockets Layer Support</title>
+<title>Transport Layer Security Support</title>
 <description>
-The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated
-network communications, and many network services include support for it. Using
-SSL is recommended, especially to avoid any plaintext transmission of sensitive
-data, even over a local network. The SSL implementation included with the
-system is called OpenSSL. Recent implementations of SSL may also be referred to
-as Transport Layer Security (TLS).  SSL uses public key cryptography to provide
-authentication and encryption.
-<br /><br />
-Public key cryptography involves two keys, one called the public key and the
-other called the private key. These keys are mathematically related such that
-data encrypted with one key can only be decrypted by the other, and vice versa.
-As their names suggest, public keys can be distributed to anyone while a
-private key must remain known only to its owner.  SSL uses certificates, which
-are files that hold cryptographic data: a public key, and a signature of that
-public key. In SSL authentication, a server presents a client with its
-certificate as a means of demonstrating that it is who it claims it is.
-
-<br /><br />
-If everything goes correctly, the client can verify the server's certificate by
-determining that the signature inside the certificate could only have been
-generated by a third party whom the client trusts.  This third party is called
-a Certificate Authority (CA). Each client system should also have certificates
-from trusted CAs, and the client uses these CA certificates to verify the
-authenticity of the server's certificate. After authenticating a server using
-its certificate and a CA certificate, SSL provides encryption by using the
-server certificate to securely negotiate a shared secret key.
-
-<br /><br />
-If your server must communicate using SSL with systems that might not be able
-to securely accept a new CA certificate prior to any SSL communication, then
-paying an established CA (whose certificates your clients already have) to sign
-your server certificates is recommended. The steps for doing this vary by
-vendor. Once the signed certificates have been obtained, configuration of the
-services is the same whether they were purchased from a vendor or signed by
-your own CA.
-
-<br /><br />
-For setting up an internal network and encrypting local traffic, creating your
-own CA to sign SSL certificates can be appropriate. The major steps in this
-process are:
-
-<ol>
-<li>Create a CA to sign certificates</li>
-<li>Create SSL certificates for servers using that CA</li>
-<li>Enable client support by distributing the CA's certificate</li>
-</ol>
+Support for Transport Layer Security (TLS), and its predecessor, the Secure
+Sockets Layer (SSL), is included in RHEL in the OpenSSL software (RPM package
+<tt>openssl</tt>).  TLS provides encrypted and authenticated network
+communications, and many network services include support for it.  TLS or SSL
+can be leveraged to avoid any plaintext transmission of sensitive data.
+<br/>
+For information on how to use OpenSSL, see
+<b>http://www.openssl.org/docs/HOWTO/</b>.  Information on FIPS validation
+of OpenSSL is available at <b>http://www.openssl.org/docs/fips/fipsvalidation.html</b>
+and <b>http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm</b>.
+<!-- Does Red Hat offer any documentation on using OpenSSL? -->
 </description>
-
-<Group id="network_ssl_create_ca">
-<title>Create a CA to Sign Certificates</title>
-<description>The following instructions apply to OpenSSL since it is included
-with the system, but creating a CA is possible with any standards-compliant SSL
-toolkit. The security of certificates depends on the security of the CA that
-signed them, so performing these steps on a secure machine is critical. The
-system used as a CA should be physically secure and not connected to any
-network. It should receive any certificate signing requests (CSRs) via
-removable media and output certificates onto removable media.
-<br /><br />
-The script <tt>/etc/pki/tls/misc/CA</tt> is included to assist in the process
-of setting up a CA. This script uses many settings in
-<tt>/etc/pki/tls/openssl.cnf</tt>. The settings in this file can be changed to
-suit your needs and allow easier selection of default settings, particularly in
-the <tt>[req distinguished name]</tt> section.
-<br /><br />
-To create the CA:
-<pre># cd /etc/pki/tls/misc
-# ./CA -newca</pre>
-When prompted, press enter to create a new CA key with the default name <tt>cakey.pem</tt>.
-When prompted, enter a password that will protect the private key, then enter the same password
-again to verify it.
-<br /><br />
-At the prompts, fill out as much of the CA information as is relevant for your site. You must specify
-a common name, or generation of the CA certificate will fail.
-<br /><br />
-Next, you will be prompted for the password, so that the script can re-open the private key in order
-to write the certificate.
-<br /><br />
-This step performs the following actions:
-<ul>
-<li>creates the directory <tt>/etc/pki/CA</tt> (by default), which contains files necessary for the operation of a
-certificate authority. These are:
-<ul>
-<li><tt>serial</tt>, which contains the current serial number for certificates signed by the CA</li>
-<li><tt>index.txt</tt>, which is a text database file that contains information about certificates signed</li>
-<li><tt>crl</tt>, which is a directory for holding revoked certificates</li>
-<li><tt>private</tt>, a directory which stores the CA's private key</li>
-</ul></li>
-<li>creates a public-private key pair for the CA in the file <tt>/etc/pki/CA/private/cakey.pem</tt>. The private key
-must be kept private in order to ensure the security of the certificates the CA will later sign.</li>
-<li>signs the public key (using the corresponding private key, in a process called self-signing) to create the CA
-certificate, which is then stored in <tt>/etc/pki/CA/cacert.pem</tt>.</li>
-</ul>
-When the CA later signs a server certificate using its private key, it means that it is vouching for the authenticity
-of that server. A client can then use the CA's certificate (which contains its public key) to verify the authenticity
-of the server certificate.
-</description>
-</Group>
-
-<Group id="network_ssl_create_ssl_certs">
-<title>Create SSL Certificates for Servers</title>
-<description>Creating an SSL certificate for a server involves the following steps:
-<ol>
-<li>A public-private key pair for the server must be generated.</li>
-<li>A certificate signing request (CSR) must be created from the key pair.</li>
-<li>The CSR must be signed by a certificate authority (CA) to create the server certificate. If a CA has been
-set up as described earlier, it can sign the CSR.</li>
-<li>The server certificate and keys must be installed on the server.</li>
-</ol>
-Instructions on how to generate and sign SSL certificates are provided for the
-following common services can be found in the applicable sections of this
-guide:
-<ul>
-<li><a href="#item-postfix_configure_ssl_certs">Postfix</a></li>
-<li>Dovecot</li>
-<li>Apache</li>
-</ul>
-</description>
-</Group>
-
-
-<Group id="network_ssl_remove_certs">
-<title>Remove Certificate Authorities, if Appropriate</title>
-<description>Survey the certificate authorities trusted by Firefox,
-Thunderbird, Evolution, or other network clients. The list of certificate
-authorities for each program can be found via GUI, as described in the previous
-sections.  Remove the certificate authorities which are not appropriate for
-your network connectivity needs.  This may only make sense for some
-environments, and may create operational problems for a general purpose
-Internet-connected system.
-</description>
-</Group>
-
 </Group>
-- 
1.7.1



More information about the scap-security-guide mailing list