blob: 9c939dcd318f2d09488c48103c0f77bb89e070a1 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
.. -*- mode: rst -*-
.. _appendix-guides-sslca_howto:
====================================
Automated Bcfg2 SSL Authentication
====================================
This how-to describes one possible scenario for automating SSL
certificate generation and distribution for bcfg2 client/server
communication using the :ref:`SSL CA feature
<server-plugins-generators-cfg-ssl-certificates>` of
:ref:`server-plugins-generators-cfg`. The process involves configuring
a certificate authority (CA), generating the CA cert and key pair,
configuring the Cfg SSL CA feature and a Bundle to use the generated
certs to authenticate the Bcfg2 client and server.
OpenSSL CA
==========
If you already have a SSL CA available you can skip this section,
otherwise you can easily build one on the server using openssl. The
paths should be adjusted to suite your preferences.
#. Prepare the directories and files::
mkdir -p /etc/pki/CA/newcerts
mkdir /etc/pki/CA/crl
echo '01' > /etc/pki/CA/serial
touch /etc/pki/CA/index.txt
touch /etc/pki/CA/crlnumber
#. Edit the ``openssl.cnf`` config file, and in the **[ CA_default ]**
section adjust the following parameters::
dir = /etc/pki # Where everything is kept
certs = /etc/pki/CA/certs # Where the issued certs are kept
database = /etc/pki/CA/index.txt # database index file.
new_certs_dir = /etc/pki/CA/newcerts # default place for new certs.
certificate = /etc/pki/CA/certs/bcfg2ca.crt # The CA certificate
serial = /etc/pki/CA/serial # The current serial number
crl_dir = /etc/pki/CA/crl # Where the issued crl are kept
crlnumber = /etc/pki/CA/crlnumber # the current crl number
crl = /etc/pki/CA/crl.pem # The current CRL
private_key = /etc/pki/CA/private/bcfg2ca.key # The private key
#. Create the CA root certificate and key pair. You'll be asked to
supply a passphrase, and some organizational info. The most
important bit is **Common Name** which you should set to be the
hostname of your bcfg2 server that your clients will see when doing
a reverse DNS query on it's ip address.::
openssl req -new -x509 -extensions v3_ca -keyout bcfg2ca.key \
-out bcfg2ca.crt -days 3650
#. Move the generated cert and key to the locations specified in
``openssl.cnf``::
mv bcfg2ca.key /etc/pki/CA/private/
mv bcfg2ca.crt /etc/pki/CA/certs/
Your self-signing CA is now ready to use.
Bcfg2
=====
SSL CA Feature
--------------
The SSL CA feature of Cfg was not designed specifically to manage
Bcfg2 client/server communication, though it is certainly able to
provide certificate generation and management services for that
purpose. You'll need to configure Cfg as described in
:ref:`server-plugins-generators-cfg-ssl-certificates`, including:
* Configuring a ``[sslca_default]`` section in ``bcfg2.conf`` that
describes the CA you created above;
* Creating ``Cfg/etc/pki/tls/certs/bcfg2client.crt/sslcert.xml`` and
``Cfg/etc/pki/tls/private/bcfg2client.key/sslkey.xml`` to describe
the key and cert you want generated.
In general, the defaults in ``sslcert.xml`` and ``sslkey.xml`` should
be fine, so those files can look like this:
``Cfg/etc/pki/tls/certs/bcfg2client.crt/sslcert.xml``:
.. code-block:: xml
<CertInfo>
<Cert key="/etc/pki/tls/private/bcfg2client.key"/>
</CertInfo>
``Cfg/etc/pki/tls/private/bcfg2client.key/sslkey.xml``:
.. code-block:: xml
<KeyInfo/>
Client Bundle
-------------
To automate the process of generating and distributing certs to the
clients we need define at least the cert and key paths created by Cfg,
as well as the CA certificate path in a Bundle. For example:
.. code-block:: xml
<Path name='/etc/pki/tls/certs/bcfg2ca.crt'/>
<Path name='/etc/pki/tls/bcfg2client.crt'/>
<Path name='/etc/pki/tls/private/bcfg2client.key'/>
Here's a more complete example bcfg2-client bundle:
.. code-block:: xml
<Bundle>
<Path name='/etc/bcfg2.conf'/>
<Path name='/etc/cron.d/bcfg2-client'/>
<Package name='bcfg2'/>
<Service name='bcfg2'/>
<Group name='rpm'>
<Path name='/etc/sysconfig/bcfg2'/>
<Path name='/etc/pki/tls/certs/bcfg2ca.crt'/>
<Path name='/etc/pki/tls/certs/bcfg2client.crt'/>
<Path name='/etc/pki/tls/private/bcfg2client.key'/>
</Group>
<Group name='deb'>
<Path name='/etc/default/bcfg2' altsrc='/etc/sysconfig/bcfg2'/>
<Path name='/etc/ssl/certs/bcfg2ca.crt' altsrc='/etc/pki/tls/certs/bcfg2ca.crt'/>
<Path name='/etc/ssl/certs/bcfg2client.crt' altsrc='/etc/pki/tls/certs/bcfg2client.crt'/>
<Path name='/etc/ssl/private/bcfg2client.key' altsrc='/etc/pki/tls/private/bcfg2client.key'/>
</Group>
</Bundle>
The ``bcfg2.conf`` client config needs at least 5 parameters set for
SSL auth.
#. ``key`` : This is the host specific key that Cfg will create.
#. ``certificate`` : This is the host specific cert that Cfg will
create.
#. ``ca`` : This is a copy of your CA certificate. Not generated by
Cfg.
#. ``password`` : Set to arbitrary string when using certificate
auth. This also *shouldn't* be required. See:
http://trac.mcs.anl.gov/projects/bcfg2/ticket/1019
Here's what a functional **[communication]** section in a
``bcfg2.conf`` genshi template for clients might look like.::
[communication]
protocol = xmlrpc/ssl
{% if metadata.uuid != None %}\
user = ${metadata.uuid}
{% end %}\
password = DUMMYPASSWORDFORCERTAUTH
{% choose %}\
{% when 'rpm' in metadata.groups %}\
certificate = /etc/pki/tls/certs/bcfg2client.crt
key = /etc/pki/tls/private/bcfg2client.key
ca = /etc/pki/tls/certs/bcfg2ca.crt
{% end %}\
{% when 'deb' in metadata.groups %}\
certificate = /etc/ssl/certs/bcfg2client.crt
key = /etc/ssl/private/bcfg2client.key
ca = /etc/ssl/certs/bcfg2ca.crt
{% end %}\
{% end %}\
As a client will not be able to authenticate with certificates it does
not yet posses we need to overcome the chicken and egg scenario the
first time we try to connect such a client to the server. We can do so
using password based auth to bootstrap the client manually specifying
all the relevant auth parameters like so::
bcfg2 -qv -S https://fqdn.of.bcfg2-server:6789 -u fqdn.of.client \
-x SUPER_SECRET_PASSWORD
If all goes well the client should recieve a freshly generated key and
cert and you should be able to run ``bcfg2`` again without specifying
the connection parameters.
If you do run into problems you may want to review
:ref:`appendix-guides-authentication`.
|
