Ask Your Question

Revision history [back]

These are not supported configurations. I have used them in the past and they have serious issues. Why is rather complex.

In short, to have a distributed SSL Certificate Authority (CA), where multiple servers sign and revoke certificates for a single CA, all signing systems need to coordinate with each other. Almost any CA commercial system worth purchasing has either built-in support for this or some outside mechanism to handle the coordination. Puppet, and Puppet Enterprise, does not.

A Certificate Authority is just an X.509 document, private-key/public-key pair and a Certificate Revocation List(CRL). The private key is used to sign other X.509 documents. The private key also signs the CRL document.

Puppet agents authenticate to a master using a signed client SSL certificate. This is an X.509 document containing something that identifies the client but was signed with the private-key from the CA. That certificate has a serial number generated by the signing process.

SSL serial numbers are not Globally Unique Identifiers but simple ordered integers. Two different servers signing for the same CAs are guaranteed to have large numbers of conflicting serial numbers. A single CA will duplicate serial numbers if the CRL or existing lists of certificates is missing.

These serial numbers have to remain unique for the private key and SSL certificate from the CA used to generate the signature. This is because of the Certificate Revocation List (CRL). The CRL is just a list of serial numbers revoked by the CA. The CA signed the list so the clients and servers trusting the CA know list list is valid.

If you have two different client certificates with the same serial number signed by the same CA then a valid Certificate Revocation List (CRL) cannot be created for that CA. Furthermore any collection of certificates that contain the duplicate certificates cannot uniquely identify the certificate anymore.

This latter duplicate is a serious problem with Puppet Enterprise when Puppet Masters are reinstalled or replaced. Clients like web browsers see a certificate for puppet.example.com with a different signature or a duplicate serial number and generate errors instead of connecting the the server.

To have multiple signing servers you will need to coordinate the signing and revoking of certificates between servers. This can be done by locking systems to prevent concurrent update. It can also be done by some transaction system with the next valid serial number and CRLs exchanged between all signing systems.

Today puppet cert lacks any of this logic. The CRL is shuttled around by the Puppet Agents on the Puppet Masters during their runs causing service downtime. At best you can backup the CRL, keys and CA to another mater but you have to stick to signing consistently on just one master.

These are not supported configurations. I have used them in the past and they have serious issues. Why is rather complex.

In short, to have a distributed SSL Certificate Authority (CA), where multiple servers sign and revoke certificates for a single CA, all signing systems need to coordinate with each other. Almost any CA commercial system worth purchasing has either built-in support for this or some outside mechanism to handle the coordination. Puppet, and Puppet Enterprise, does not.

A Certificate Authority is just an X.509 document, private-key/public-key pair and a Certificate Revocation List(CRL). The private key is used to sign other X.509 documents. The private key also signs the CRL document.

Puppet agents authenticate to a master using a signed client SSL certificate. This is an X.509 document containing something that identifies the client but was signed with the private-key from the CA. That certificate has a serial number generated by the signing process.

SSL serial numbers are not Globally Unique Identifiers but simple ordered integers. Two different servers signing for the same CAs are guaranteed to have large numbers of conflicting serial numbers. A single CA will duplicate serial numbers if the CRL or existing lists of certificates is missing.

These serial numbers have to remain unique for the private key and SSL certificate from the CA used to generate the signature. This is because of the Certificate Revocation List (CRL). The CRL is just a list of serial numbers revoked by the CA. The CA signed the list so the clients and servers trusting the CA know list list is valid.

If you have two different client certificates with the same serial number signed by the same CA then a valid Certificate Revocation List (CRL) cannot be created for that CA. Furthermore any collection of certificates that contain the duplicate certificates cannot uniquely identify the certificate anymore.

This latter duplicate is a serious problem with Puppet Enterprise when Puppet Masters are reinstalled or replaced. Clients like web browsers see a certificate for puppet.example.com with a different signature or a duplicate serial number and generate errors instead of connecting the the server.

To have multiple signing servers you will need to coordinate the signing and revoking of certificates between servers. This can be done by locking systems to prevent concurrent update. It can also be done by some transaction system with the next valid serial number and CRLs exchanged between all signing systems.

Today puppet cert lacks any of this logic. The CRL is shuttled around by the Puppet Agents on the Puppet Masters during their runs causing runs. This cause service downtime. downtime as CRL updates restart Puppet Masters. At best you can backup the CRL, keys and CA to another mater master but you have to stick to signing consistently on just one master.