Generate HTTPS certificates with ssl_setup.

Extracts common OpenSSL functionality from pki_setup and adds a new cli
command ssl_setup which re-uses this base to generate SSL certificates
for https.

Change-Id: Ia34827583bcdfbd871133250681010e642271f07
Fixes: bug 1155361

2 files changed, 38 insertions, 11 deletions

diff --git a/doc/source/configuration.rst b/doc/source/configuration.rst
index c390a7fb..4b09f2c4 100644
--- a/doc/source/configuration.rst
+++ b/doc/source/configuration.rst
@@ -161,6 +161,7 @@ The values that specify where to read the certificates are under the
 * ``certfile`` - Location of certificate used to verify tokens.  Default is ``/etc/keystone/ssl/certs/signing_cert.pem``
 * ``keyfile`` - Location of private key used to sign tokens.  Default is ``/etc/keystone/ssl/private/signing_key.pem``
 * ``ca_certs`` - Location of certificate for the authority that issued the above certificate. Default is ``/etc/keystone/ssl/certs/ca.pem``
+* ``ca_key`` - Default is ``/etc/keystone/ssl/certs/cakey.pem``
 * ``key_size`` - Default is ``1024``
 * ``valid_days`` - Default is ``3650``
 * ``ca_password``  - Password required to read the ca_file. Default is None
@@ -176,8 +177,8 @@ the following conditions:
 * private key files must not be protected by a password
 
 When using signing certificate issued by an external CA, you do not need to
-specify ``key_size``, ``valid_days``, and ``ca_password`` as they will be
-ignored.
+specify ``key_size``, ``valid_days``, ``ca_key`` and ``ca_password`` as they
+will be ignored.
 
 The basic workflow for using a signing certificate issed by an external CA involves:
 
@@ -359,10 +360,10 @@ Reset collected data using::
 SSL
 ---
 
-Keystone may be configured to support 2-way SSL out-of-the-box.  The x509
-certificates used by Keystone must be obtained externally and configured for use
-with Keystone as described in this section.  However, a set of sample certficates
-is provided in the examples/pki/certs and examples/pki/private directories with the Keystone distribution for testing.
+Keystone may be configured to support SSL and 2-way SSL out-of-the-box.
+The X509 certificates used by keystone can be generated by keystone-manage or
+obtained externally and configured for use with Keystone as described in this
+section.
 Here is the description of each of them and their purpose:
 
 Types of certificates
@@ -390,7 +391,7 @@ provided as an example.
 Configuration
 ^^^^^^^^^^^^^
 
-To enable SSL with client authentication, modify the etc/keystone.conf file accordingly
+To enable SSL modify the etc/keystone.conf file accordingly
 under the [ssl] section.  SSL configuration example using the included sample
 certificates::
 
@@ -399,7 +400,8 @@ certificates::
     certfile = <path to keystone.pem>
     keyfile = <path to keystonekey.pem>
     ca_certs = <path to ca.pem>
-    cert_required = True
+    ca_key = <path to cakey.pem>
+    cert_required = False
 
 * ``enable``:  True enables SSL.  Defaults to False.
 * ``certfile``:  Path to Keystone public certificate file.
@@ -407,6 +409,29 @@ certificates::
 * ``ca_certs``:  Path to CA trust chain.
 * ``cert_required``:  Requires client certificate.  Defaults to False.
 
+When generating SSL certificates the following values are read
+
+* ``key_size``: Key size to create. Defaults to 1024.
+* ``valid_days``: How long the certificate is valid for. Defaults to 3650 (10 years).
+* ``ca_key``: The private key for the CA. Defaults to ``/etc/keystone/ssl/certs/cakey.pem``.
+* ``ca_password``: The password for the CA private key. Defaults to None.
+* ``cert_subject``: The subject to set in the certificate. Defaults to /C=US/ST=Unset/L=Unset/O=Unset/CN=localhost. When setting the subject it is important to set CN to be the address of the server so client validation will succeed. This generally means having the subject be at least /CN=<keystone ip>
+
+Generating SSL certificates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Certificates for secure HTTP communication can be generated by::
+
+    $ keystone-manage ssl_setup
+
+This will create a private key, a public key and a certificate that will be
+used to encrypt communications with keystone. In the event that a Certificate
+Authority is not given a testing one will be created.
+
+It is likely in a production environment that these certificates will be
+created and provided externally.
+
+
 User CRUD
 ---------
 
@@ -620,6 +645,7 @@ through the normal REST API. At the moment, the following calls are supported:
 * ``export_legacy_catalog``: Export service catalog from a legacy (pre-Essex) database.
 * ``import_nova_auth``: Load auth data from a dump created with ``nova-manage``.
 * ``pki_setup``: Initialize the certificates for PKI based tokens.
+* ``ssl_setup``: Generate certificates for HTTPS.
 
 Invoking ``keystone-manage`` by itself will give you additional usage
 information.
@@ -1031,7 +1057,7 @@ is::
 There are some configuration options for filtering users, tenants and roles,
 if the backend is providing too much output, in such case the configuration
 will look like::
-  
+
   [ldap]
   user_filter = (memberof=CN=openstack-users,OU=workgroups,DC=openstack,DC=com)
   tenant_filter =
@@ -1054,7 +1080,7 @@ the mask then the account is disabled.
 
 It also saves the value without mask to the user identity in the attribute
 *enabled_nomask*. This is needed in order to set it back in case that we need to
-change it to enable/disable a user because it contains more information than the 
+change it to enable/disable a user because it contains more information than the
 status like password expiration. Last setting *user_enabled_mask* is needed in order
 to create a default value on the integer attribute (512 = NORMAL ACCOUNT on AD)
 
@@ -1103,4 +1129,4 @@ A few points worth mentioning regarding the above options.  If both
 tls_cacertfile and tls_cacertdir are set then tls_cacertfile will be
 used and tls_cacertdir is ignored.  Furthermore, valid options for
 tls_req_cert are demand, never, and allow.  These correspond to the
-standard options permitted by the TLS_REQCERT TLS option.
\ No newline at end of file
+standard options permitted by the TLS_REQCERT TLS option.
diff --git a/doc/source/man/keystone-manage.rst b/doc/source/man/keystone-manage.rst
index af5ad409..b7c2131c 100644
--- a/doc/source/man/keystone-manage.rst
+++ b/doc/source/man/keystone-manage.rst
@@ -48,6 +48,7 @@ Available commands:
 * ``import_legacy``: Import a legacy database.
 * ``import_nova_auth``: Import a dump of nova auth data into keystone.
 * ``pki_setup``: Initialize the certificates used to sign tokens.
+* ``ssl_setup``: Generate certificates for SSL.
 
 
 OPTIONS