ReleaseEngineering/PuppetAgain/Certificate Chaining: Difference between revisions

Jump to navigation Jump to search

ReleaseEngineering/PuppetAgain/Certificate Chaining (view source)

Revision as of 19:56, 26 April 2013

359 bytes added ,  26 April 2013
no edit summary
No edit summary
No edit summary
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/emailAddress=release@mozilla.com, O=Mozilla, Inc., OU=Release Engineering)
     +--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/emailAddress=release@mozilla.com, O=Mozilla, Inc., OU=Release Engineering)
     +-- 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:
         .
         .


Note Master and Agent certs are functionally identical.
Note Master and Agent certs are functionally identical.  The "OU=PuppetMasters" is important so that each puppetmaster can have a master and agent cert with the same fqdn.


= Master Initialization =
= Master Initialization =
Line 46: Line 46:
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 154:
= 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.  We accomplish this with a client_cert directory.  This directory has a subdirectory for each puppet master, and each such subdirectory has a ''revoke'' subdirectory for certificates that should be revoked.  The whole thing might look like
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:
client_certs/puppetmaster1.mozilla.com/client1.mozilla.com.crt
    agent-certs/relabs02.build.mtv1.mozilla.com/
client_certs/puppetmaster1.mozilla.com/client3.mozilla.com.crt
    agent-certs/relabs03.build.mtv1.mozilla.com/
client_certs/puppetmaster1.mozilla.com/revoke/098350a8f.0
    agent-certs/relabs03.build.mtv1.mozilla.com/agent1.build.mtv1.mozilla.com.crt
client_certs/puppetmaster2.mozilla.com/client10.mozilla.com.crt
    agent-certs/relabs03.build.mtv1.mozilla.com/agent2.build.mtv1.mozilla.com.crt
client_certs/puppetmaster2.mozilla.com/client11.mozilla.com.crt
    revocation-requests/relabs02.build.mtv1.mozilla.com/
client_certs/puppetmaster2.mozilla.com/revoke/
    revocation-requests/relabs02.build.mtv1.mozilla.com/agent8.build.mtv1.mozilla.com-for-relabs03.build.mtv1.mozilla.com.crt
where there is a pending revocation on puppetmaster1.  This client_certs directory is synchronized among all masters, and a crontask runs on each master that checks its ''revoke'' subdirectory 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.
    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 =
Djmitche
canmove, Confirmed users
1,394

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/649896"

Navigation menu