Develop Reference

Does Java Runtimes require use of Keystore for SSL certificates as mandatory?

I would like to understand the Java runtime's requirement for SSL certificates storage in general.
I understand it can be copied to the host's /etc/ssl/certs folder but for Java, does it need to import to a specific Keystore for a runtime to be able to use and consume in any SSL verification process by the application?
E.g.
If I have a JRE client that requires packaging of a root/intermediate certificates to make web client internally to site1.foo.com, I will need the root and intermediate certificates dependent on the chain to verify the request.
With various other runtime environments, it seems I can just place them in the /etc/ssl/certs folder:
NodeJS => How to add custom certificate authority (CA) to nodejs
Go => Where is Golang picking up root CAs from?
However, presumably for usage in Java, I need to go an extra step and use keytool and import into a specific Keystore?
Presumably, it can't just pick up from a common directory as per above?
Hope my question makes sense.

In Java, collections of certificates are usually accessed through a KeyStore interface.
As remarked in the comments the default SSLContext will read the certificates from a PKCS12 (or JKS) file located in $JRE_HOME/lib/security/cacerts.
However that is not the only possibility and you don't have to call keytool to add trusted certificates:
on Debianoids you can use -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts (cf. this question) to use the the PKCS12 file provided by the ca-certificates-java package. It is updated whenever you call update-ca-certificates. Therefore you just need to add a *.crt file in /usr/local/share/ca-certificates and run update-ca-certificates.
if you don't use the default SSLContext you can init it with a different TrustManager (cf. this question). That's how Tomcat 8.5+ loads certificates in PEM format.
Unfortunately there is no implementation of KeyStore that reads certificates from a directory, but that can easily be written.
Edit: On Debianoids the packaged JREs already use /etc/ssl/java/cacerts, so no further configuration is needed.

how does keytool know which CA to use

The server has changed from http to https. Instead of modifying client code (of course the host which was http is now https), we use keytool to save server CA. When I used keytool, I see a list of all stored CA (about 100 pieces).
So how does JRE know which CA to use? And what is the story behind this, like why when JRE is configured with a CA the client code could remain the same?
Thanks.

I'm trying to answer the basic questions you pose.
Java and Keytool know which CAs to trust by consulting a special file named cacerts which is shipped with the JRE and it's placed in <JRE_HOME>/lib/security.
This kind of file is usually called KeyStore or TrustStore.
This file is shipped by default by the "creator" of the JRE (e.g. Oracle) and contains list of Certificate Authority certificates to be trusted (usually updated at every release).
It's not that different from the same process for browsers.
As for the story behind this, if I understand correctly, we are talking about PKI (Public Key Infrastructure) which, in you case, very roughly, means that when your JRE keystore gets updated with the new CA certificate, then entities (such as SSL Sites, applets,etc) presenting a certificate provided (usually sold) by that CA are now basically valid and trusted, since now a trusted third party (the new CA) can guarantee (by means of encryption and digital signature) that "you are effectively you" in a digital scenario.
Also worth noting that, Keytool can be instructed to use a user-defined keystore with the -keystore <keystore_path> command line option (and even the JVM can configure a specific non-default truststore for SSL connection via a system property like this)

using KeyStore with .crt

I need to integrate an application with external web service which forces to use https. Authors of this web service provided me with .crt file which I should use for making https requests. After some investigation I've found the following code which uses KeyStore class for secured https access:
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
FileInputStream instream = new FileInputStream(new File(file));
try {
trustStore.load(instream, password.toCharArray());
} finally {
instream.close();
}
SSLContext sslcontext =
SSLContexts.custom().loadTrustMaterial(trustStore, new TrustSelfSignedStrategy()).build();
SSLConnectionSocketFactory sslsf =
new SSLConnectionSocketFactory(sslcontext, new String[]{"TLSv1.2"}, null,
BROWSER_COMPATIBLE_HOSTNAME_VERIFIER);
HttpClients.custom().setSSLSocketFactory(sslsf).build();
In this code KeyStore requires input stream along with password trustStore.load(instream, password.toCharArray());. However, as I understand, we don't need password when using .crt file. So this way of loading certificate is not suitable for me. At the same time, from what I've discovered so far, the code I provided here is the only way to configure HttpClient for using SSL certificate. Is there any workaround to configure HttpClient for using .crt certificate?
Thanks,
Andrey

I assume the Web service is providing you with a self-signed certificate (i.e. not signed by a well-known CA). If it is already signed by a well-known CA that is in Java's cacerts file, then you don't need to do anything.
Otherwise, you have a couple of options:
Import the certificate into global cacerts keystore
Launch your application with application-specific keystore
In either case, you first need to convert crt file into jks keystore that Java uses. You can do this by:
$ keytool -import -keystore mykeystore.jks -storepass horsestaple
Note that keytool requires the password (horsestaple above) to be supplied for creating a jks store. You can put anything there; as you mention, public website certificates do not need password protection, they are public after all.
If you are doing option 1, make a backup of your cacerts and supply the cacerts file instead of mykeystore.jks. See the link below for the location of cacerts. For this option, you are all set, your application should be connecting to the Web service via HTTPS without any additional configuration, since Java loads cacerts by default.
If you are doing option 2, which is probably preferred at least for testing phase, you need to run your application with this parameter:
-Djavax.net.ssl.trustStore=mykeystore.jks
This is a JVM parameter, so supply it appropriately. This depends on how you are running you application.
Note that you will only have the imported certificate in this case, so your other HTTPS connections will not work. You can avoid this by first copying the standard cacerts to a temporary location, importing the key into it and using that in the command above. That will give you all the standard certificates, plus the one you need.
A slight downside of option 2 is that if new certificates are added or revoked, your application-specific keystore will not be updated. If this is a concern, you can merge keystores on the fly, for example:
Registering multiple keystores in JVM
In either case, you should now be able to just do a standard URL fetch, such as in example given here:
https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https
i.e.:
final URL url = new URL("https://example.com");
try(final InputStream in = url.openStream()){
//…
}
More information here:
Keytool and general certificates info
https://docs.oracle.com/cd/E19830-01/819-4712/ablqw/index.html
Cacerts location
http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html
More options for importing self-signed certificates
How to properly import a selfsigned certificate into Java keystore that is available to all Java applications by default?

Unless they provided you with their .crt file which should be used for validating connections to them, which would indicate they are using a self-signed certificate, they haven't provided you with anything useful. If you need a certificate as a client, the first thing you need is a public/private key pair, from which you generate a CSR, which you get signed. Nobody else can securely provide any of that except the signed certificate.
If they've provided their own (self-signed?) certificate, you need to load it into a truststore, not a keystore, via the keytool with the -trustcacerts option, and then tell Java to use that truststore, either via the javax.net.ssl.trustStore system property or by constructing your own TrustManager and feeding it to a custom SSLContext, as described in the JSSE Reference Guide.

Determining which certificate to use in two way ssl

I'm having an issue sending our certificate (client) to another server during a web service call.
We're expected to return the certificate with the CN:
b2b-test
however whenever we receive the servers certificate and attempt to send our own, we're getting:
Unable to find valid certificate path to requested target
From my understanding, if I put our certificate b2b-test inside of our keystore jre/lib/security/cacerts, then when receiving the server request, it should send the appropriate certificate.
How does the client know which key from the keystore it should send to the server? Should I be specifying the exact certificate to send during my request, or is it enough for it to be in the keystore?
Currently the server is sending back the certificate
b2b-a
The certificate chain shows:
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=b2b-a, OU=Web Technologies
The URL for the service is:
https://b2b-a/service
If I configure it like one way ssl, and put the servers certificate into our cacerts, then it picks up their cert and fails the handshake (I'm assuming because it's expecting our cert and not theirs back due to it being a two way setup).
I'm a little stumped here. Any clarification on what I've said is greatly appreciated.

The "Unable to find valid certificate path to requested target" error usually occurs when one side passes a certificate for which the other side doesn't trust any of the certs in the chain. You'll generally (always?) see the error message on the side that's receiving the cert (the side that's missing the truststore).
If you're the client and they're the server, one-way SSL would send their cert from them to you and you would validate it (making sure that the hostname matches the content in the cert), but it would not send any cert from you to them nor would they do any validation.
You'll want to make sure you're configuring a truststore that contains either the b2b-a certificate or a certificate that was used to sign it (but that cert doesn't appear to have any root CAs, so you're stuck with directly importing the cert itself). So yes, you want to do what you wrote in your post and put their certificate into your cacerts. And you'll also need to make sure that the b2b-a service trusts the cert you're sending (or a root CA that was used to sign your cert, if any), so you'll need to put your cert into their cacerts as well, or do something equivalent.
Note that putting a cert in cacerts (or in a truststore JKS) DOES NOT send any certs to anyone; any truststore is used only to allow you to validate that you trust the certificate someone else provides you, either because you trust the cert or because you trust a CA cert that was used to sign the cert. No certs are picked out of the cacerts directory to send to another machine.
If you're using a JKS rather than the JRE directory (which is generally a better idea, since you can specify a different set of trusted certs for your process without changing the default set for anyone running a Java project within your JRE), it's possible to use the same JKS as both a keystore and a truststore (you'll just provide the same filename and password for both the keystore and the truststore properties), or you can have two separate files; either approach will work.

From my understanding, if I put our certificate b2b-test inside of our keystore jre/lib/security/cacerts, then when receiving the server request, it should send the appropriate certificate.
Certainly not. That's a truststore. A source of trusted certificates. Don't mess with it. It isn't used for the purpose you require and in any case it is updated every Java dot release, which clobbers your changes.
Your own certificate and private/public key pair should go in a file of your own, a keystore, which is defined to JSSE by the javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword system properties, or by more complex means described in the JSSE Reference Guide.
The keystore is a precious and confidential file containing your private key. Guard and protect it. Private key leakage would compromise your security and identity.

Getting Java to accept only one SSL certificate

I've got a java applet that loads some pre-installed native code extensions to display custom content in the browser. Some of this content may include native code to be loaded by the JVM. Obviously, this is a security concern. I'd like to enforce that all content comes only from authorized servers.
The path I've been following to accomplish this is to create a keystore that contains just one SSL certificate. I set the keystore location and password and turned on debug output.
System.setProperty("javax.net.ssl.keyStore", "C:\\keys\\keystore");
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");
System.setProperty("javax.net.debug", "ssl");
I was under the impression that this would mean that the JVM would have access to only the one keystore file and consequently the one key inside it. In fact, the SSL debug info lists something like 75 CA keys in addition to the one key I added. Clearly, this isn't going to keep anyone from sending us untrusted code.
Is there a way to tell the SSL system to only use a single certificate? Should I be using a completely different approach?
Update:
Changing the cacerts file isn't really an option here. The JVM should continue to function normally for other applications using it. Is there a way, at runtime, to elect not to load that file? I'm looking at the TrustManager and KeyManager classes but I don't really understand how to use them.

You need to set the javax.net.ssl.trustStore system property to point to a keystore with your one certificate in it. The keystore is for your authentication credentials, not your peer's.

The very question is wrong here. A certificate is only a proof of identity. You don't authorize certificates, you authorize identities. What if the same client comes up with a new certificate?
The correct answer is to install a HandshakeCompletedListener that checks the peer identity. The truststore is only there for authentication, i.e. is that person who they said they were. What you are doing is authorization, which is a different thing completely. You shouldn't use the truststore (or any PKI mechanism) for authorization.

You also have the global keystore installed with the JRE, which is where all the CA's are stored. Try to rename it and see what happens.

You still "see" the CA certificates of the system-wide JRE cacerts file located in java.home/jre/lib/security, which is normal.
Now, quoting the keytool documentation about this file:
IMPORTANT: Verify Your cacerts File
Since you trust the CAs in
the cacerts file as entities for
signing and issuing certificates to
other entities, you must manage the
cacerts file carefully. The cacerts
file should contain only certificates
of the CAs you trust. It is your
responsibility to verify the trusted
root CA certificates bundled in the
cacerts file and make your own trust
decisions. To remove an untrusted CA
certificate from the cacerts file, use
the delete option of the keytool
command. You can find the cacerts file
in the JRE installation directory.
Contact your system administrator if
you do not have permission to edit
this file.
In your case, it might be easier to entirely replace the cacerts with your own key store instead of removing all 75 entries if this is really what you want. If not, then you should use a different approach indeed (why don't you just restrict or hard code the list of authorized servers?).