http://stackoverflow.com/questions/24043397/options-for-programatically-adding-certificates-to-java-keystore
原文如下:
Options for Programatically Adding Certificates to Java KeyStore
I was getting an SSL Handshake Exception error: PKIX "path does not chain" . I fixed it by importing a certificate chain using openssl:
openssl s_client -host www.envmgr.com -port 443 -showcerts > cert_chain.crt
and installed it into my JDK's keystore:
keytool -import -alias envmgrchain -file cert_chain.crt -keystore cacerts -storepass changeit
Well this works. Hooray. The problem is we'll be putting our application up on a cloud server like rackspace or AWS and I think there is a good chance that we won't have access to modify the keystore of the JVM to add this chain.
I thought, "no problem, I'll just add this certificate chain to the keystore programatically" so I removed it from my JVM:
keytool -delete -alias envmgrchain -keystore cacerts -storepass changeit
and added this code:
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
//Create an empty keystore that we can load certificate into
trustStore.load(null);
InputStream fis = new FileInputStream("cert_chain.crt");
BufferedInputStream bis = new BufferedInputStream(fis);
CertificateFactory cf = CertificateFactory.getInstance("X.509");
while(bis.available()>0) {
Collection extends Certificate> certs = cf.generateCertificates(bis);
Iterator extends Certificate> iter = certs.iterator();
//Add each cert in the chain one at a time
for(int i=0; i0)?i:"");
trustStore.setCertificateEntry(alias, cert);
}
}
bis.close();
fis.close();
//Add custom keystore to TrustManager
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(trustStore);
SSLContext ctx = SSLContext.getInstance("TLSv1");
ctx.init(null, tmf.getTrustManagers(), null);
But when I run it, the PKIX error reappears. Is the above code not equivalent to keytool -import? I feel like I'm either adding certificates to the KeyStore incorrectly, or I'm not installing the Keystore into the TrustManager in the right way.
FYI: I am also attempting to address this issue by implementing an X509TrustManager
文中提到的 PKIX "path does not chain"的描述如下:
http://stackoverflow.com/questions/23775155/pkix-path-does-not-chain-with-any-of-the-trust-anchors-error-in-windows-environm
I am a bit of an idiot to how SSL and Webservices work at the fine-grained level. I am developing a system that calls several web services, some with secured URLs and others that are not with little problem. Currently, however, I am doing an integration with Endicia's LabelServer Web API. The webservice is used to calculate and print postage.
The test URL and WSDL is at: https://www.envmgr.com/LabelService/EwsLabelService.asmx
I used wsimport to create and setup a Java client for connecting to this webservice but when I try to all it I get the error
PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
This error is documented here: Java7 Refusing to trust certificate in trust store
in which it's discussed how Java 7 forces an error with self-signed certificates with "bad" keyusage. Bad in this situation is defined as not containing keyCertSign. The webservice does work with Java 6. I can believe this situation might apply to this certificate since it's only being used as a test server, but I don't know how to verify that.
There's a bug report on it that is solved (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7018897), but I'm not sure how any of this translates to fixing the problem for a Windows Tomcat environment. I exported the certificate onto my machine, but am uncertain of how to proceed from there.
EDIT: I tried using OpenSSL to modify the certificate and add it to my keystore as described in the "Refusing to trust certificate in trust store" link and it didn't work. It seems like this is a process that is done by the owner of the certificate, right? I wonder if there's some way I can configure my Java 7 environment to let this certificate through.
http://stackoverflow.com/questions/24032052/cpan-module-to-access-openssl-en-decrypt-cipher-operations/24070354#24070354
原文如下:
CPAN module to access OpenSSL (en/de)crypt (cipher) operations
I'm looking for a perl (CPAN) module to access OpenSSL's (en/de)cryption functions. Something entirely equivalent to piping through openssl enc ... (using the openssl binary) but without the overhead of fork/exec of a subprocess.
So far all the modules that I can find are more interested in implementing SSL or TLS, with all the associated communication and overheads. I am aware of Crypt::CBC, and the various compatible cipher modules such as Crypt::OpenSSL::AES, but this does the bulk of the work in perl, only calling the underlying (C) libraries for one block at a time, and this is too slow.
http://stackoverflow.com/questions/20573215/how-do-you-use-tlsv1-2-on-kitkat-was-where-is-openssl-1-0-1-in-the-android-19
作者是想用一个新的.jar包替换layoutlib.jar,但OpenSSL实现不了。
分析:这个不一定是漏洞引起,也有可能是编程技术问题导致。
帖子原文如下:
In the Android SDK for API level 16-18, OpenSSL 1.0.1 was available in sdk/platforms/android-18/data/layoutlib.jar (or 16, 17 instead of 18). This provided the org.apache.harmony.xnet.provider.jsse package.
An application using API level 18 cannot find the classes in this package on KitKat.
In API level 19, this package seems to have disappeared, to be replaced by org.conscrypt. This seems to be the new OpenSSL 1.0.1 provider, judging from the source code. However, I cannot find conscrypt in any of my Android SDK jars, for API level 19 or any API level, for that matter.
What do I need to do to use org.conscrypt in an app with API level 19, to replace the OpenSSL implementation that used to be in layoutlib.jar? That is, how can I use OpenSSL 1.0.1 with API level 19?
Thanks.
4月8日漏洞公布后,作者修订了这个帖子
UPDATED 2014-Apr-10
In the process of patching for the Heartbleed problem, I ran across this: https://www.ssllabs.com/ssltest/viewClient.html?name=Android&version=4.4.2. Qualys claims KitKat supports TLSv1.2 (for the first time; see the other Android versions there). This is encouraging, but I still cannot reproduce it. It suggests that maybe you don't need to use OpenSSL directly, but the AndroidHttpClient still uses TLSv1.