On Wednesday, March 19, 2014 10:15:19 AM UTC-5, [email protected] wrote: > > What would happen if I chattr +i ca_crl.pem to prevent it being updated? > > Certificate revocation is something that should be manually controlled > anyway. > > Suppose that the Puppet error message is wrong (or at least misleading) > and the problem is not revocation. If the crl.pem file is immutable and > this error really happened then I would know that it really isn't a > revocation, right? And if I ever do want to revoke a cert all I have to do > is chattr -i > > Would this break anything else in Puppet? > > However looking at it now, I can see that the ca_crl.pem was in fact > updated on the day I had problems with the puppetdb servers certificate > being 'revoked' so perhaps there is something revoking certs? Or is this > just coincidence? > > Here we go: > openssl crl -in ca_crl.pem -text shows a bunch of revocations and > > Serial Number: 0C > Revocation Date: Mar 17 18:15:36 2014 GMT > CRL entry extensions: > X509v3 CRL Reason Code: > Key Compromise > > why would some automated system think the key was compromised and revoke > it without any human intervention? > >
Key compomise is the default revocation reason; that's what Puppet will record if no other is specified. I remain dubious that anything within Puppet automatically revoked your certificates. I even had a look at the code, and found no evidence that Puppet has any automated mechanism to do that. All certificate revocations appear to come back to the test suite (you're not running that on your live master, right?) or to one of Puppet's UI termini. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/704e14cd-5f5f-4689-b8a4-b175cd775c09%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
