Giter Site home page Giter Site logo

puppetlabs / puppetlabs-java_ks Goto Github PK

View Code? Open in Web Editor NEW
34.0 163.0 97.0 819 KB

Uses a combination of keytool and openssl to manage entries in a Java keystore

License: Apache License 2.0

Ruby 99.44% Puppet 0.27% Dockerfile 0.29%
module supported hacktoberfest

puppetlabs-java_ks's Introduction

java_ks

Table of Contents

  1. Overview
  2. Module Description
  3. Setup
  4. Usage
  5. Reference
  6. Limitations
  7. License
  8. Development

Overview

The java_ks module uses a combination of keytool and openssl to manage entries in a Java keystore.

Module Description

The java_ks module contains a type called java_ks and a single provider named keytool. Their purpose is to enable importation of arbitrary, already generated and signed certificates into a Java keystore for use by various applications.

Setup

Beginning with the module

To get started with java_ks, declare each java_ks resource you need.

java_ks { 'puppetca:truststore':
  ensure       => latest,
  certificate  => '/etc/puppet/ssl/certs/ca.pem',
  target       => '/etc/activemq/broker.ts',
  password     => 'puppet',
  trustcacerts => true,
}

Usage

You must specify a target in some way. You can specify target after the colon in the title or by using the target attribute in the resource. If you declare both, it will prefer the attribute.

java_ks { 'puppetca:keystore':
  ensure       => latest,
  certificate  => '/etc/puppet/ssl/certs/ca.pem',
  target       => '/etc/activemq/broker.ks',
  password     => 'puppet',
  trustcacerts => true,
}

java_ks { 'broker.example.com:/etc/activemq/broker.ks':
  ensure              => latest,
  certificate         => '/etc/puppet/ssl/certs/broker.example.com.pe-internal-broker.pem',
  private_key         => '/etc/puppet/ssl/private_keys/broker.example.com.pe-internal-broker.pem',
  password            => 'albatros',
  password_fail_reset => true,
}

For use cases where you want to fetch the certificate data from a secure store, like vault, you can use the _content attributes. Here is an example:

java_ks { 'broker.example.com:/etc/activemq/broker.ks':
  ensure              => latest,
  certificate_content => $certificate_data_fetched_from_secure_store,
  private_key_content => $private_key_data_fetched_from_secure_store,
  password            => 'albatros',
  password_fail_reset => true,
}

NOTE: Sensitive fields like password, certificate_content and private_key_content can be deferred using the Deferred function. This will ensure sensitive values are not present in the Catalog.

You can see an example of its use below.

java_ks { 'broker.example.com:/etc/activemq/broker.ks':
  ensure              => latest,
  certificate_content => Deferred('sprintf', [$certificate_data_fetched_from_secure_store],
  private_key_content => Deferred('sprintf', [$private_key_data_fetched_from_secure_store],
  password            => Deferred('sprint', ['albatros']),
  password_fail_reset => true,
}

We recommend using the data type Senstive for the attributes certificate_content and private_key_content. But These attributes also support a regular String data type. The _content attributes are mutual exclusive with their file-based variants.

You can also use Hiera by passing params to the java_ks::config class:

java_ks::config::params:
  'broker.example.com:/etc/activemq/broker.ks':
    ensure: latest
    certificate: '/etc/puppet/ssl/certs/broker.example.com.pe-internal-broker.pem'
    private_key: '/etc/puppet/ssl/private_keys/broker.example.com.pe-internal-broker.pem'
    password: true

Certificates

To have a Java application server use a specific certificate for incoming connections, use the certificate parameter. You will need to simultaneously import the private key accompanying the signed certificate you want to use. As long as you provide the path to the key and the certificate, the provider will do the conversion for you.

Namevars

The java_ks module supports multiple certificates with different keystores but the same alias by implementing Puppet's composite namevar functionality. Titles map to namevars via $alias:$target (alias of certificate, colon, on-disk path to the keystore). If you create dependencies on these resources you need to remember to use the same title syntax outlined for generating the composite namevars.

Note about composite namevars: The way composite namevars currently work, you must have the colon in the title. This is true even if you define name and target parameters. The title can be foo:bar, but the name and target parameters must be broker.example.com and /etc/activemq/broker.ks. If you follow convention, it will do as you expect and correctly create an entry in the broker.ks keystore with the alias of broker.example.com.

Reference

For information on the classes and types, see the REFERENCE.md.

Limitations

The java_ks module uses the keytool and openssl commands. It should work on all systems with these commands.

Java 7 is supported as of 1.0.0.

Developed against IBM Java 6 on AIX. Other versions may be unsupported.

For an extensive list of supported operating systems, see metadata.json

License

This codebase is licensed under the Apache2.0 licensing, however due to the nature of the codebase the open source dependencies may also use a combination of AGPL, BSD-2, BSD-3, GPL2.0, LGPL, MIT and MPL Licensing.

Development

Puppet modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad hardware, software, and deployment configurations that Puppet is intended to serve.

We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things. For more information, see our module contribution guide.

puppetlabs-java_ks's People

Contributors

adrienthebo avatar bmjen avatar chelnak avatar cyberious avatar daianamezdrea avatar david22swan avatar davids avatar eimlav avatar eputnam avatar fatmcgav avatar glennsarti avatar gspatton avatar haus avatar hunner avatar johngmyers avatar jordanbreen28 avatar jtappa avatar justinstoller avatar lionce avatar lukasaud avatar malikparvez avatar michaeltlombardi avatar ody avatar pmcmaw avatar ramesh7 avatar reidmv avatar sanfrancrisko avatar sheenaajay avatar tomkitchen avatar tphoney avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

puppetlabs-java_ks's Issues

Feature Request: Support CA Directory Import

Many users will have CA certificates that are managed in a directory structure. It would be ideal to be able to read each CA certificate in the directory and import them without having to list each file individually or combine them artificially.

truststore is not idempotent for chain pem certificates

Describe the Bug

Consider

java_ks { "$cert_alias:$truststore_path":
ensure => latest,
certificate => $cert_path_unique,
trustcacerts => true,
password => $truststore_passwd
}

If $cert_path_unique is a pem file which contains an intermediate and a leaf certificate then puppet outputs the following every run
Java_ks[jREDACTED]/ensure: ensure changed 'present' to 'latest'

Expected Behavior

Puppet should be idempotent

Environment

  • Version [e.g. 5.0.0]
  • Platform [e.g. puppet 8 rhel 8]

Newly created store is of type PKCS12, even when storetype is JKS

Describe the Bug

Whenever a new store is created, a command is executed to create a new store. If you specify, JKS as storetype, you still get PKCS12 as type.

Expected Behavior

The store type is JKS.

Steps to Reproduce

1, Create the following configuration:

java_ks { 'some_alias':
        ensure              => latest,
        target              => '/some_path',
        password            => 'some_password',
        certificate_content => '...'
        storetype           => 'jks'
      }
  1. Run puppet and make sure the store does not exist yet.

Environment

  • Java_ks version 4.3.1
  • Puppet version 6.27.0
  • Linux RHEL 7

Additional Context

I found the issue in the code. See keytool.rb function def create. Based on the storetype different code is executed. The else case is done when storetype is jks, but no storetype is set in this command. Adding it would solve the issue.

Check, if keytool exists, before trying to execute it

Use Case

If keytool does not exist, sensitive Password is not “redacted” in Error-Message:

Error: /Stage[main]/Myprofilemodule/Java_ks[myRootCA]/ensure: change from 'absent' to 'latest' failed:  
Execution of 'keytool -importcert -noprompt -alias myrootca -file /etc/pki/tls/certs/myCA_root.pem -keystore /path/to/mykeystore -srcstorepass MyPassword -deststorepass MyPassword' returned 1:  
Error: Could not execute posix command: No such file or directory - keytool

Describe the Solution You Would Like

  • check, if keytool exists, before trying to execute it
  • prevent Password-Leak in other Error-Situations

Add SAN support to puppetlabs-java_ks

Use Case

Needing to add SAN extension, validity name, and distinguished name when generating the keystore

Describe the Solution You Would Like

Add SAN support

Describe Alternatives You've Considered

Managing keystores manually

error when pwd gets updated in ENC

Just tried out the module, with the password coming from an ENC (Foreman)

when changing the password in he ENC, puppet does not regenerate the keystore, but tries to update it with the new password which naturally fails and leaves the system in an inconsistent state

debug: Executing 'keytool -importcert -noprompt -alias puppetca -file /var/lib/puppet/ssl/certs/ca.pem -keystore /etc/pki/testvm02.localdomain.ks -trustcacerts'
err: /Stage[main]/Java_ks::Host/Java_ks[puppetca:keystore]/ensure: change from absent to latest failed: Execution of 'keytool -importcert -noprompt -alias puppetca -file /var/lib/puppet/ssl/certs/ca.pem -keystore /etc/pki/testvm02.localdomain.ks -trustcacerts' returned 1: Enter keystore password: keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

Allow no password

I'm not sure what's the reasoning behind forcing the password parameter to be present (and to be of a certain length). I'm trying to use this to provision a trustedca pem for sending email from java, i.e. adding it to the system-wide /etc/pki/java/cacerts, which doesn't have (or need a password).

As it is, the password restriction prevents me from using it for that. Is there something I'm missing? Isn't a password-less store common (e.g. if all it contains are public keys).

invalid curve name error

Describe the Bug

When using the puppet-openssl and puppetlabs-java_ks modules the passwords for the private key and the Java keystore files cannot be different. If they are different, it results in an error message invalid curve name error

Expected Behavior

The curve name is valid and the code works when both passwords are the same. The error message is elusive to what the issue is.

Steps to Reproduce

Install the puppet-openssl and puppetlabs-java_ks modules.

  x509_cert { certificate:
   ...
    password  => $private_key_pw,
   ...
  }

  java_ks { keystore_location:
   ...
    password  => $keystore_pw,
   ...
  }

When running puppet the error occurs on the line for the java_ks resource

Error: Could not set 'latest' on ensure: invalid curve name 
Wrapped exception:
invalid curve name

Environment

  • Version 4.3.0

Truststore Password not correctly validated.

TS files require a password of at least 6 characters. If you provide a password of under 6 chars, your puppet run succeeds, but the keytool command fails silently and no .ts file is created.

java_ks { 'truststore':
    ensure       => latest,
    certificate  => '/path/to/cert/cert.pem',
    target       => '/foo.ts',
    password     => 'test',
    trustcacerts => true,
  }    

The above code should be sufficient to reproduce this issue, assuming you can provide a .pem file.

undefined method 'environment' when $environment used in puppet:// URI

Just updated to the latest version and get following error when trying to use
an environment specific path in the puppet URI

(/Stage[main]/Jumio::Role::Platform/Java_ks::Keystore[platform]/Java_ks[myks:keystore]/ensure) change from absent to latest failed: Could not set 'latest on ensure: undefined method `environment' for #Puppet::Resource::Catalog:0x7f2ca4f0fa78 at /etc/puppet/environments/test/modules/java_ks/manifests/keystore.pp:51

the implementation is the following

java_ks { "${title}:keystore":
ensure => $ensure,
certificate => "puppet:///ssl/${environment}/${certificate}",
private_key => "puppet:///ssl/${environment}/${private_key}",
target => "${path}/${title}.jks",
password => $password,
trustcacerts => $trustcacerts,
}

Create keystore files as non-root user/groups

Use Case

By default the java_ks module create the target file with owner root group root (on linux systems), while this can be "fixed" with a post ACL change it would be cleaner if the module supported user and group parameters and created the target file as that user/group.

Describe the Solution You Would Like

java_ks accept user and groups parameters and creates/updates the target keystore as that user/group

Feature - autodiscovering JAVA_HOME in Ubuntu

I have a production problem with java_ks, when "target" parameter is constants:

target       => '/usr/lib/jvm/java-7-oracle/jre/lib/security/cacerts'

but when Java 1.7 was updated I need changed puppet manifest to:

target       => '/usr/lib/jvm/java-7-oracle-25/jre/lib/security/cacerts'

It is not solution and I need autodiscovering JAVA HOME and concating with "/jre/lib/security/cacerts" internal in "java_ks" extension.

Problem with $JAVA_HOME - it is not right way to discovering "java".

Extract JAVA path example:

$ update-alternatives --get-selections | grep "java\s" | awk '{FS=" ";print $3}' | sed 's/jre\/bin\/java//g'
/usr/lib/jvm/java-7-oracle/
$ update-alternatives --get-selections | grep "java\s" | awk '{FS=" ";print $3}' | sed 's/jre\/bin\/java//g'
/usr/lib/jvm/java-7-oracle-25/bin/java

What do you think about auto discovering java path in this puppet extension in Ubuntu ?

insync comparison is reverse of what it should be

Describe the Bug

When obtaining the array of fingerprints from a pkcs12 keystore, the list includes multiple certificates' fingerprints - each of the CAs in the chain is also in the fingerprint array returned. When this is compared to the "latest" in the insync function, the current is a large list of fingerprints which will never match the fingerprint being matched as latest.

This behavior of printing the corresponding CA certs seems to be for at least pkcs12 formatted keystores on java 17. We have multiple java 17 instances where there is an existing JKS keystore where the listing of the CA certs doesn't happen. This also only happens on a "leaf" cert.

Expected Behavior

Certificate is repeatedly deleted then re-imported as the comparison is the reverse of what it should be. Here is what happens when we print the fingerprint values being compared by the insync method:

Info: current has value:'["14:5A:5E:B0:18:E1:00:C3:C0:25:DD:32:91:3D:04:BE:E2:21:B0:A2:B3:23:92:CB:CF:AF:10:8D:7A:01:80:68", "25:CD:2D:9A:12:96:F9:3E:05:A6:0A:A3:62:B9:31:59:6A:83:43:8F:91:A6:47:25:C1:1A:3E:84:A4:C5:CD:D5", "2E:E8:86:28:AD:4D:71:87:19:34:CB:2C:EE:C4:F6:70:19:C7:78:B7", "8E:A0:FF:5D:3B:24:12:F7:D1:C5:E8:23:63:E0:E2:96:83:8E:7F:F6", "B8:B2:CE:01:17:65:78:9F:8E:8B:BC:CF:7C:22:35:BF:9D:37:D2:2F:7B:92:3E:8E:57:FA:24:EC:2B:A1:F3:4C", "BA:05:B0:A6:89:B8:2D:D6:7B:6E:6B:60:2B:1E:4A:9E:75:28:0F:4B"]'
Info: latest has  value:'["14:5A:5E:B0:18:E1:00:C3:C0:25:DD:32:91:3D:04:BE:E2:21:B0:A2:B3:23:92:CB:CF:AF:10:8D:7A:01:80:68", "BA:05:B0:A6:89:B8:2D:D6:7B:6E:6B:60:2B:1E:4A:9E:75:28:0F:4B"]'

Steps to Reproduce

Steps to reproduce the behavior:

  1. create a pkcs12 type keystore with this tool on JDK v17
  2. add ca and intermediate certs relevant to the leaf cert to be added later
  3. try adding the cert and observe that it will be repeatedly added during every puppet run.

Environment

  • Version puppet 6.28
  • Platform RHEL8
  • Java v17 (java version "17.0.3.1" 2022-04-22 LTS)

random failures in java_ks provider

Observe random errors in java_ks provider in PE2021.7.2 (puppet 7) environment, Amsazon Linux 2 agent, RHEL8 server

change from 'present' to 'latest' failed: Execution of 'keytool -v -printcert -file /tmp/certificate20230313-11787-1fogisx' returned 1: keytool error: java.io.FileNotFoundException: /tmp/certificate20230313-11787-1fogisx (No such file or directory)
java.io.FileNotFoundException: /tmp/certificate20230313-11787-1fogisx (No such file or directory)

The temp file is created by provider itself, so there seems to be some race condition

java_ks { "sat.example.com:${cacerts}":
    ensure              => 'latest',
    certificate_content => file("${module_name}/sat.example.com.pem"),
    password            => 'changeit',
    storetype           => 'jks',
  }

It doesn't happen each puppet run, I didn't find any pattern

certificate or certificate_content parameter is required when removing entries from Keystores

Describe the Bug

ensure => absent requires parameter certificate or certificate_content set

Expected Behavior

The certificate or certificate_content parameter should not be required when removing entries from Keystores

Steps to Reproduce

Steps to reproduce the behavior:

  1. Create java_ks resource with parameter
    ensure => absent
    but do not set the certificate or certificate_content parameter

Puppet will fail with:

Error: Failed to apply catalog: Validation of Java_ks[name_goes_here] failed: You must pass one of 'certificate' or 'certificate_content'

Environment

  • Version v4.3.0

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.