Keystore Explorer Latest Version

[Carmina Piette]

Previousversions of KSE had some basic CA features like signing X.509 certificates, key creation, PKCS#10 requests, support for many X.509 extensions, extension profiles, but revokating certificates by creating/signing a certificate revocation list (CRL) has been missing so far.

The feature uses an automatically created file with the issuer serial number as its name and ".db" as its extension to save meta data like CRL serial number, the revoked certificates and the validity period. This makes creating subsequent CRLs much easier.

In contrast to the older PKCS#1 v1.5 signature scheme the Probabilistic Signature Scheme (PSS) from PKCS#1 v2.1 is provably secure. This does not mean that the v1.5 scheme is unsecure, but PSS should be preferred if possible.

When generating a certificate with KSE, a wide range of commonly used certificate extensions can be added. There are however some exotic or non-public extensions that are completely out of scope for a tool like KSE. With this new feature any extension can be added to a new certificate by entering the object ID (OID) of the extension and the value as a hex encoded string.

As before it is possible to either replace the original jar file with the signed one or create a new file. In the latter case the file name of the signed jar is created by adding a prefix and/or a suffix. The suffix is added before the file extension.

Every keystore entry with a matching name is selected after the search was executed. The number of selected entries has been added to the status bar, which gives an overview of the search result, which is useful if not all found entries fit into the window. This feature was contributed by Jairo Gratern.

Wherever you can enter OIDs in KSE, this new feature makes suggestions that you can select from a drop down list. Of course - if none of the suggestions should match, you can still enter another OID just like before.

Setting up secure LDAP (LDAPs) authentication for eDiscovery requires importing a valid certificate or certificate chain into the Java keystore file(s). This process can be daunting if done using the keytool command line interface with certificates provided in various formats and naming conventions. This article provides a method to streamline that process and take out some of the guesswork using an open source tool called KeyStore Explorer..

Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.

I did export the private key and public key as well with the same process that you explained for , but still it gives the error! It stores the private key in pkcs8 format. Is that the issue that it expects it to be in pkcs7 format! Is it due to the new version of KeyStore explorer tool? How to export it in pksc7 format? ShouldI use the older version of the tool? Or is there an option in module-signer POM file to accept the PKCS8 format as well?

Got it! Its working ! I think the problem was the name for the keystore file which was .keystore by default, which I changed to some some thing else, or it could be case sensitivity of the alias name which was different in the command line than as defined in the editor tool!

What about self signed models , are they acceptable in module showcase ?

Kevin McCluskey has also created a module Showcase API project in Ignition which has text section for Module Info and Module License. Where does this info go? Directly on the Module Showcase page?

The module.conf file must have a section specifying the file name of the license document, typically license.html, in the root of the .modl file. A section similarly specifies the top level html file of your documentation, or a PDF file. This is assumed to be in a doc folder of your .modl file.

How are modules to be distributed for evaluation? Do we include the signed .modl files in our downloads?

Does the License Key management have to be done by us using the tool supplied by Ignition on 15/09/2015 for all versions of Ignition, or only for 7.9 and above? Then how licenses are managed for 7.7 & 7.8?

Yes, you must host your signed module downloads and online documentation yourself. You can offer signed modules for eval purposes before you update the showcase, but you have to get the links to your customers yourself. Like with forum links here -- that's how I publish my betas.

Thanks a lot Phil. So I will be able to include the self signed modl files in my downloads. I will give you and kyle the first beta before I make them available on gitHub (perhaps by tomorrow) so that you can tell if I have included the right modl files or not.

I got the answer to my previous quest.

Another question, how to find out if our module is Licensed or not. (Like the isFreeModule(), is there any function that returns the Licensed status of our modl?).

Question: Do you have any idea why this fails? I am pretty sure, that the provided password is correct and that the location specified is also correct and the .pfx file looks also correct in KeyStore Explorer.

thanks for your answer. Maybe I set up the trace logging wrongly. Would it be possible for you to specify, exactly how I should set up the extended logging to retrieve the details error message when I try to create a new keystore Alias?

It turned out, that the reason was, that we were using a version of Keystore Explorer which was not compatible with webMethods 10.3 seemingly. Using Keystore Explorer version 5.44 together with java version jdk 8. 261 did the trick

Keystore Explorer is a graphical user interface with the same powers as OpenSSL, and used for many certificate conversions. This manual describes the most often used functions, like creating a keypair and CSR, importing your certificate into the keystore, exporting the keypair as PFX or PEM format, and importing a PEM key to convert to PFX.

OS, JDK are both supported versions. AD certs are imported into the JDK keystore, JAVA_HOME is set and JDK\bin is in the path... Using the same Base DN as did with WC 12, Bind user CN / PW is good (Used it with LDAP browser to connect to AD)... Can connect to the AD via openssl s_client -connect ADFQDN:636 and it responds with the connection info and cert...

Went back through things... Dunno how I made this mistake... but we have started replacing our jdk trust store to only include out needed certs... Musta misclicked in Keystore Explorer and created my keystore as a JCEKS instead of JKS.

Caused by: java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)

In troubleshooting, I have checked permissions... the trust store is valid... the installer user has access to the files.. What is odd, I used the same settings for the ldap connection as I did in 12.0.2.x install and that validated fine

The algorithms you mention should be there by default using the default security providers. NoSuchAlgorithmExceptions are often cause by other underlying exceptions (file not found, wrong password, wrong keystore type, ...). It's useful to look at the full stack trace.

I encountered this with @davidacland last week. The cause was in the certificate keystore (pfx) I was provided with; it didn't include the intermediate CA certificate that issued it (shown in the 'Issuer' field) which the JSS needs to present along with the server certificate itself in order for clients to trust it. Appending the intermediate certificate to the chain in the keystore, then re-importing the new keystore into Tomcat via the JSS solved it.

Once downloaded, I used KeyStore Explorer to append it (I'm a sucker for a GUI): -explorer.org/ - it's available on Windows and macOS. Open your keystore with it, right click the certificate and choose Edit Certificate Chain, Append Certificate and choose the intermediate CA cert you just downloaded.

The other thing we did as a troubleshooting step before we found the root cause (which I'm not sure was related or necessary now) was to replace the APNS certificate (delete it and request/install a new one). But be VERY careful because if you do that, it means all your devices need to be enrolled into MDM again - can be automated with Macs (watch out if you use a profile to configure wi-fi - if they're using that connection, it will drop when they re-enroll and the profile gets removed, then they can't pull down the new profile because no connection...) but iOS devices need to be re-enrolled by hand.

Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.

This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.

I am new in the IT field, and I have built a windows 2016 server VM, I used the all-in-one installer to get this guy going, and have 400 clients connecting properly. I have been tasked with getting our webconsole to go to HTTPS://era.******.com without the "your connection is not private" warning on chrome. I have spent an embarrassing amount of time trying to rectify this. I am not sure which end I have is wrong, I feel it is either the certificate I am using is wrong, or I can not get the commands processed properly to get a properly configured .keystore going. I have been following:

3a8082e126