If you do this for fully automatic disaster recovery purposes, it might be worthwhile, but otherwise you have to think about if you actually save anything by investing the significant amount of time you need to reliably (!) automate what should be a very rare one-off operation (if you have to do this all the time, something's very wrong in your environment)....
A Redditor provided a detailed step-by-step that seems to have resolved the issue. The three key things were:
Make sure that the clocks are in sync (they were)
Make sure that the puppet service is stopped (it wasn't)
Invoke puppet agent with an explicitly defined target for the master, e.g.
puppet agent -t --server master1.example.com
That combination ...
puppet ca is being deprecated though and may not work, but please try:
puppet ca destroy slave2.example.com
Also check the /var/lib/puppet/ssl/ca/requests directory for any pending request certificates manually even though puppet cert list -a isn't showing anything. Infact, do a ls -lRa /var/lib/puppet/ssl/ on the master and search for the slave2 cert, ...
To add a SAN entry to the puppet server cert use:
systemctl stop puppetserver
puppetserver ca setup --subject-alt-names $(hostname -f),puppet
systemctl start puppetserver
may need to clear out existing certs via rm -rf $(puppet master --configprint ssldir) as well