Details

    • Type: Epic
    • Status: Closed
    • Priority: Normal
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: SERVER 2.5.0
    • Component/s: None
    • Epic Name:
      Securing SSL Extensions
    • Template:
    • Sub-team:
    • Epic Status:
      Done
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      In this release we allow the signing of CSR that contain a new custom OID arc to represent secured extensions for use with trapperkeeper-authorization (the system that underpins the newer auth.conf routing).

      Signing CSRs wth the new OID arc is done via the command line via `puppet cert sign --allow-authorization-extensions`, a workflow similar to signing DNS alt names.

      The new OID arc is "puppetlabs.1.3", long name: "Puppet Authorization Certificate Extension", short name: "ppAuthCertExt" (where "puppetlabs" is our registered arc 1.3.6.1.4.1.34380). The extension "puppetlabs.1.3.1" (pp_authorization) should be set for CSRs that need to be authenticated via the new workflow. We've also include an default alias of "pp_auth_role" at extension "puppetlabs.1.3.13" for common workflows.

      We've also improved the CLI output of `puppet cert list` and `puppet cert sign` to be more user friendly with `--human-readable` and `--machine-readable` flags as well as allowing admins to force a prompt when signing certificates with a `--interactive` flag.

      We hope this allows easier automated fail over to authorized nodes within a puppet infrastructure and will hopefully open up possibilities for additional security workflows in the future. See https://docs.puppet.com/puppet/4.5/reference/ssl_attributes_extensions.html for additional infromation on Custom SSL Extensions in Puppet.
      Show
      In this release we allow the signing of CSR that contain a new custom OID arc to represent secured extensions for use with trapperkeeper-authorization (the system that underpins the newer auth.conf routing). Signing CSRs wth the new OID arc is done via the command line via `puppet cert sign --allow-authorization-extensions`, a workflow similar to signing DNS alt names. The new OID arc is "puppetlabs.1.3", long name: "Puppet Authorization Certificate Extension", short name: "ppAuthCertExt" (where "puppetlabs" is our registered arc 1.3.6.1.4.1.34380). The extension "puppetlabs.1.3.1" (pp_authorization) should be set for CSRs that need to be authenticated via the new workflow. We've also include an default alias of "pp_auth_role" at extension "puppetlabs.1.3.13" for common workflows. We've also improved the CLI output of `puppet cert list` and `puppet cert sign` to be more user friendly with `--human-readable` and `--machine-readable` flags as well as allowing admins to force a prompt when signing certificates with a `--interactive` flag. We hope this allows easier automated fail over to authorized nodes within a puppet infrastructure and will hopefully open up possibilities for additional security workflows in the future. See https://docs.puppet.com/puppet/4.5/reference/ssl_attributes_extensions.html for additional infromation on Custom SSL Extensions in Puppet.

      Description

      Provide a clean mechanism for setting certificate extensions to be used for cert-based authorizations (e.g. in TK-293). This mechanism needs to be different from our existing certificate extensions due to the need to prevent authorization-granting certificates from being accidentally signed.

      The logical way to do this is to create a new OID arc specifically for authorization-granting extensions.

      Our root OID is 1.3.6.1.4.1.34380 for "puppetlabs". We then have:

      puppetlabs.1:   "Puppet Certificate Extension"
      puppetlabs.1.1: "Puppet Registered Certificate Extension" (ppRegCertExt)
      puppetlabs.1.2: "Puppet Private Certificate Extension"    (ppPrivCertExt)
      

      See details here.

      Our CA will currently ONLY accept extension requests if they are under one of the existing ppRegCertExt or ppPrivCertExt OIDs. See the ruby code and the clojure code.

      To implement "authorization" certificate extensions, we could define another OID arc under puppetlabs.1. For example, we could define:

      puppetlabs.1.3: "Puppet Authorization Certificate Extension" (ppAuthCertExt)
      

      Because any extensions under this OID are flatline rejected today, we have full control over how we implement the methodology for accepting them. We could require on the command line something like:

      puppet cert sign --allow-authorization-extensions
      

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  nathaniel Nathaniel Smith
                  Reporter:
                  reid Reid Vandewiele
                  QA Contact:
                  Erik Dasher
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  9 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: