canmove, Confirmed users
1,394
edits
ReleaseEngineering/PuppetAgain/Certificate Chaining: Difference between revisions
ReleaseEngineering/PuppetAgain/Certificate Chaining (view source)
Revision as of 12:59, 13 May 2013
, 13 May 2013→Certificate Hierarchy
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 16: | Line 16: | ||
Root CA cert (Subject: CN=PuppetAgain Base CA/emailAddress=release@mozilla.com, OU=Release Engineering, O=Mozilla, Inc.) | Root CA cert (Subject: CN=PuppetAgain Base CA/emailAddress=release@mozilla.com, OU=Release Engineering, O=Mozilla, Inc.) | ||
| | | | ||
+--Master CA cert (Subject: CN=CA on $fqdn | +--Master CA cert (Subject: CN=CA on $fqdn) | ||
| | | | | | ||
| +--Master cert (Subject: CN=$fqdn) | | +--Master cert (Subject: CN=$fqdn, OU=PuppetMasters) | ||
| | | | | | ||
| +--Agent cert (Subject: CN=$fqdn) | | +--Agent cert (Subject: CN=$fqdn) | ||
| Line 26: | Line 26: | ||
| . | | . | ||
| | | | ||
+-- Master CA cert (Subject: CN=CA on $fqdn | +-- Master CA cert (Subject: CN=CA on $fqdn) | ||
: | | : | | ||
. +--Master cert (Subject: CN=$fqdn) | . +--Master cert (Subject: CN=$fqdn, OU=PuppetMasters) | ||
| | | | ||
+--Agent cert (Subject: CN=$fqdn) | +--Agent cert (Subject: CN=$fqdn) | ||
| Line 36: | Line 36: | ||
. | . | ||
Notes: | |||
* Here and throughout these docs, the terms "root" and "base" CA are used interchangeably. "Root" is preferred. | |||
* Master and Agent certs are nearly identical, except that one has an EKU allowing use as SSL clients, and the other only allows SSL server. The "OU=PuppetMasters" is important so that each puppetmaster can have a master and agent cert with the same fqdn, but the certificate subjects are different. | |||
= Master Initialization = | = Master Initialization = | ||
| Line 46: | Line 48: | ||
When a client is issued a new certificate, after the requisite authentication has been performed (see [[ReleaseEngineering/PuppetAgain/Puppetization Process|Puppetization Process]]), a new certificate and key are generated and signed by the CA on the puppetmaster doing the issuing. Any puppetmaster can issue a certificate. This certificate and key, along with the root CA certificate, are returned to the client. | When a client is issued a new certificate, after the requisite authentication has been performed (see [[ReleaseEngineering/PuppetAgain/Puppetization Process|Puppetization Process]]), a new certificate and key are generated and signed by the CA on the puppetmaster doing the issuing. Any puppetmaster can issue a certificate. This certificate and key, along with the root CA certificate, are returned to the client. | ||
The process looks something like this: | The process looks something like this: (although see the puppet manifests themselves to see how this works for real) | ||
# make a key | # make a key | ||
| Line 154: | Line 156: | ||
= Revocation = | = Revocation = | ||
When it comes time to revoke a certificate, things can be a bit complicated. Revocation of a compromised cert requires access to the CA certificate and key, but that key only exists on the master that created the compromised cert it. So a method is required to indicate that a particular certificate should be revoked. | When it comes time to revoke a certificate, things can be a bit complicated. Revocation of a compromised cert requires access to the CA certificate and key, but that key only exists on the master that created the compromised cert it. So a method is required to indicate that a particular certificate should be revoked. This is accomplished with a number of directories in the git repository shared between the masters. The relevant pieces look like this: | ||
agent-certs/relabs02.build.mtv1.mozilla.com/ | |||
agent-certs/relabs03.build.mtv1.mozilla.com/ | |||
agent-certs/relabs03.build.mtv1.mozilla.com/agent1.build.mtv1.mozilla.com.crt | |||
agent-certs/relabs03.build.mtv1.mozilla.com/agent2.build.mtv1.mozilla.com.crt | |||
revocation-requests/relabs02.build.mtv1.mozilla.com/ | |||
revocation-requests/relabs02.build.mtv1.mozilla.com/agent8.build.mtv1.mozilla.com-for-relabs03.build.mtv1.mozilla.com.crt | |||
revocation-requests/relabs03.build.mtv1.mozilla.com/ | |||
Active agent certs are kept in ''agent-certs'', under a directory named for the master that issued the cert. When any master wants to revoke a certificate, it moves it ('git mv') to a subdirectory of ''revocation-requests'' again named after the issuing master. The filename is set up to be unique even if two masters request a revocation of the same certificate. | |||
A crontask runs on each master that checks its revocation requests for any pending revocations, and carries them out. After each such revocation, a new CRL is generated and placed in the ''certdir'', where it is soon distributed again to all masters. | |||
= Puppet Configuration = | = Puppet Configuration = | ||
| Line 175: | Line 181: | ||
NOTE: be careful to distinguish the puppetmaster's CA certificate from its leaf certificate, particularly in the Apache configurations. | NOTE: be careful to distinguish the puppetmaster's CA certificate from its leaf certificate, particularly in the Apache configurations. | ||
== | == Root CA == | ||
The | The root CA has a simple self-signed certificate. This is the keys to the kingdom, so be careful with it. Put it on a well-protected system, isolated from your puppet environment, and protect the passphrase carefully. | ||
You should also understand the difference between a certificate, a key, and a CRL. There are plenty of good summaries out there on the 'net. | |||
Put the following in ''openssl.conf'': | |||
<pre> | <pre> | ||
[ca] | [ca] | ||
| Line 206: | Line 216: | ||
keyUsage = keyCertSign, cRLSign | keyUsage = keyCertSign, cRLSign | ||
</pre> | </pre> | ||
then touch inventory.txt and echo 0001 > serial. | |||
Set up a new self-signed CA cert with: | |||
openssl req -new -newkey rsa -days 3650 -x509 -subj "/CN=PuppetAgain Base CA, OU=Release Engineering, O=Mozilla, Inc." -keyout puppetagain-base-ca.key -out puppetagain-base-ca.crt | |||
adjusting the subject appropriately for your environment. The subject doesn't particularly matter, but using the above will risk it being confused with moco's certificate. | |||
Generate a CRL with | |||
openssl ca -config openssl.conf -gencrl -out puppetagain-base-ca.crl | |||
You now have a *.key (private key - keep this secret!), *.crt (certificate), and *.crl (CRL) file for your root CA. | |||
Note that the file contents are short blobs encoded in a text format. You can easily copy-and-paste them, if -- as is wise -- your CA host is strictly isolated from your production systems. | |||
== Making a New Puppetmaster CA Certificate == | == Making a New Puppetmaster CA Certificate == | ||
You should already know what a key, certificate, CRL, and CSR are. | |||
The idea here is to make a CA certificate (one that can sign other certificates) that is signed by the root CA. | |||
The following commands will make a new key (master.key) and a corresponding CSR. Note that the instructions you get from puppet when you're setting this up will contain explicit paths, so it will be easier to copy/paste there. | |||
openssl genrsa -out ${master_ca_key} 2048 | |||
openssl req -new -subj "/CN=CA on ${fqdn}" -key ${master_ca_key} -out master-ca.csr | |||
openssl req -text -in master-ca.csr | |||
Check that the CSR has the expected fields (check the dates, etc.), then copy/paste it into a temporary file (say, master.csr) on the host where your root CA is set up. There, run | |||
openssl ca -config openssl.conf -in master.csr | |||
This is using the root CA to sign the master CA's certificate. Check that the CSR values match what you specified above, and answer the prompts. You'll end up with a new certificate, which you can copy and paste back onto the puppetmaster (the puppet message will tell you where to put it). | |||
=== Puppetmaster CA Setup === | |||
You don't need to know this if you're using PuppetAgain, because the setup scripts do it for you (and slightly differently), but for those wondering how Certificate Chaining works in general: | |||
<pre> | <pre> | ||
$ openssl genrsa -des3 -out ${fqdn}-ca.key -passout file:${fqdn}-ca.password 2048 | $ openssl genrsa -des3 -out ${fqdn}-ca.key -passout file:${fqdn}-ca.password 2048 | ||