[Please help] - How to renew/fix certificate at puppetmaster level?

[puppet-bsd]

  Hi all,

I'm new in puppet. 

I'm currently using puppet 4.10

Long story short, puppet certificates were expired and by this time, I am renewing these certificates one node at the time (including the puppetmaster). 

Once the puppetmaster got "renewed" , I tried to create a node successfully but its first run of puppet agent -t got unsuccessful due to its related smart proxy server certificate for revoked. Performed a certificate renewal for the proxy and the new agent now runs fine.

However, it always happens everytime I create a new node. In the past, I don't have to renew proxy certificates. That means that there is something/somewhere in puppetmaster that isn't caught up in terms of certificates.

One try I made is to regenerate a new CA certificate but seems it isn't successful for the early described issue.

Can anyone please point how to fix the certificate at the puppetmaster level? 

[treydock]

My advise might not be the best but it's what worked for me when our master CA certificate expired.  These are my raw notes from when I had to renew our puppetserver certificate. The original certificate was likely Puppet 4 and expired when running Puppet 6.  I googled around and took some steps from various blog posts I found so most of this isn't my original ideas:

 # Verify

 cd /etc/puppetlabs/puppet/ssl/ca

 ( openssl rsa -noout -modulus -in ca_key.pem  2> /dev/null | openssl md5 ; openssl x509 -noout -modulus -in ca_crt.pem  2> /dev/null | openssl md5 )

 

 # Generate new CSR

 openssl x509 -x509toreq -in ca_crt.pem -signkey ca_key.pem -out ca_csr.pem

 

 # Sign

 cat > extension.cnf << EOF

 [CA_extensions]

 basicConstraints = critical,CA:TRUE

 nsComment = "Puppet Ruby/OpenSSL Internal Certificate"

 keyUsage = critical,keyCertSign,cRLSign

 subjectKeyIdentifier = hash

 EOF

 cp ca_crt.pem ca_crt.pem.old

 openssl x509 -req -days 3650 -in ca_csr.pem -signkey ca_key.pem -out ca_crt.pem -extfile extension.cnf -extensions CA_extensions

 openssl x509 -in ca_crt.pem -noout -text|grep -A 3 Validity

 chown puppet: ./*

 cd /etc/puppetlabs/puppet/ssl

 cp -a ca/ca_crt.pem certs/ca.pem 

 

 # CLIENTS

 

 /opt/puppetlabs/bin/puppet resource file /etc/puppetlabs/puppet/ssl/certs/ca.pem ensure=absent

 /opt/puppetlabs/bin/puppet ssl download_cert

 systemctl restart choria-server

For expired client certs, when that happens to me I will do "rm -rf /etc/puppetlabs/puppet/ssl" on the agent (never master) and then run Puppet which will request new cert then sign the cert and run Puppet again.  That process is rather tedious and not something I've automated really well but also not something I have had happen frequently as we don't tend to keep servers around for 5+ years.

[puppet-bsd]

Hi,

Obviously does it need file backup and the puppetmaster to be restated after the action. Correct?

[puppet-bsd]

Performed the Verify steps. Seems the values are not equal. Is there any steps in order to make the values equal?

On Friday, October 15, 2021 at 9:34:11 AM UTC-4 treydock wrote:

[treydock]

If the key and the certificate don't match, you may have to regenerate your puppetserver's CA and start from scratch essentially. I'm not aware of a way to fix a mismatch without totally starting over from scratch.  If you want to start from scratch, you usually just delete /etc/puppetlabs/puppet/ssl on puppetserver (or move to like /tmp or something) and restart daemon and puppetserver should regenerate everything.

[puppet-bsd]

Following the instruction to create the certificate from scratch and reissuing one of its agents (specially the smart proxy) it generates certificate revoke. 

In order to remote the revoked certificate, I had to restart the puppet agent service and to sign it in master. Just to test the agent (in the smart proxy ) works, the certificate gets revoked again.

Do I have to stop the puppetmaster as well?

[treydock]

I believe you only have to restart the puppetmaster if you modified the private keys used directly by master or the certs or CA used by master. Modifying client certs should not require restarting the master service.