From b0a48379a1ad4a4ed8033e33807a3b9b6d20170d Mon Sep 17 00:00:00 2001 From: "R. Tyler Croy" Date: Sat, 28 Sep 2019 12:39:35 -0700 Subject: [PATCH] Document some of my certificate shenanigans from Friday --- ...2019-04-25-custom-certificates-minikube.md | 1 + _posts/2019-09-28-jks-jfc.md | 64 +++++++++++++++++++ 2 files changed, 65 insertions(+) create mode 100644 _posts/2019-09-28-jks-jfc.md diff --git a/_posts/2019-04-25-custom-certificates-minikube.md b/_posts/2019-04-25-custom-certificates-minikube.md index 316d65b..23e8899 100644 --- a/_posts/2019-04-25-custom-certificates-minikube.md +++ b/_posts/2019-04-25-custom-certificates-minikube.md @@ -4,6 +4,7 @@ title: Using custom root certificates with Minikube tags: - kubernetes - scribd +- minikube --- If you were to draw a coordinate system for software, where the x-axis was diff --git a/_posts/2019-09-28-jks-jfc.md b/_posts/2019-09-28-jks-jfc.md new file mode 100644 index 0000000..2d768c4 --- /dev/null +++ b/_posts/2019-09-28-jks-jfc.md @@ -0,0 +1,64 @@ +--- +layout: post +title: "JKS? jfc. Adding a root certificate" +tags: +- security +- tls +- java +- scribd +--- + + +TLS certificates have the largest "complexity/importance" scores imaginable. +Everything about them is error prone and seemingly over-engineered from top to +bottom, yet they are one of the most important pieces of security and +authentication in our software architectures. From an engineering management +standpoint, I am finding myself adopting the rule of: estimates for any project +involving certificates should be multiplied tenfold. If the project involves +the Java Virtual Machine (JVM) and the Java Key Store (JKS), multiply by +another ten I suppose. For my own future convenience, in this blog post I would +like to outline how to add a root certificate to a Java Key Store in Red +Hat-derived environments. + + +Like many corporate environments, we have our own internal Certificate +Authorities (CAs) which all derive their chain of trust from our internal root +certificate. Accessing internal services requires that the operating system has +that root certificate, or when accessing those internal services from anything +running atop the JVM, the default JKS must have the root certificate. + +If you search around the web for how to add root certificates, you might find +the `update-ca-certificates` command, whose CentOS/RHEl manpage has the +following: + + + The directory /etc/pki/ca-trust/extracted/java/ contains a CA + certificate bundle in the java keystore file format. Distrust information + cannot be represented in this file format, and distrusted certificates are + missing from these files. File cacerts contains CA certificates trusted for TLS + server authentication. + +You might assume, as I did, that this means the `update-ca-certificates` tool +is going to create files that the JVM picks up properly and your default JKS +will have the root certificate in place. + +This is _false_. At least in the environments which I have tested this. + + +Digging further I found [this blog post](https://connect2id.com/blog/importing-ca-root-cert-into-jvm-trust-store) and used the following command to import the root certificate into JKS after installing it on the system at large: + + keytool -importcert -alias startssl -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -file ca.der + +Using the SSLPoke tool referenced in [this Atlassian knowledgebase +article](https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-779355358.html) +I was then _finally_ able to access the same internal services from native +utilities (e.g. `curl`) and from the Java-based services which I was working +with at the time. + +In my situation, the fact that all of this was happening within Docker +containers further complicated the debugging: multiple by another 2-5 on that +engineering estimate. + + +Certificates are too important to be this painful. +