Re: Importing CERTIFICATE into Java Keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Uma, Please keep posts on the list for the benefit of the community. On 11/22/2010 7:31 PM, uma ravi wrote: I am trying to import the certificate and did the same as you did but still go the same error.My test connection on IDm is not working.I saw your post (year back) that you got it working.Can you please send me the steps to get rid of this problem.It would be really helpful Please tell me what file(s) you have and what you are trying to achieve. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzsNCgACgkQ9CaO5/Lv0PBkoQCgwLUMIxjxHbgCm9LN4SrwlYRT jQEAn2fM9lRpqFicvVcFpZXAe+5Pb/GO =Pw1N -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Importing CERTIFICATE into Java Keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/20/2009 3:05 AM, Stephen . wrote: I got the LDAP connection working on my IDM. Test Connection Succeeded Glad to hear it. However, when I try to create a new User on the LDAP Resource, I get the following error : javax.naming.CommunicationException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Do you have an idea what this could mean? This means that your client doesn't trust the server's SSL certificate. How are you configuring your LDAP resource? You have not yet posted that, so it's hard to help, here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUGMMACgkQ9CaO5/Lv0PCv2wCbBODzpoquP5eA38U+OnB3yH/v h9QAoMLZGgjzGZ+8r/4SkJ43lxkI9Fai =U+CG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Importing CERTIFICATE into Java Keystore
Hi again, I got the LDAP connection working on my IDM. Test Connection Succeeded However, when I try to create a new User on the LDAP Resource, I get the following error : javax.naming.CommunicationException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Do you have an idea what this could mean? Thanks Regards Stephen Date: Thu, 19 Nov 2009 15:22:07 -0500 From: ch...@christopherschultz.net To: marr...@hotmail.com CC: users@tomcat.apache.org Subject: Re: Importing CERTIFICATE into Java Keystore -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/19/2009 2:42 AM, Stephen . wrote: My JAVA folder has 3 different locations which contain the command KEYTOOL I don't even know which of them is supposed to hold the certificate. None of those hold any certificates: they are just programs that operate on files called keystores. A keystore is a specially-formatted file that contains one or more certificates and keys. You can create a new one or use an existing one. Typically, your JVM has a system-level keystore installed that contains all of the special top-level certificates from the big guys like VeriSign and Thawte. That allows your JVM to trust certificates signed by those certificate authorities. X.509 (which is what all this stuff is defined as) is built on a tree of trust where a small number of implicitly-trusted entities (VeriSign, Thawte, etc.) are allowed to dictate who is and who is not trusted on the web via these certificates. It's a great racket. Yesterday, just to be on the safe side, I imported my certificate into ALL 3 locations (under 3 different aliases) The real question was which keystore you were operating on. From the 'keytool' manual page: Each keytool command has a -keystore option for specifying the name and location of the persistent keystore file for the keystore managed by keytool. The keystore is by default stored in a file named .keystore in the user's home directory, as determined by the user.home system property. So, do you have a file in ~/.keystore? If so, it's likely to be the place where all the certificates you are (re-)importing are going. You need to configure this keystore to be the one that is used for your JNDI connection. How are you configuring your JNDI resource? Please post the configuration (minus any passwords, of course) and tell us where that configuration appears. Then I found yet another command online which says that, it's not enough to import the certificate into keystore. It needs to be imported directly into the CACERT file. That sounds like malarkey. To make matters even worse, I found yet another advice in Tomcat's documentation, saying : before importing the certificate, you need to first import a so-called TRUST CHAIN. That may be possible. See... the big guys like VeriSign don't have just a single certificate/key that they use to sign your certificate(s): they have dozens. That is, in the tree of trust, there are many branches. There are many reasons for that which I won't go into, here. Basically, VeriSign's top-level cert (and they have more than one) trusts VeriSign's mid-level certs, which in turn trust VeriSign's lowest-level cert, which trusts you. If you want the JVM to trust your certificate, you need to provide your certificate (duh!) plus the 2 intervening (chain) certificates to bridge the chain of trust from your cert to the top-level VeriSign cert that ships with the JVM. In some places, it says you need this trust chain if the certificate was applied for by yourself. That statement is a bit ambiguous. is it: *keytool -import -file tomcatCert.crt -trustcacerts -alias tomcat -keystore c:/apps/jdk/jre/lib/security/cacerts -storepass changeit* or is it : * keytool -import -alias root -keystore your_keystore_filename -trustcacerts -file filename_of_the_chain_certificate* It's both, or neither :) Usually, you don't want to modify the keystore that came with the JVM (that's c:/apps/jdk/jre/lib/security/cacerts). Why? Because if you upgrade your JVM, then you're trusted certs will appear to vanish because the new JVM ships with a new cacerts file which doesn't include your changes. What would be best is something like this (the \s in here are a *NIX-style command continues on the next line convention... they are not intended to be actually entered on the command line, but indicate that you shouldn't press ENTER at the end of each line of text): keytool -import \ -file chain-1-cert.crt \ -trustcacerts\ -alias chain-1 \ -keystore path\to\my\keystore (then enter the password when prompted) This will import one of the chain
Re: Importing CERTIFICATE into Java Keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/19/2009 2:42 AM, Stephen . wrote: My JAVA folder has 3 different locations which contain the command KEYTOOL I don't even know which of them is supposed to hold the certificate. None of those hold any certificates: they are just programs that operate on files called keystores. A keystore is a specially-formatted file that contains one or more certificates and keys. You can create a new one or use an existing one. Typically, your JVM has a system-level keystore installed that contains all of the special top-level certificates from the big guys like VeriSign and Thawte. That allows your JVM to trust certificates signed by those certificate authorities. X.509 (which is what all this stuff is defined as) is built on a tree of trust where a small number of implicitly-trusted entities (VeriSign, Thawte, etc.) are allowed to dictate who is and who is not trusted on the web via these certificates. It's a great racket. Yesterday, just to be on the safe side, I imported my certificate into ALL 3 locations (under 3 different aliases) The real question was which keystore you were operating on. From the 'keytool' manual page: Each keytool command has a -keystore option for specifying the name and location of the persistent keystore file for the keystore managed by keytool. The keystore is by default stored in a file named .keystore in the user's home directory, as determined by the user.home system property. So, do you have a file in ~/.keystore? If so, it's likely to be the place where all the certificates you are (re-)importing are going. You need to configure this keystore to be the one that is used for your JNDI connection. How are you configuring your JNDI resource? Please post the configuration (minus any passwords, of course) and tell us where that configuration appears. Then I found yet another command online which says that, it's not enough to import the certificate into keystore. It needs to be imported directly into the CACERT file. That sounds like malarkey. To make matters even worse, I found yet another advice in Tomcat's documentation, saying : before importing the certificate, you need to first import a so-called TRUST CHAIN. That may be possible. See... the big guys like VeriSign don't have just a single certificate/key that they use to sign your certificate(s): they have dozens. That is, in the tree of trust, there are many branches. There are many reasons for that which I won't go into, here. Basically, VeriSign's top-level cert (and they have more than one) trusts VeriSign's mid-level certs, which in turn trust VeriSign's lowest-level cert, which trusts you. If you want the JVM to trust your certificate, you need to provide your certificate (duh!) plus the 2 intervening (chain) certificates to bridge the chain of trust from your cert to the top-level VeriSign cert that ships with the JVM. In some places, it says you need this trust chain if the certificate was applied for by yourself. That statement is a bit ambiguous. is it: *keytool -import -file tomcatCert.crt -trustcacerts -alias tomcat -keystore c:/apps/jdk/jre/lib/security/cacerts -storepass changeit* or is it : * keytool -import -alias root -keystore your_keystore_filename -trustcacerts -file filename_of_the_chain_certificate* It's both, or neither :) Usually, you don't want to modify the keystore that came with the JVM (that's c:/apps/jdk/jre/lib/security/cacerts). Why? Because if you upgrade your JVM, then you're trusted certs will appear to vanish because the new JVM ships with a new cacerts file which doesn't include your changes. What would be best is something like this (the \s in here are a *NIX-style command continues on the next line convention... they are not intended to be actually entered on the command line, but indicate that you shouldn't press ENTER at the end of each line of text): keytool -import \ -file chain-1-cert.crt \ -trustcacerts\ -alias chain-1 \ -keystore path\to\my\keystore (then enter the password when prompted) This will import one of the chain certificates you may need to import for whoever signed your certificate. Who did sign it, by the way? Repeat that command for each chain certificate you have to import. Now, import your own certificate: keytool -import \ -file your-cert.crt \ -trustcacerts\ -alias my-jndi-certificate \ -keystore path\to\my\keystore (then enter the password when prompted) This should get all your necessary certificates in one place: the file indicated by path\to\my\keystore. Please let us know where you intend to place this file. Now, to actually /use/ that keystore depends on how you are configuring your JNDI resource. Once we see that, we can help you point your configuration at this file. And what is the
RE: Importing CERTIFICATE into Java Keystore
Chris, thank you for your reply. And thank you so much for taking the time and trouble to explain all this to me. I really don't know much about JNDI. I don't even know where and how it is configured. But, I am going to try your suggestions, and see if it works out. If you want, I could keep you posted on this. Thanks again. Regards Stephen Date: Thu, 19 Nov 2009 15:22:07 -0500 From: ch...@christopherschultz.net To: marr...@hotmail.com CC: users@tomcat.apache.org Subject: Re: Importing CERTIFICATE into Java Keystore -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/19/2009 2:42 AM, Stephen . wrote: My JAVA folder has 3 different locations which contain the command KEYTOOL I don't even know which of them is supposed to hold the certificate. None of those hold any certificates: they are just programs that operate on files called keystores. A keystore is a specially-formatted file that contains one or more certificates and keys. You can create a new one or use an existing one. Typically, your JVM has a system-level keystore installed that contains all of the special top-level certificates from the big guys like VeriSign and Thawte. That allows your JVM to trust certificates signed by those certificate authorities. X.509 (which is what all this stuff is defined as) is built on a tree of trust where a small number of implicitly-trusted entities (VeriSign, Thawte, etc.) are allowed to dictate who is and who is not trusted on the web via these certificates. It's a great racket. Yesterday, just to be on the safe side, I imported my certificate into ALL 3 locations (under 3 different aliases) The real question was which keystore you were operating on. From the 'keytool' manual page: Each keytool command has a -keystore option for specifying the name and location of the persistent keystore file for the keystore managed by keytool. The keystore is by default stored in a file named .keystore in the user's home directory, as determined by the user.home system property. So, do you have a file in ~/.keystore? If so, it's likely to be the place where all the certificates you are (re-)importing are going. You need to configure this keystore to be the one that is used for your JNDI connection. How are you configuring your JNDI resource? Please post the configuration (minus any passwords, of course) and tell us where that configuration appears. Then I found yet another command online which says that, it's not enough to import the certificate into keystore. It needs to be imported directly into the CACERT file. That sounds like malarkey. To make matters even worse, I found yet another advice in Tomcat's documentation, saying : before importing the certificate, you need to first import a so-called TRUST CHAIN. That may be possible. See... the big guys like VeriSign don't have just a single certificate/key that they use to sign your certificate(s): they have dozens. That is, in the tree of trust, there are many branches. There are many reasons for that which I won't go into, here. Basically, VeriSign's top-level cert (and they have more than one) trusts VeriSign's mid-level certs, which in turn trust VeriSign's lowest-level cert, which trusts you. If you want the JVM to trust your certificate, you need to provide your certificate (duh!) plus the 2 intervening (chain) certificates to bridge the chain of trust from your cert to the top-level VeriSign cert that ships with the JVM. In some places, it says you need this trust chain if the certificate was applied for by yourself. That statement is a bit ambiguous. is it: *keytool -import -file tomcatCert.crt -trustcacerts -alias tomcat -keystore c:/apps/jdk/jre/lib/security/cacerts -storepass changeit* or is it : * keytool -import -alias root -keystore your_keystore_filename -trustcacerts -file filename_of_the_chain_certificate* It's both, or neither :) Usually, you don't want to modify the keystore that came with the JVM (that's c:/apps/jdk/jre/lib/security/cacerts). Why? Because if you upgrade your JVM, then you're trusted certs will appear to vanish because the new JVM ships with a new cacerts file which doesn't include your changes. What would be best is something like this (the \s in here are a *NIX-style command continues on the next line convention... they are not intended to be actually entered on the command line, but indicate that you shouldn't press ENTER at the end of each line of text): keytool -import \ -file chain-1-cert.crt \ -trustcacerts\ -alias chain-1 \ -keystore path\to\my\keystore (then enter the password when prompted) This will import one of the chain certificates you may need to import for whoever signed your certificate. Who did sign it, by the way? Repeat that command for each
Importing CERTIFICATE into Java Keystore
Hi. I have an IDM instance setup. I am currently trying to configure and set-up an LDAP Resource. During the configuration, I got the error : Could not connect to the LDAP server api.csc.fi. == javax.naming.CommunicationException: simple bind failed: api.csc.fi:636 Upon extensive research (on Tomcat websites, as well as Forums), I got the notion that I needed to import the ldapCertificate into my JAVA Keystore, otherwise it would be impossible for IDM to successfully connect to LDAP. I am using Apache Tomcat as my application server. I was able to locate several online documents which explained how to import a trusted certificate into the Keystore (unfortunately, these documents seem to give several different solutions to the same problem). Eventually, I decided to use the following command at my command-prompt : keytool -importcert -alias abc -file ABCCA.cer (where abc is the alias) The import was successful. However, I am still getting the same error on my LDAP configuration. Am I doing something wrong? Is there something ELSE I need to do ? Best regards, Stephen _ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
Re: Importing CERTIFICATE into Java Keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/18/2009 3:26 AM, Stephen . wrote: keytool -importcert -alias abc -file ABCCA.cer (where abc is the alias) You need to make sure that the keystore file you used to import the certificate is also the keystore used by the LDAP resource. Do you know what keystore into which you imported your cert? Do you know what keystore is being used by the LDAP resource? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksEUlEACgkQ9CaO5/Lv0PCpogCcDEhSp2nvPErskak6mbdkpJqR PD8AnjglMawq8ag9j3YTh9HefruQ4oLY =TR5G -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Importing CERTIFICATE into Java Keystore
Thanks for your response, No, I don't know any of these things. This is why I am so confused!! My JAVA folder has 3 different locations which contain the command KEYTOOL I don't even know which of them is supposed to hold the certificate. Yesterday, just to be on the safe side, I imported my certificate into ALL 3 locations (under 3 different aliases) Still did not work. Then I found yet another command online which says that, it's not enough to import the certificate into keystore. It needs to be imported directly into the CACERT file. But, it does not say HOW this should be done!! To make matters even worse, I found yet another advice in Tomcat's documentation, saying : before importing the certificate, you need to first import a so-called TRUST CHAIN. In some places, it says you need this trust chain if the certificate was applied for by yourself. In some places, it does not mention the trust chain at all, if you already trust the certificate. So, what exactly is the CORRECT way to do this? And what is the right command??? is it : keytool -import -file tomcatCert.crt -trustcacerts -alias tomcat -keystore c:/apps/jdk/jre/lib/security/cacerts -storepass changeit or is it :keytool -import -alias root -keystore your_keystore_filename -trustcacerts -file filename_of_the_chain_certificate or : keytool -import -alias tomcat -keystore your_keystore_filename -file your_certificate_filename or : keytool -importcert -alias abc -file ABCCA.cer Which is it ??? And what is the difference between KEYSTORE and CACERT I am just so confused!! Date: Wed, 18 Nov 2009 15:00:17 -0500 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: Importing CERTIFICATE into Java Keystore -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/18/2009 3:26 AM, Stephen . wrote: keytool -importcert -alias abc -file ABCCA.cer (where abc is the alias) You need to make sure that the keystore file you used to import the certificate is also the keystore used by the LDAP resource. Do you know what keystore into which you imported your cert? Do you know what keystore is being used by the LDAP resource? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksEUlEACgkQ9CaO5/Lv0PCpogCcDEhSp2nvPErskak6mbdkpJqR PD8AnjglMawq8ag9j3YTh9HefruQ4oLY =TR5G -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org _ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
