How does my app know what private key to use - java

I have an app that runs on GlassFish 3.x. It communicates to a remote server over https. In my cacerts file I've added the server certs. In my keystore.jks I added the private key the company running the remote server issued me. This works great on Glassfish 2.x, however on 3.x they remote server keeps complaining that the key I have is invalid.
If I remove the key from the keystore I get the same error. It's as if it's not even loading the key, which has got me wondering how does the app / container know which key I need
My connection code looks like this:
public class SSLSocket {
private static Logger logger = LoggerFactory.getLogger(SSLSocket.class);
private ConnectionProperties connectionProperties;
public TuSSLSocket(ConnectionProperties connectionProperties) {
this.connectionProperties = connectionProperties;
}
public SSLSocket getSSLSocket() throws Exception{
SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket socket = (SSLSocket) factory.createSocket(connectionProperties.getHost(), connectionProperties.getPort());
socket.setSoTimeout(90000);
return socket;
}
}
I set the Host and Port accordingly, but no where do I say go look for this alias in the keystore. So... how does the app know what alias to grab?

Explaining two way ssl and all that jazz is exhausting. I will try to find a useful link. However, for your information when an applicaiton deployed in glassfish acts as a client to communicating with a server over SSL ( for instance LDAP server realm configured through an SSL port), it will use glassfish server's identity certificate (from its keystore) as its client certificate.
But if you are explicitly coding for SSL handshake, client application is responsible for selecting the keystore, and presenting the certificate as part of the handshake.
Since it is working in a previous version of Glassfish, the same code should work for you. It is very likely that your problem is related to configuration. I am a bit confused about what you had added to server's keystore.jks generally the other server's certificate is added to the trust store cacerts.jks
A useful glassfish ssl example
An SSL Socket client example
Example of choosing keystore in client.

There are two ways to accomplish this
The first:
Open the following path from the admin console page.
configuration
your cluster/instance configuration.
jvm settings
jvm options
you will find this line some where in the list of items
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
Change the s1as value to the certificate alias you want to use.
The other option is to add a system property to your code
System.setProperty("com.sun.enterprise.security.httpsOutboundKeyAlias", "your certificate alias");

Related

Apache directory API refuses to add user to Active Directory "(UNWILLING_TO_PERFORM)"

Im trying to add a user using Java 6 and Apache Directory API to Active Directory running on windows server 2008, but the result i get is (UNWILLING_TO_PERFORM), now i understand that it needs a secure connection and to use unicodePwd attribute to add the password, which i did, or at least tried to do.
The server admin created a certificate for the account i use when adding users, i exported it and added it to cacert in /jre/lib/security/.
I tried to see if i can just connect securely to the AD server without performing any operations, i get 2 scenarios that fail on the binding operation .bind():
1- if i connect using port 636 and use startTLS() available in ldapNetworkConnection : then i either get PROTOCOL_ERROR server will disconnect
2- if i connect using port 389 and use startTLS() available in LdapConnectionConfig i get "Failed to initialize the SSL context" and "IllegalArgumentException :TLSv1.1"
I added the trust manager but still no luck, below is the code so far.
LdapConnectionConfig config = new LdapConnectionConfig();
config.setLdapHost(IP);
config.setLdapPort(389);
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init((KeyStore)null);
config.setTrustManagers(tmf.getTrustManagers());
config.setName("CN=TestAdmin,CN=Users,DC=bmrk,DC=com");
config.setCredentials("P#ssw0rd");
LdapNetworkConnection ldapNetworkConnection = new LdapNetworkConnection(config);
ldapNetworkConnection.connect();
ldapNetworkConnection.startTls();
ldapNetworkConnection.bind();
// EDIT
i switched to JNDI LDAP APIs it gave me a more reasonable error, apparently the issue comes from the SSL handshake, my app isn't able to find the valid certificate, any recommendations?
Any help is really appreciated.
Thanks,
In Case anyone is interested, my only issue was in the adding the server that generated the certificate as a CA authority in the cacerts file so that the JVM can trust certificates issued by the server although it worked smoothly and perfect with JNDI ldap APIs it doesn't work with Apache Directory not sure why.
so my recommendation is to use JNDI instead of Apache Directory and make sure you export the certificate for the account used to login to Active Directory as PKCS12 and add it to the keystore.
so it's 2 certificates, 1 for the login/bind account and 1 for the server to act as a CA (Certificate Authority).
Also Java 6 support TLSv1 as a maximum security protocol which isn't the standard case with Apache LDAP, so either upgrade you Java or use JNDI.
it works perfectly with Java 7.

Mule ESB does not accept SSL cert when deployed on server, but works fine on local dev machine

I have Mule ESB deployed to a Linux server and Anypoint Studio running in my local windows dev environment. I have a fairly simple flow that includes a SalesForce connector. Salesforce REST API has a valid cert signed by VeriSign and my local instance of Mule happily accepts it and connects with no problems. However, when Mule runs on the server it always throws "PKIX path building failed, unable to find valid certification path to requested target".
I've tried using the default java keystore, specifying a keystore with javax.net.ssl.keystore, nothing works.
On my local machine I've ended up doing the following to show that Mule is using the right trust store:
I generated an empty truststore and added it to my AnyPoint project as a resource. I created an HTTPS connector configuration in order to explicitly specify the truststore I want to be used for my SalesForce connector, and pointed it to my empty truststore. When I try to run the project locally, I get the exact same SSL error (as I would expect, since it's an empty truststore). I then take the VeriSign CA cert and add it to my empty truststore. After that, locally everything works just fine. To me, this confirms that my mule project is using the truststore that I've added as a resource to the project itself.
I then export this project and deploy it to my server. On the server it throws the SSL error.
Can there be some weird JVM config differences that could cause this?
It turns out that Mule does not use a different trust store for each service. If you have multiple services deployed to it, the last service to declare a trust store explicitly will force all other services to use that same trust store, overwriting whatever configuration they may have. This was happening in my case. I found this out by echoing out System.getProperty("javax.net.ssl.trustStore"); to log and realized it's a trust store that was a resource in some completely different deployed project but being used by mine.
Seems like a pretty bad screw up by the Mule guys.
I agree with your suspicion that the JDK on your linux server doesn't trust the proper certificates. However, this doesn't need to stop your application from doing so.
I've been able to make the salesforce connector trust a given certificate by doing the following:
KeyStore truststore = KeyStore.getInstance("JKS");
truststore.load(myKeystoreInputStream, myKeystorePassword.toCharArray());
TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(truststore);
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, tmf.getTrustManagers(), null);
HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
The key is the last line. The salesforce connector uses HttpsURLConnection directly to connect to the server, while the HTTPS connector doesn't. This will allow your mule application to use a different trust store for salesforce than it uses for one or more HTTPS connectors. You can use this to control the SSL certificates that your application will trust, independently from the certificates that the server's JVM trusts.

Passbook APN certificate failing (Java/Groovy)

I'm trying to write a service in Grails to send push notifications to update passbook passes. I got to the point where I could test to see if the code to connect to the APN server was working, however, I cannot seem to establish a connection using the Java SSLSocket methods.
The first part of the connection works, I receive the certificate from the server and find a trusted certificate in the certificate chain; however, after that, for some reason my client certificate / certificate chain is not ever sent to the server, and hence the connection fails.
I can't seem to figure out why the certificate is not being sent, I use the following code to set up the keystore:
void setupSSLPropertiesForConnection() {
System.setProperty("javax.net.ssl.keyStore", "superSecretFile.p12")
System.setProperty("javax.net.ssl.keyStorePassword", "superSecretPassword")
System.setProperty("javax.net.ssl.keyStoreType", "PKCS12")
System.setProperty("javax.net.ssl.trustStore", "trustStoreFile")
System.setProperty("javax.net.ssl.trustStorePassword", "trustStorePassword")
System.setProperty("javax.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol")
}
and then to try and connect to the APN server:
setupSSLPropertiesForConnection()
SSLSocketFactory factory = (SSLSocketFactory)SSLSocketFactory.getDefault()
SSLSocket socket = (SSLSocket)factory.createSocket("gateway.push.apple.com", 2195)
I've looked at the PKCS12 file using Java's keytool and there is only one alias, which contains the entire certificate chain for my passbook certificate (certificate, WWDR, Apple Certificate), so I'm stuck on why the certificate isn't being sent when it's requested. Any help as to why it's not sending the certificate information would be muchly appreciated!
Edit: Also, if someone were to post a method of getting a SSL certificate from a .p12 used to sign passes or simply from the passbook certificate downloaded from the iOS dev portal, that is known to work, then I might be able to work backwards from that to figure out what it is I'm doing wrong.
Now I feel silly, apparently the filenames for my client PKCS12 file and the trust store file were both wrong, but in setting the keystore and truststore using the System.setProperty, it doesn't throw any error if the files cannot be found or opened.
I tried changing my code so that I am creating SSLSocketFactory from an SSLContext created with a TrustManagerFactory and a KeyManagerFactory, and when I tried that it threw FileNotFoundError. Now it seems to be working at least. Sigh.

Can't consume a SSL protected webservice with Java/Glassfish

I'm trying to consume a Webservice hosted under https security.
I'm using Java and glassfish and I'm getting the following error:
INFO: HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching testdomain.com found
The thing is that this specific server is used for testing and it's using the production certificate (the one with CN=domain.com)
I already added the domain.com certificate to my glassfish domain's cacerts keystore using keytool -importcert and it didn't work.
I also tried creating a self signed certificate with the CN=testdomain.com and adding it to the cacerts keystore and it didn't work either...
So how do I configure Java/Glassfish to consume this Web Service?
The CN of the server certificate should match the domain in URL to which the client connects. If still doesn't work, I would check if the IP maps to this hostname too (reverse DNS). It is the client, who verifies it. If you want to bypass this hostname verification, see the example code in my article: http://jakubneubauer.wordpress.com/2011/09/06/java-webservice-over-ssl/
The priciple is that you provide your own HostnameVerifier to the service client proxy.
THe self-signed certificate needs to be installed in the keystore of the Web service, along with its private key, and imported into the truststore of Glassfish.
the self signed certificate needs to be installed in key store of your java client. and testdomain.com should be resolved using dns.

SSL client - when is the certificate needed?

I have this:
SSLSocketFactory factory = HttpsURLConnection.getDefaultSSLSocketFactory();
SSLSocket socket = (SSLSocket) factory.createSocket("www.verisign.com", 443);
This is failing on the 2nd line with a "Connection refused" error.
Now, would I have to install verisign's certificate in my trust store before I can even do the above? I was under the impression that I could connect to an SSL server and execute getPeerCertificates() to get the certificates. Is this not what our browsers do? Otherwise how would they know which signing authority to use?
(Obviously I'm using Verisign as an example. My real URL is far too fugly to use here...)
Connection refused means nothing was listening at the target host:port, or a firewall got in the way. This is logically and temporally prior to anything SSL does.
Have you checked that the remote service is actually up and running, and that you can connect to it? Perhaps the "Connection refused" error is actually a refused connection. :-)
Usually you don't need to install server's certificate on your computer explicitly. PKI works in the way that your system should be able to validate server's certificate without any prior knowledge about it. However this will work only when your server's certificate has it's roots in on of the "known CAs", i.e. certificate authorities, whose root or other certificates are already listed on the client system. If this is not the case (eg. you have a self-signed or some other custom certificate on the server), you really need to install the certificate on your client system before the mentioned classes can validate server certificate properly.
You can read about certificates and how they are used in SSL here.

Categories