Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-2509

Prevent duplicate entries in Puppet CA's CRL

    XMLWordPrintable

Details

    • PUP Bug Template
    • Froyo
    • 3
    • Froyo - 7/28/2021, Froyo - 8/11/2021
    • Customer Feedback
    • Major
    • 2 - 5-25% of Customers
    • 4 - Major
    • 5 - $$$$$$
    • This is causing problems with a number of very large scale customers. The way the CRL is handled is very inefficient.
    • 16,000
    • Bug Fix
    • Previously the Puppet CA would add duplicate CRL entries. After the fix, we prevent duplicate entries and thus keep the CRL smaller.
    • Needs Assessment

    Description

      Using the 'puppet node purge' command it is possible to put duplicate revoked certificates in Puppet's CRL. For example:

      # puppet cert generate testcert
      Notice: testcert has a waiting certificate request
      Notice: Signed certificate request for testcert
      

      Now purge the node / certificate:

      puppet node purge testcert
      Notice: Revoked certificate with serial 650
      Notice: Removing file Puppet::SSL::Certificate testcert at '/etc/puppetlabs/puppet/ssl/ca/signed/testcert.pem'
      Notice: Removing file Puppet::SSL::Certificate testcert at '/etc/puppetlabs/puppet/ssl/certs/testcert.pem'
      Notice: Removing file Puppet::SSL::Key testcert at '/etc/puppetlabs/puppet/ssl/private_keys/testcert.pem'
      Node "testcert" was purged.
      

      But if we purge it again...

      puppet node purge testcert
      Notice: Revoked certificate with serial 650
      

      You can see that additional lines are added by looking at the output before / after the purge:

      openssl crl -in ca_crl.pem -noout -text | grep Serial | wc -l
      

      I suspect that PUP-2189 might contribute to this. I also suspect that the larger a CRL file gets the more likely it is to become corrupted, as it takes longer to hold open the file and add a long list of redundant serial numbers.

      Outcomes

      • Attempting to revoke a cert whose serial number is already in the CRL should be a no-op.
      • Include an output message when the above is attempted (probably INFO level).

      Implementation notes

      • want to check the performance when making sure we're not adding a duplicate serial. This is especially important for the batch revoke endpoint, to make sure it doesn't get super slow when revoking a lot of certs at once (the whole point of that endpoint was to be fast).

      Attachments

        Issue Links

          Activity

            People

              tu.vu Tu Vu
              erik.hansen Erik Hansen
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Zendesk Support