[PUP-2018] `puppet certificate generate` Generates Two CSRs in One Run Created: 2014/03/22  Updated: 2016/12/16  Resolved: 2016/08/20

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: PUP 3.4.3, PUP 3.7.1
Fix Version/s: PUP 4.6.1

Type: Bug Priority: Normal
Reporter: Riley Shott Assignee: John Duarte
Resolution: Fixed Votes: 3
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

One Puppet Master & separate CA server (both configured as below):
CentOS 6.5 x86_64
RVM - Ruby 2.0.0-p451
Puppet installed via a Gem (3.4.3)
VirtualBox VM


Issue Links:
Blocks
Duplicate
is duplicated by PUP-3178 puppet certificate generate also gene... Closed
Relates
Support
Template:
Story Points: 3
Sprint: Client 2016-08-10, Client 2016-08-24
CS Priority: Reviewed
Release Notes: Bug Fix
Release Notes Summary: This fixes a bug in the `puppet certificate generate` command where it attempted to generate a CSR for the FQDN for the host when the same FQDN was provided as the remote.

 Description   

When I run the following on my Puppet Master:

`puppet certificate generate --verbose --ca-location remote HOSTNAME`

I receive the following:

http://pastie.org/private/ackais1tdrc0lyjyekozxq

The remote Puppet CA does successfully sign the request (autosign is configured), but the command will always exit 1 because of the second CSR creation (which is unnecessary).

I have noticed that if the Puppet Master already has a CSR in its '*/ssl/certificate_requests/' directory, the command runs as expected:

http://pastie.org/private/iueobgf93b8q0k4edmi56q



 Comments   
Comment by Lee Lowder [ 2015/02/02 ]

This issue exists in PE 3.2.x - PE 3.7.1

Comment by R.I.Pienaar [ 2016/07/10 ]

Eric Sorenson repro steps..I dont think puppet cert can talk to remote CAs so not sure if it does the exact same thing

Here I expect just one cert made but it makes the new one and then the fqdn one - which the master already have and so i get the wrong key error

If I set --certname rip.mcollective (to match the requested cert) it attempts to make the same cert twice.

% rm -rf .puppetlabs/etc/puppet/ssl
% puppet --version
4.5.2
% ls /home/rip/.puppetlabs/etc/puppet/csr_attributes.yaml
ls: cannot access /home/rip/.puppetlabs/etc/puppet/csr_attributes.yaml: No such file or directory
% puppet certificate generate rip.mcollective --ca-location remote --ca_server dev5.devco.net --debug --verbose
....
Info: Creating a new SSL key for rip.mcollective
Info: csr_attributes file loading from /home/rip/.puppetlabs/etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for rip.mcollective
Info: Certificate Request fingerprint (SHA256): 36:A7:C0:2B:14:21:36:7D:03:33:35:5D:DF:C6:45:82:8E:20:7F:97:82:45:79:30:60:46:E8:E4
:04:B9:40:56
Info: Creating a new SSL key for dev3.devco.net
Debug: Creating new connection for https://dev5.devco.net:8140
Info: Caching certificate for ca
Debug: Creating new connection for https://dev5.devco.net:8140
Info: Caching certificate for dev3.devco.net
Error: The certificate retrieved from the master does not match the agent's private key.
Certificate fingerprint: 5F:38:23:92:F8:10:31:DB:D5:FF:08:D9:AA:A7:EE:89:DB:9D:B4:31:4C:81:0C:72:C7:9F:1B:E4:C6:62:AC:11
To fix this, remove the certificate from both the master and the agent and then start a puppet run, which will automatically regene
rate a certficate.
On the master:
  puppet cert clean dev3.devco.net
On the agent:
  1a. On most platforms: find /home/rip/.puppetlabs/etc/puppet/ssl -name dev3.devco.net.pem -delete
  1b. On Windows: del "/home/rip/.puppetlabs/etc/puppet/ssl/dev3.devco.net.pem" /f
  2. puppet agent -t
 
Error: Try 'puppet help certificate generate' for usage

Comment by R.I.Pienaar [ 2016/07/12 ]

side note, this breaks the mcollective install docs, be good to get this fixed

Comment by Adrien Thebo [ 2016/08/15 ]

Reading more information related to this ticket leads me to suspect that there might be multiple bugs that trigger this issue, but I've found at least one of them. The bug that I've found is due to how we generate a CSR the first time a HTTP connection is requested. In normal operation Puppet will request a certificate from the CA the first time that certificate is needed; in practice this is any authenticated HTTP request to the master. puppet certificate generate breaks some assumptions around this though, because that command will make requests that would normally require a certificate but when no certificate is available. If the command is used to submit a CSR for another node, then the command will actually submit a CSR and request a cert for the node itself before submitting the request for the original node. In the case where a node is requesting a certificate for itself though, Puppet will effectively submit a CSR and request a certificate so that it can then resubmit that CSR and request the same cert. This is where we get that duplicate CSR submission.

Comment by John Duarte [ 2016/08/20 ]

Validated using a pre-release build of puppet-agent at SHA ad760e5 containing puppet at SHA 4e7bbb0.

The puppet certificate generate command no longer attempts to create a CSR for the FQDN of the host if the same FQDN is passed as the remote value.

root@ivbktz9ku535fmo:~# puppet certificate generate --debug --verbose --ca-location remote $(facter fqdn)
...
Info: Creating a new SSL key for ivbktz9ku535fmo.delivery.puppetlabs.net
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for ivbktz9ku535fmo.delivery.puppetlabs.net
Info: Certificate Request fingerprint (SHA256): A6:1D:CC:E3:B3:39:B5:1A:44:1E:1D:05:6B:65:F3:83:5E:8E:11:6E:3E:A4:5A:06:64:80:70:DE:D6:8B:4A:20
true
root@ivbktz9ku535fmo:~# echo $?
0

Generated at Sat Dec 07 20:53:20 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.