Java Cacerts Password

[Brook Mithani]

Im a bit confused about JKS "/etc/pki/java/cacerts".Am I right, that default password for this JKS is "changeit"?Can I change this password? If yes, shoud it be the same on all hosts connected to FreeIpa?Will it be problem later for FreeIpa? Should I somehow tell FreeIpa this password?

Export certificates of Your Artifactory

Open your artifactory in browser and export it (in order to get certificate from chrome browser open console, move to security tab and click view certificates, after that you will be able to export by dragging certificate icon to desktop).

Added Certificates in ca file

Import exported certificate in cacerts using command

keytool -import -alias yourartifactory.com -file exported_certificate.cer -keystore cacerts -storepass password

the default java cacerts password is changeit

Tested with oracle jdk 171.

the command in point 2 should be

keytool -import -alias yourartifactory.com -file exported_certificate.cer -keystore cacerts -storepass changeit

I already have made scripts to add certificates to the "machine" keystore (in C:\Program Files...) and those works using the default password "changeit". But if I try to use this password (or changeme, which is for Mac OS IIRC), I can't list or import certificate in users keystore, for example trusted.certs and trusted.cacerts. Is there another "default password" for those?

(The reason of this requirement is that we have a problem with an app that ignores certicate when we put them in the machine keystore, but if a user manually add the cert is in keystore with the Control Panel GUI, it works. So we have to deploy that solution to 18k+ users)

However, you mention using the Control Panel GUI, certmgr.msc (User) or certlm.msc (System), which manages the windows trust store. These are separate locations, but are used for the same thing

In an attempt to harden a setup running Instant Messaging (IM) Server, one of the tasks is to change the default cacerts password that comes by default with the Oracle JDK package.

Basically change to the one residing under the new JDK location for Instant Messaging, which resolves to:

This did not help, though: turns out that ca-certificates-java installs a script /etc/ca-certificates/update.d/jks-keystorethat whenever ca-certificates is updated, re-generates the java certificates. Given that ca-certificates wasalready installed on my system, the newly installed script was not invoked (or it did not work properly? See below).Fail. A simple apt-get install --reinstall ca-certificates seemed to run the script, and create the file.

However, the stack trace did not go away: the application kept failing. As I know nothing about how java certs arehandled in debian, I run a simple strace of the java interpreter running my application. A long shot, but greppingfor open in the strace.log file and looking for files that seemed relevant, showed that java was looking(among many other files) for /etc/ssl/certs/java/cacerts, which contained very little (and was non existant beforeinstalling ca-certificates-java).

Went to chromium, went to the https site the Java app was trying to access, looked at the root authority, looked for the correspondingfile in /etc/ssl/certs/ (a simple ls grep -i authorityname), and then run the commands:

Once this was done, the stack trace disappeared. Rather than debug jks-keystore, the fastest way to get thejava app to run was to (sigh, sigh, sigh :-() add all root certificates to the java/cacerts file.

I am having the same problem. Can you tell me exactly how you fixed the .net library? I tried redownloading the .net platform and it did not work. I have 32 bit java v25 both the runtime and the sdk. [import]uid: 55057 topic_id: 6814 reply_id: 34594[/import]

After verifying my JAVA_HOME was set to the correct directory, ran it again with only one Java installed, and it worked without me even having to enter passwords again. Thanks! [import]uid: 7721 topic_id: 6814 reply_id: 88251[/import]

The keystone is created successfully and then I startup the Corona Simulator. I goto build for Amazon/Kindle fill in all the fields, select my new keystore & place the password. The first prompt for the password seems to accept it, however once the build process starts I get a second prompt for the key alias password. I re-enter the same password and and it keeps telling me that the password for the key alias awechsler was not valid.

Sorry, I just did not want to create duplicate topics. The problem is exactly the same. If you install jdk-8u131, then another error appears during the build. This second error was just solved by installing a suitable Java, in my case, the assembly turned out only on version 11.

Great. Now lets try to check if its a machine or sitescope issue. I am assuming what if java is the culprit here. Was the java got updated recently? If yes from which version? Use 32 bit version of java. Try accessing the same page from other machine and let me know the result. Clear the browser cache and then give a try.

Could you try manually importing any one certificate and let us know the status please. This generally happens when you try to tamper with the default password. Hope its changeit. if not, please do change it and respond.

Is there any documentation for using secure settings (opensearch-keystore), and if not does anyone know what needs to be done to allow for secure configuration of security passwords (certs, auth ldap etc).

Looking over the source code for opensearch and the security plugin, it appears that some minor changes are needed in security/OpenSearchSecuritySSLPlugin.java at main opensearch-project/security GitHub to use SecureSetting.secureString rather than Setting.simpleString.

Is there a simpler way using variable interpolation in the yml files? I tried adding my own value into the keystore (say ldap_bind_password), and using bind_password: "$ldap_bind_password", but that errors are startup because the keys in the keystore appear to be validated for whether they are known or not

Question, I noticed you are referring to LDAP Bind Password. If I understand this correct, the password for the authentication connection is not working? Or you referring to OpenSearch Key store and the certification passwords not working? Also Certificates with pass phrase?

I also have LDAP configured with uses User/password. I created a service account ( i.e., opensearch_user, password123) to connect to my LDAP server. And last Certificates, using a passphrase this would be when creating those certificates.

I have configured a wildfly to use BC-FIPS as the security provider and I have configured a keystore of type BCFKS to work with it. I added the provider to java.security as the first provider and added BCFIPS to the internal SSL provider.

Part of my application code, on the server is opening a stream on a URL using https (basically client calls to server to get a page, the page is actually constructed from applying XSL to an XML file and sending the html back. When we are trying to parse the XML, by opening a stream on the URL that we get the following error:

Now, in the past we've had issues with this code when we turned on standard SSL. I was not involved so I can't say if this is the EXACT same issue. But it was solved by adding the root cert to java's cacert in java.security. That's not really going to work as this is a jks keystore and we can only read BCFKS. And this is mentioning Keystore instead of the truststore I'm wondering should I be trying to configure the java that runs this application to point to my bcfks keystore as a truststore? And would I be doing that by setting system properties for javax.net.ssl.trustStore, javax.net.ssl.trustStoreType, and javax.net.ssl.trustStorePassword? Or should I create a separate bcfks truststore with just the root cert ?

I should mention that I don't know that my truststore configuration is correct in my standalone.xml. But given the fact that we had a similar issue with these forms when we first turned on SSL and it was solved by adding the root cert to the java running wildfly's cacerts, I don't know that the truststore we set up in wildfly is or ever has be set correctly. Or it just could be that given the weird way we are generating the html for these screens on the back end is why we needed to use cacerts. I've tried two different configurations for my truststore

Then using the keytool and the bc-fips-1.0.0.jar I created a new cacerts that is of type BCFKS. I actually exported everything that was in the original cacerts from java, imported those plus my root cert which is what we needed in the first place.

The last I don't really care for,. but based on the source, it looks like I either set the password with this property or I don't have a password on the truststore and you can't create a truststore with keytool without a password.

The last thing I don't know about, or I should say I'm very unclear about is that I have a truststore configured in wildfly that doesn't appear to be being used. I'm not sure if it's just that I did it wrong? Or what. Is there some way I can figure out if anything uses it?

I made this shell script to automate the import of the newly renewed/created certificates into the Java Keytool and Glassfish.

Any pointers or ideas for improvements. Specifically if anyone know how to query for the password rather than hardcoding it.

Modify the four variables as needed.

I followed the tutorial above and created the keystore.jks for the new certificate, but the console login failed. I checked the link you shared but didn't know how to apply it correctly.

First in the tutorial link they mentioned NAME, can i set it with any name or should it be a specific name. Also how can i merge the newly created keystore.jks with the existing one in the domain config directory?

3a8082e126