Keystore Ex

[Lorin Searing]

A KeyStore manages different types of entries. Each type of entry implements the KeyStore.Entry interface. Three basic KeyStore.Entry implementations are provided:

• KeyStore.PrivateKeyEntry This type of entry holds a cryptographic PrivateKey, which is optionally stored in a protected format to prevent unauthorized access. It is also accompanied by a certificate chain for the corresponding public key. Private keys and certificate chains are used by a given entity for self-authentication. Applications for this authentication include software distribution organizations which sign JAR files as part of releasing and/or licensing software.
• KeyStore.SecretKeyEntry This type of entry holds a cryptographic SecretKey, which is optionally stored in a protected format to prevent unauthorized access.
• KeyStore.TrustedCertificateEntry This type of entry contains a single public key Certificate belonging to another party. It is called a trusted certificate because the keystore owner trusts that the public key in the certificate indeed belongs to the identity identified by the subject (owner) of the certificate. This type of entry can be used to authenticate other parties.

Each entry in a keystore is identified by an "alias" string. In the case of private keys and their associated certificate chains, these strings distinguish among the different ways in which the entity may authenticate itself. For example, the entity may authenticate itself using different certificate authorities, or using different public key algorithms. Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case. Whether keystores are persistent, and the mechanisms used by the keystore if it is persistent, are not specified here. This allows use of a variety of techniques for protecting sensitive (e.g., private or secret) keys. Smart cards or other integrated cryptographic engines (SafeKeyper) are one option, and simpler mechanisms such as files may also be used (in a variety of formats). Typical ways to request a KeyStore object include relying on the default type and providing a specific keystore type.

• To rely on the default type: KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); The system will return a keystore implementation for the default type.
• To provide a specific keystore type: KeyStore ks = KeyStore.getInstance("JKS"); The system will return the most preferred implementation of the specified keystore type available in the environment.

Before a keystore can be accessed, it must be loaded. KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); // get user password and file input stream char[] password = getPassword(); try (FileInputStream fis = new FileInputStream("keyStoreName")) ks.load(fis, password); To create an empty keystore using the above load method, pass null as the InputStream argument. Once the keystore has been loaded, it is possible to read existing entries from the keystore, or to write new entries into the keystore: KeyStore.ProtectionParameter protParam = new KeyStore.PasswordProtection(password); // get my private key KeyStore.PrivateKeyEntry pkEntry = (KeyStore.PrivateKeyEntry) ks.getEntry("privateKeyAlias", protParam); PrivateKey myPrivateKey = pkEntry.getPrivateKey(); // save my secret key javax.crypto.SecretKey mySecretKey; KeyStore.SecretKeyEntry skEntry = new KeyStore.SecretKeyEntry(mySecretKey); ks.setEntry("secretKeyAlias", skEntry, protParam); // store away the keystore try (FileOutputStream fos = new FileOutputStream("newKeyStoreName")) ks.store(fos, password); Note that although the same password may be used to load the keystore, to protect the private key entry, to protect the secret key entry, and to store the keystore (as is shown in the sample code above), different passwords or other protection parameters may also be used. Every implementation of the Java platform is required to support the following standard KeyStore type:

• PKCS12

This type is described in the KeyStore section of the Java Cryptography Architecture Standard Algorithm Name Documentation. Consult the release documentation for your implementation to see if any other types are supported.Since:1.2See Also:PrivateKey, SecretKey, CertificateNested Class SummaryNested Classes Modifier and TypeClass and Descriptionstatic class KeyStore.BuilderA description of a to-be-instantiated KeyStore object.static class KeyStore.CallbackHandlerProtectionA ProtectionParameter encapsulating a CallbackHandler.static interface KeyStore.EntryA marker interface for KeyStore entry types.static interface KeyStore.LoadStoreParameterA marker interface for KeyStore load and store parameters.static class KeyStore.PasswordProtectionA password-based implementation of ProtectionParameter.static class KeyStore.PrivateKeyEntryA KeyStore entry that holds a PrivateKey and corresponding certificate chain.static interface KeyStore.ProtectionParameterA marker interface for keystore protection parameters.static class KeyStore.SecretKeyEntryA KeyStore entry that holds a SecretKey.static class KeyStore.TrustedCertificateEntryA KeyStore entry that holds a trusted Certificate.Constructor SummaryConstructors ModifierConstructor and Descriptionprotected KeyStore(KeyStoreSpi keyStoreSpi, Provider provider, String type)Creates a KeyStore object of the given type, and encapsulates the given provider implementation (SPI object) in it.Method SummaryAll Methods Static Methods Instance Methods Concrete Methods Modifier and TypeMethod and DescriptionEnumerationaliases()Lists all the alias names of this keystore.booleancontainsAlias(String alias)Checks if the given alias exists in this keystore.voiddeleteEntry(String alias)Deletes the entry identified by the given alias from this keystore.booleanentryInstanceOf(String alias, Class

The Java Development Kit maintains a CA keystore file named cacerts in folder jre/lib/security. JDKs provide a tool named keytool[1] to manipulate the keystore. keytool has no functionality to extract the private key out of the keystore, but this is possible with third-party tools like jksExportKey, CERTivity,[2] Portecle[3] and KeyStore Explorer.[4]

in your nifi.properties, then for the client, you probably want to generate a separate cert that has been signed by the same CA that your NiFi node(s) trust. I.e. either use the same self-managed CA (such as the one that Ambari installs for you) or use official (mostly paid) CA-signed certificates.

Your client curl command would not be pointing at a secure :10001/contentListener end-point and will need its own certificate to present in this connection. You can use the toolkit to generate another pkcs12 keystore that your connecting client can use. That way it gets signed by the same CA.

I have read through a lot of discussions on how to solve this issue but nothing is working.
I am working on an install process for the winlogbeat service.
The Service installs and starts with no issues showing.
But if you go the logs and review, I get the following error messages:

I also recreated the Keystore, using the following commands to see if would resolve the issue ;
winlogbeat keystore create -E keystore.path= C:\ProgramData\winlogbeat
winlogbeat.exe --path.data "C:\ProgramData\winlogbeat" keystore add DFWES_PWD.

HINT on the issue;
I also made sure that the Keystore is in the ProgramData folder. I did a copy command on the Keystore file. When I "MOVE" the Keystore ( from Program Files to ProgramData ) the Service is not finding the file. That means the service is looking at Program Files for the Keystore.

I also recreated the Keystore to make sure it was in ProgramData\winlogbeat
winlogbeat keystore create -E keystore.path= C:\ProgramData\winlogbeat
and added the password for the Key and verified that it was there.

The keystore is located by looking in path.data. (ref). The windows service sets path.data to programdata. You can look at the properties of the service to verify this. So I think rather than setting keystore.path you should set -E path.data=C:/ProgramData/winlogbeat when manually running the exe (mimic what the service's command does). Also note the -E vs -e.

Also for debugging I would try to cause an error when the variable is not found via the keystore. See Use environment variables in the configuration Winlogbeat Reference [7.16] Elastic. This way you get a hard failure long before it tries to connect to ES.

I am still getting the same Error Message BUT when I enter in the "password" in the config file, it connects and sends the data. The following is some of the information that I receive when I manually start the service using the Keystore. ( removed the IP address of the host(s) )

A keystore can be a repository where private keys, certificates and symmetric keys can be stored. This is typically a file, but the storage can also be handled in different ways (e.g. cryptographic token or using the OS's own mechanism.)

KeyStore is also a class which is part of the standard API. It is essentially a way to load, save and generally interact with one of the "physical" keystores as described above. A KeyStore can also be purely in memory, if you just need the API abstraction for your application.

How to load and handle such a KeyStore instance depends on the format of the keystore file (or other storage system) that backs it. Multiple formats are available. Some of the most common are JKS and PKCS#12 (.p12).

"keystore" can also be used as the counterpart of "truststore". This is where it can get confusing, since both "keystore" and "truststore" are keystores, they're just used for different purposes. You can find more details in this answer. The keystore is used to initialise the key manager, whereas the truststore is used to initialise the trust manager. From the JSSE reference guide:

c80f0f1006