Updates to CA command line interaction in Puppet 6

[Maggie Dreyer]

Hello!

As you may know, we are about to release Puppet 6. This release contains a major update to the command line tools that are used to interact with Puppet's CA and certificates. The update makes the commands much faster and more reliable, removes duplication, and makes the interface easier to understand. However, this means that some scripts and workflows will have to be updated.

What is getting removed:

* puppet cert

* puppet ca

* puppet certificate

* puppet certificate_request

*puppet certificate_revocation_list

What is new:

* puppetserver ca (for CA tasks like signing and revoking certs)

* puppet ssl (for agent-side tasks like submitting a CSR and fetching a cert, though these steps will still usually be taken care of by an agent run)

We have been making updates to beaker and various test suites to account for this change. If you use Beaker to do any CA or certificate interaction in your tests, you will need to make some updates to test against Puppet 6:

1) Update to Beaker 4 and beaker-puppet 1. The latest release of both of these projects contains updates for these CA changes. Details.

2) Update any tests or pre-suites that use one of the removed commands to use the equivalent new command instead. For details, invoke `puppet cert` in Puppet 6 for help output containing the mapping of old commands to new alternatives. We will have docs pages up soon with this info.

The most recent Puppet 6 builds on puppet nightlies have these updates if you would like to try them out ahead of the release.

Please feel free to reach out to us if you have any further questions or feedback.

Thanks!

[Simon Tideswell]

Hello

I've upgraded a test server from Puppet 5.5 to Puppet 6 and the upgrade was quite seamless.

However post upgrade the puppetserver ca command does not work: it yields 403 denied errors. In auth.conf the new Puppet Server has elements like ...

allow: {

     extensions: {

          pp_cli_auth: "true"

      }

}

There's presumably the requirement to recreate the Puppet Server's own certificate with the additional extensions - but this doesn't appear to be documented anywhere? I've worked around this by using a simpler "allow" stanza including the Puppet Server's own certificate and it works, but it'd be nice if the post-upgrade requirement (of re-minting the certificate) was identified in the documentation. I can't say that recreating the certificate with the extension really seems to offer any obvious advantage over just using the server's own certname to be honest?

Simon

[Simon Tideswell]

Forgot to mention: this is on Ubuntu 18 (Bionic) using the packages pulled from apt.puppetlabs.com. Simon

[Maggie Dreyer]

Thanks for the feedback! We'll have docs around the upgrade scenario out shortly. We had instructions around exactly what you did in release notes for the 5.5 version where we started shipping the gem, as the best way forward to switch to using it in an existing install. I think that will probably continue to be the easiest way to enable the gem moving forward as well when upgrading.

Using the extension allows us to ship an auth.conf file that works out of the box for FOSS users doing new installs (we don't know their server hostnames ahead of time, and using something like localhost can be insecure). It's also resistant to hostname changes on the CA node.

Please let us know if you have any other issues!

--
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 puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/79019f37-9496-403d-8d0d-22ea0efa2a23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[schom...@glamus.de]

Hi again,

I also tried to set allow-unauthenticated: true for rule "puppetlabs cert status" and that worked.

Now I was able to sign the csr.

And sorry, puppetserver ca list now also works.

Yours Henri

[schom...@glamus.de]

Hi,

@Simon: Could you please describe how you solved that problem?

I already invested hours to at least find the reason for the problem that "puppetserver ca list" gives me a 403 Forbidden, but couldn't solve it until now.

And unfortunately this thread is the only  document I could find on google which refers to "pp_cli_auth".

Simply replacing ...

            allow: {
               extensions: {
                   pp_cli_auth: "true"
               }
            }

by ...

            allow-unauthenticated: true

... did not work for me.

That's a real big problem because we can't create new VMs for our customers now until it will be documented how to deal with this issue.

Many thanks in advance,

yours Henri

Am Donnerstag, 20. September 2018 00:58:06 UTC+2 schrieb Simon Tideswell:

[Maggie Dreyer]

Here are a few options that should work:

1) whitelist the master's certname (which is more secure than allow-unauthenticated anyway). See the example at the bottom of this section in the docs.

2) Another community member also created https://github.com/smortex/puppet-add-cli-auth-to-certificate yesterday, which adds the auth extension to your master cert.

For all of these things, it's important to remember to restart your server. The auth.conf file in particular won't be reloaded until you restart the server.

Let me know if you can't get any of this to work.

--

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 puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/16046491-82af-4321-93cc-c5a32f3385a3%40googlegroups.com.

[Justin Stoller]

On Thu, Sep 27, 2018 at 9:12 AM <schom...@glamus.de> wrote:

Hi again,

I also tried to set allow-unauthenticated: true for rule "puppetlabs cert status" and that worked.

Now I was able to sign the csr.

Be aware, this is a very dangerous way to solve the problem. This will allow anyone with http access to your CA to sign certs. Maybe your network is secure enough that that's okay, but in general folks should only whitelist the certnames or secure extensions that are allowed to admin a CA.

HTH,

Justin

 

--

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 puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9c901fae-18fb-4a76-91ad-b6cd35b761ef%40googlegroups.com.

[schom...@glamus.de]

Thank you very much Maggie,

1) did the job the right way. Perfect :-)

Yours Henri

[Simon Tideswell]

Hello Henri

I suspect you've already had this answered, but I just replaced the offending stanza ...

allow: {

     extensions: {

          pp_cli_auth: "true"

      }

}

with 

allow: "the.fqdn.of.my.puppetserver"

I actually have a number of Puppet servers serving different clients and so the auth.conf is managed by an ERB template and so the above is actually ...

allow: "<%= @fqdn -%>"

... in my template file.

Simon

--

[Mike Sharpton]

Thanks, I wasted about 60 mins before finding this after monkeying about trying to fix my CA.  Trying test upgrade from 4.2.2 to 6.0.1 in a split environment.  Wish me luck.  Thanks again!

Mike

[Evgenii Fedosov]

Hi Maggie,

I'm curretly trying to use puppetserver ca commands on m puppetserver but getting the following error message:

puppetserver: 'ca' is not a puppetserver command. See 'puppetserver --help'

I've dug through a ton of information but none of it references this exact message. I'm using puppetserver version 2.8.1 on centos-release-7-6.1810.2.el7.centos.x86_64. If any additional information is required I'll be happy to provide it. 

Thanks!

вторник, 18 сентября 2018 г., 9:33:05 UTC-7 пользователь Maggie Dreyer написал:

[Maggie Dreyer]

Hi Evgenii,

The `puppetserver ca` command is only available starting in version 5.3.5 of Puppet Server, released last August. Puppet Server 2.8.1 is EOL (along with all of Platform 4) and is not receiving feature updates like this one. You should probably try to use the `puppet cert` command instead, see https://puppet.com/docs/puppet/4.10/man/cert.html.

Let me know if you have any more questions.

Maggie

--

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 puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7ef434f2-e4af-4570-bec3-bcd4ee5e2582%40googlegroups.com.

[Evgenii Fedosov]

Hi Maggie,

I realized what the issue was once I posted it of course =)

Thank you for your suggestion but unfortunately I've tried using puppet cert but the system says "This command is no longer functional, please use 'puppetserver ca' instead", that's why I was trying the latter initially. I find it pretty weird that a command for an older version is deprecated without prividing an alternative.

Anyway, I updated to version 6.3.0 yesterday but now I'm getting these error messages:

/opt/puppetlabs/puppet/bin/ruby: /lib64/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /opt/puppetlabs/puppet/lib/libruby.so.2.5)

/opt/puppetlabs/puppet/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /opt/puppetlabs/puppet/lib/libruby.so.2.5)

From what I have found online, updating glibc is not a trivial task and should not be attempted on a live system. I have installed it into an alternative directory but now I struggle with setting it as default one for puppetserver to use. Any suggestions would be highly appreciated. 

Thanks!

пятница, 24 мая 2019 г., 9:34:49 UTC-7 пользователь Maggie Dreyer написал:

To unsubscribe from this group and stop receiving emails from it, send an email to puppet...@googlegroups.com.