Issue #693 has been updated by Andrew Parker. Description updated Status changed from Closed to Re-opened Target version changed from 0.25.0 to 3.4.0
Either the fix for this regressed or the fix was never correct. However, we are seeing multiple errors when CSRs are submitted in parallel and autosigning is enabled. The submitted description is: > If too many new clients try to check in to the CA at the same time, the CA > gets confused. Errors on the client say Cannot find certificate request for > $HOSTNAME. The problem is that $HOSTNAME does not actually match the > hostname of the client returning the error. I have since been using a ssh > loop to avoid having them all check in at the same time and have not > encountered this again, but I saw it with as little as 5 servers checking in > for the first time at the same time. In addition after investigating we found that there were duplicate serial numbers showing up in the inventory.txt file. I've investigated the problem and it looks like there are at least two different parts to this: 1. Every CSR submission tries to sign all outstanding, unsigned CSRs. This causes each request process to race with the other ones because the signing process involves several steps of reading, writing, and creating files. 2. Issuing the next serial number requires updates to a single file (identified by the serial setting). Access to this is racing right now, and the current code that tries to provide locking is incorrect causing various races when updating the serial state. These two combine for some fairly racy logic around signing certificates. For item 1, I think the right solution is to have it only sign the certificate that was just submitted. Other CSRs are dealt with by their own request and if a CSR gets dropped, then the user can deal with it from the command line. For item 2, it looks like we need to overhaul the file locking in the settings system. Unfortunately because of the way files are accessed and managed simply using the new exclusive_open code is not sufficient. There are several parts of Puppet::Settings that need to be retained (user setting and mode control from the settings information). I think the best solution for this is to add an exclusive_open method to the FileSetting class and allow access to the FileSetting instance of serial rather than maintain the current system of write, writesub and readwritelock on Puppet::Settings. ---------------------------------------- Bug #693: Race condition in CA could result in two certs with same serial https://projects.puppetlabs.com/issues/693#change-99192 * Author: Luke Kanies * Status: Re-opened * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 0.25.4 * Keywords: * Branch: ---------------------------------------- In the 'sign' method in sslcertificates/ca.rb, the serial is read in, the certificate is signed, then a new serial is written out. This means that if two CAs are trying to sign a certificate at the same time, both certificates could theoretically get the same serial number. This method needs to be updated to use some kind of lock file, and the reading and modification of the serial number should be made more atomic. This way multiple CAs could run on the same host, which is important when running multiple Mongrel instances. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
