Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5644

puppet lookup command creates new SSL hierarchy with self-signed CA

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: PUP 4.3.1
    • Fix Version/s: PUP 4.3.2
    • Component/s: None
    • Labels:
      None
    • Template:
    • Story Points:
      1
    • Sprint:
      Language 2016-01-13
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      The lookup command needlessly created a separate SSL hierarchy with self-assigned CA. Now it does not.

      Description

      Puppet lookup docs says it works on both masterless Puppet nodes, and nodes with a Puppet master (perhaps the docs should say server?). However it fails on agents, and produces an unexpected and unwelcome side effect on Puppet apply nodes.

      When using a masterless Puppet it creates a new SSL directory and populates a CA with a new key in the local node's name.

      [vagrant@client ~]$ cd .puppetlabs/etc/puppet
       
      [vagrant@client puppet]$  ls -la ssl
      ls: cannot access ssl: No such file or directory
       
      [vagrant@client puppet]$  puppet lookup puppet4::config
      Notice: Signed certificate request for ca
      ---
      log_level: info
       
      [vagrant@client puppet]$ ls -la ssl
      total 4
      drwxrwx--x 8 vagrant vagrant 119 Jan  3 10:23 .
      drwxrwxr-x 4 vagrant vagrant  49 Jan  3 10:23 ..
      drwxr-xr-x 5 vagrant vagrant 149 Jan  3 10:23 ca
      drwxr-xr-x 2 vagrant vagrant   6 Jan  3 10:23 certificate_requests
      drwxr-xr-x 2 vagrant vagrant  19 Jan  3 10:23 certs
      -rw-r--r-- 1 vagrant vagrant 967 Jan  3 10:23 crl.pem
      drwxr-x--- 2 vagrant vagrant   6 Jan  3 10:23 private
      drwxr-x--- 2 vagrant vagrant   6 Jan  3 10:23 private_keys
      drwxr-xr-x 2 vagrant vagrant   6 Jan  3 10:23 public_keys
       
      $ openssl x509 -subject -fingerprint -noout -in ssl/ca/ca_crt.pem 
      subject= /CN=Puppet CA: client.example.com
      SHA1 Fingerprint=DB:A7:FE:80:37:5A:1E:91:C9:FD:B7:0B:88:0E:D0:7D:54:4C:5E:C8
      

      Furthermore, on systems which do have an existing Puppet server, it produces the same local CA creation and then complains about the certificate not matching:

      vagrant@client ssl]$ puppet lookup puppet4::config
      Error: Could not prepare for execution: The certificate retrieved from the master does not match the agent's private key.
      Certificate fingerprint: 01:56:F3:17:17:A9:65:40:85:04:93:F3:14:A2:6A:A1:AE:DE:B3:52:0E:E7:B7:11:BD:4B:8C:64:74:EF:53:F9
      To fix this, remove the certificate (blah blah blah...)
      

      As before it has created a new SSL CA locally, which of course doesn't match the key used on the node's real certificate.

      [vagrant@client puppet]$ ls -la ssl/ca
      total 8
      drwxr-xr-x 5 vagrant vagrant   82 Jan  3 10:33 .
      drwxrwx--x 8 vagrant vagrant  119 Jan  3 10:33 ..
      -rw-r----- 1 vagrant vagrant 3243 Jan  3 10:33 ca_key.pem
      -rw-r--r-- 1 vagrant vagrant  800 Jan  3 10:33 ca_pub.pem
      drwxr-x--- 2 vagrant vagrant    6 Jan  3 10:33 private
      drwxr-xr-x 2 vagrant vagrant    6 Jan  3 10:33 requests
      drwxr-xr-x 2 vagrant vagrant    6 Jan  3 10:33 signed
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jorhett Jo Rhett
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support