Ben is right. You might have to import certs up the cert chain (like a
CA) and be sure to import it into the right cert store that OpenBD is using:
sudo keytool -importcert -v -alias zebra1 -file
/home/peter/Desktop/Zebra1-CA-Base64.cer -keystore
|/etc/java-6-sun/security/cacerts| -storepass changeit||
|
|sudo keytool -importcert -v -alias cheetah2 -file
/home/peter/Desktop/cheetah2b64.cer -keystore
|/etc/java-6-sun/security/cacerts| -storepass changeit||
sudo keytool -list -v -keystore |/etc/java-6-sun/security/cacerts|
-alias wa-cert -storepass changeit
Benjamin Davis said the following on 07/24/2012 10:46 AM:
Hey Matt,
You are barking up my tree with this one! At work, our apps use SSL
and most of the time the certificates are self-signed, so I am very
used to seeing the PKIX path error. :)
You are correct that this means that the java you are running does not
have the certificate and you are correct that you *do not* need to
enable SSL in Tomcat for this to work. Tomcat is just handling the
inbound connection.
So, a question on the site you are trying to connect to. Is the
certificate self-signed or is it signed by someone else? Usually if
it is signed by someone else, then Java has no issues. The only time
that it might, is if the root certicate of the signer is not
up-to-date inside of you Java instance. If it is self-signed, then
that totally explains it.
The certificate needs to be imported into the file called cacerts. On
Windows, this is found in jre6/lib/security. I would think that it
would be similar on Linux. My favorite tool to work with certificates
is Portecle (http://portecle.sourceforge.net/). There are plenty of
command line tools as well. If the site is self-signed, then you just
need to import the public key certificate into the keystore. If the
site is not self-signed, then you need each public key certificate in
the key chain since one signs another.
After you get all the certificates imported in the cacerts file (make
sure this is for the Java that Tomcat/Coldfusion is actually
running...I've imported it into the wrong one before! :)), then you
will need to restart Tomcat. That is the big kicker here. It doesn't
re-look at the file until a restart. I remember reading on the group
before about someone requesting to be able to use their own keystores
for cfhttp calls. If that was available, then you could just use a
new keystore and not have to worry about the restart.
Let me know how this goes! I've had my share of trying to diagnose
SSL issues! :)
Ben
On Mon, Jul 23, 2012 at 4:45 PM, Matthew Woodward
<[email protected] <mailto:[email protected]>> wrote:
Since I haven't had to do this in a million years I figured I'd
hit the group to see if someone can rattle off the steps to do
this quicker than me refreshing my memory via google.
I have two Linux VPSes I need to make CFHTTP calls to over SSL.
The servers I'm calling are set up fine, with SSL verified working.
When I try to CFHTTP to them with an https URL, I get this error:
Connect Exception: Failed to verify hostname due to IOException:
Connection has been shutdown: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building
failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target
If memory serves that means I need to import the SSL certificates
into the Java keystore, specifically under the JDK/JRE that Tomcat
is using. I took a stab at that but no dice so I'm assuming I did
it wrong.
Also if I'm only making outbound SSL calls I do *not* need to
enable SSL in Tomcat, right?
Any help with my very rusty recollection on all this would be
greatly appreciated!
Thanks,
Matt
--
Matthew Woodward
[email protected] <mailto:[email protected]>
http://blog.mattwoodward.com
identi.ca <http://identi.ca> / Twitter: @mpwoodward
Please do not send me proprietary file formats such as Word,
PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
--
online documentation: http://openbd.org/manual/
http://groups.google.com/group/openbd?hl=en
--
online documentation: http://openbd.org/manual/
http://groups.google.com/group/openbd?hl=en
--
Peter J. Farrell
OpenBD Steering Committee / Mach-II Lead Developer
[email protected]
[email protected]
http://blog.maestropublishing.com
Identi.ca / Twitter: @maestrofjp
--
online documentation: http://openbd.org/manual/
http://groups.google.com/group/openbd?hl=en
