Document some of my certificate shenanigans from Friday

_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

_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.
+