Issue #3360 has been updated by Matt Robinson.
There's been some confusion about the --allow_duplicate_certs behavior. The
issue seems to be that if you're using 'puppet agent' to connect to the master
with the same certname that is already signed, in both 2.6.x and 2.7.x the
behavior is the same (when the 2.7.x master has --allow_duplicate_certs set) in
that you get the message:
err: Could not request certificate: Retrieved certificate does not match
private key; please remove certificate from server and regenerate it with the
current key
However if you manually generate the Certificate Signing Request (CSR) using
curl or the new 'puppet certificate' face, it works. I haven't got to the
bottom of debugging, but it the agent is obviously doing something different in
which key it's using when it's verifying a certificate (presumably the CA's?).
So this isn't a regression in that with --allow_duplicate_certs set the
behavior is the same in 2.7rc as in 2.6. The new question is if the behavior
is the desired behavior or not.
One thing is clear, our SSL error messages could be a lot clearer. I'm going
to open a ticket to address the question of desired behavior and for better ssl
error messages in this case. I'll link both tickets to #3360.
----------------------------------------
Bug #3360: Add a flag to make puppet ca behavior on receipt of duplicate
request configurable
https://projects.puppetlabs.com/issues/3360
Author: Claus Divossen
Status: Closed
Priority: Normal
Assignee: Nick Lewis
Category: SSL
Target version: Statler
Affected Puppet version: 0.25.4
Keywords: puppetca autosigning signed certificate
Branch:
The puppetca accepts CSRs for CNs/nodenames that already have a signed
certificate, and signing the new certificates will overwrite the old certs
without warning or further validation. This seems to be introduced with the
work on Bug #2890.
The puppetca does not care about already exisiting signed certificates anymore.
This is especially dangerous in combination with autosigning: When autosigning
is active, any client can pretend to be another node as long as the desired
node name matches the autosigning pattern(s). In consequence, autosigning
completely disables the authorization process for matching node names.
If there are node specific secrets distributed with puppet, an attacker can
simply pretend to be another node with the "puppetd --fqdn" option and he will
get the other node's secrets without any questions asked.
The default behaviour should be to reject new CSRs for a node that already has
a signed cert, especially with autosigning. When puppetca is run manually, a
warning might be sufficient.
**[Nigel]** See [Note 33](http://projects.puppetlabs.com/issues/3360#note-33)
for the plan of action
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
