Hands-On Cryptography with Java—AppendicesRussell Bateman |
The course mostly concentrated on how to interact with the keystore programmatically. Though interesting, this isn't what I need right now. Instead, this is me augmenting the course.
The Java keystore is a file—repository for one or more private keys, certificates containing public keys or just secret keys that can be used for various cryptological purposes. Each entity within is stored by an alias for easy look-up.
The best example of a server in Java-land would be Tomcat. Think of Tomcat in what follows.
A server that wants to use HTTPS presents its public key and certificate to clients. (Client authentication interests me not at all, so I will not elaborate here.)
There is no default Java keystore. For this reason the following must be set in the JVM:
where:
This is a topic that got practically zero coverage in the course.
The Java trust store is also a file. It is the opposite of the keystore: while a keystore holds certificates that identify (a "first person"), the trust store holds certificates that identify others.
In Java, the trust store contents are used to determine whether to trust the third party being communicated with. This trust store is like the store operating systems and browsers ship with containing myriad certificates that can be found in legitimate certificate authority (CA) chains.
A server can get a public key and certificate from its own keystore to present to a client requesting its services.
The client then looks up the certificate in his own trust store.
Don't mistake the client for a human being: the client is software—a browser, curl or something else like NiFi InvokeHTTP over which the human user may not have "do it anyway" control (as he does in the browser or when running curl).
This means that the certificate presented by the server must either already exist in the client's trust store or a certificate authority (CA) in the chain of authority in the server's certificate.
When a server has a self-signed certificate—with no acceptable, publicly known and trusted authority (CA), the client will not be able (allowed) to trust the server, the client JVM will throw SSLHandshakeException and fail the connection.
Java has bundled with it a trust store named cacerts on the path ${JAVA_HOME}/lib/security 1 2 that contains default, trusted certificate authorities (CA) just as operating systems and browsers do. This is what the JVM gets by default when it runs. For instance, ...
russ@tirion /etc/ssl/certs/java $ keytool -list -cacerts Enter keystore password: changeit Keystore type: JKS Keystore provider: SUN Your keystore contains 139 entries debian:ac_raiz_fnmt-rcm.pem, Jan 3, 2021, trustedCertEntry, Certificate fingerprint (SHA-256): EB:C5:57:0C:29:01:8C:4D:67:B1:AA:12:7B:AF:12:F7:03:B4:61:1E:BC:17:B7:DA:B5:57:38:94:17:9B:93:FA ...
If the server has a self-signed certificate, it is likely not among the 139 entries in cacerts nor does it include a chain among which is included a root certificate in those entries.
Therefore, the client will have to add—by hand—the server's self-signed certificate to his trust store (as an addition to the JVM's trust store, cacerts) in order to inform applications, such as a browser, curl or other software, that the server can be trusted.
Adding a self-signed certificate to Java's trust store is a "baling-wire and twine" method of getting authentic, commercial sign-off on the server's self-signed certificate for the client that adds it. It makes the server appear legitimate. For example, this is done:
$ keytool -import -trustcacerts -alias tomcat -file tomcat.crt -keystore cacerts
where tomcat.crt is the self-signed certificate (we're thinking about a Tomcat microservice here) and cacerts is the cacerts active in the client software's running JVM (${JAVA_HOME}/lib/security/cacerts) or supplied to that JVM by launching it with:
1 Before Java 9, this path was ${JAVA_HOME}/jre/lib/security.
2 cacerts is often not very mysterious. In a JDK, it's a shipping file on the path noted above, but formally installed as a JRE—for example, on Ubuntu and Mint—it ends up a very pedestrian location indeed, not far from where the operating system keeps its pile of trusted certificates:
root@tirion:# which java /usr/bin/java root@tirion:/home/russ# cd /usr/bin/ root@tirion:/usr/bin# ll -d java lrwxrwxrwx 1 root root 22 Jan 28 2021 java -> /etc/alternatives/java* root@tirion:/usr/bin# cd /etc/alternatives root@tirion:/etc/alternatives# ll -d java lrwxrwxrwx 1 root root 43 Jan 28 2021 java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java* root@tirion:/etc/alternatives# cd /usr/lib/jvm/java-11-openjdk-amd64/ root@tirion:/usr/lib/jvm/java-11-openjdk-amd64# ll -d lib/security/cacerts lrwxrwxrwx 1 root root 27 Jul 22 03:14 lib/security/cacerts -> /etc/ssl/certs/java/cacerts
As implied in the note just above, Linux keeps its list of trusted certificates on the path /etc/ssl/certs.
This is me more repeating details that the course discussed early on.
The major root certificate stores are Apple, Microsoft, Mozilla and Android (Google). When you visit a website, it presents a certificate that's signed by another certificate, which is signed by another certificate—and so on up a chain until you reach one of the certificates in the browser's store.
Each certificate store has its own requirements for a certificate authority (CA) to get added, however, they all require passing WebTrust for Certification Authorities, an audited assurance process for policies and procedures that verify identity, issue certificates, handle keys, etc.
Firefox is a good example of how to see the certificates it trusts. In Firefox 103, follow this path:
Once upon a time, you could bring up Chrome on google.com, launch Developer Tools, click the Security tab, then View Certificate to show details about google.com's certificate. There you would learn of...
This is a simple example since many websites have more than one intermediate certificate in their chain before reaching a root certificate.
At that time, Chrome shipped with (at least) the root certificate that google.com and a lot of other websites' certificate chains would lead to.
...and resources to answer them.
Don't import (certificates) into cacerts unless you really need to do this (because you have an internal CA within your organization). Importing the domain's certificate into cacerts is almost always the wrong solution. Just because it works doesn't mean it should be done.
Importing a certificate into cacerts says that this certificate is a trusted certificate authority.
This is a pretty common exception when connecting to an HTTPS server. Reasons it could happen:
If you are using an internal certficiate authority and a self-signed certificate, then you should import your internal CA certificate into cacerts. (This is not ideal.) This makes you a certificate authority, but your authority doesn't hold for anyone else.
import java.net.URL;
import java.io.*;
import javax.net.ssl.HttpsURLConnection;
public class JavaHttpsExample
{
public static void main(String[] args) throws Exception
{
final String HTTPS_URL = "https://your.https.url.here/";
URL url = new URL( HTTPS_URL );
HttpsURLConnection connection = ( HttpsURLConnection ) url.openConnection();
BufferedReader reader = new BufferedReader( new InputStreamReader( connection.getInputStream() ) );
String line;
while( ( line = reader.readLine() ) != null )
System.out.println( line );
br.close();
}
}
Fill in SERVER_URL, ALIAS_NAME and CERT_NAME.
This will create a trusted (JKS) store by the name of CERT_NAME containing a certficate of the server's URL. To add this certificate to cacerts, replace ${CERT_NAME}.jks with cacerts.
# parameters
SERVER_URL=serverhost:serverport
ALIAS_NAME=your_alias
CERT_NAME=trust
# action
openssl s_client -showcerts -connect ${SERVER_URL} < /dev/null 2 > /dev/null|openssl x509 -outform PEM > ${CERT_NAME}.pem
openssl x509 -outform der -in ${CERT_NAME}.pem -out ${CERT_NAME}.der
keytool -import -alias ${ALIAS_NAME} -keystore ${CERT_NAME}.jks -file ${CERT_NAME}.der
One reason for this deprecation is the ambiguity and lack of type of CN since, by usage, it's sometimes a domain name (like windofkeltia.com) instead of a human name (person, place or thing).
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: \
No subject alternative names matching IP address 192.168.178.71 found
will occur when the certificate isn't created with
192.168.178.71 in mind. DNS become very important since no one
really wants to hard-code an IP address in a certificate. (localhost
isn't much better, but we'll use it in examples in place of making up a
DNS name.)
$ keytool -genkeypair -keyalg RSA -validity 365 \
-keystore server.jks -storepass changeit -deststorestype pkcs12 \
-dname "CN=darren-server," -ext "SAN=IP:10.10.10.73"
$ openssl req -newkey rsa:2048 -nodes -config san.conf -keyout private.key -out server.csr
where san.conf might appear:
[ req ] default_bits = 2048 distinguished_name = req_distinguished_name req_extensions = req_ext [ req_distinguished_name ] countryName = US stateOrProvinceName = UT localityName = Provo commonName = windofkeltia.com [ req_ext ] subjectAltName = @alt_names [alt_names] DNS.1 = nargothrond.com DNS.2 = tirion.com DNS.3 = alqualondë.com
$ openssl s_client -connect localhost:8443 -showcerts (displays a certificate) $ vim trust.crt (copy and paste into it everything between the displayed begin header and end foot inclusive) $ openssl x509 -in trust.crt -text $ keytool -importcert -keystore trust.jks -file trust.crt -keypass changeit -storepass changeit -alias tomcat -noprompt
Note -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true, but this check (i.e.: don't disable) is preventing man-in-the-middle attacks on secure connections and the vulnerability of connecting to the wrong site. Disabling certificate validation is only wise in a development environment.
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.net.URL;
import java.security.KeyManagementException;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.cert.Certificate;
import java.security.cert.CertificateException;
import java.security.cert.CertificateFactory;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;
public void createTrustStore( final String url )
throws KeyManagementException, KeyStoreException, CertificateException, IOException, NoSuchAlgorithmException
{
File file = new File( "server.crt" );
Certificate certificate = CertificateFactory.getInstance( "X.509").generateCertificate( new FileInputStream( file ) );
// or if the crt-file is packaged inside a JAR file:
// CertificateFactory.getInstance( "X.509" ).generateCertificate( this.class.getClassLoader().getResourceAsStream( "server.crt" ) );
KeyStore keyStore = KeyStore.getInstance( KeyStore.getDefaultType() );
keyStore.load( null, null );
keyStore.setCertificateEntry( "server", certificate );
TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance( TrustManagerFactory.getDefaultAlgorithm() );
trustManagerFactory.init( keyStore );
SSLContext sslContext = SSLContext.getInstance( "TLS" );
sslContext.init( null, trustManagerFactory.getTrustManagers(), null );
HttpsURLConnection connection = ( HttpsURLConnection ) new URL( url ).openConnection();
connection.setSSLSocketFactory( sslContext.getSocketFactory() );
}