<p>So I'm trying to add an ssl certificate for my project, on my local machine I was able to add it by simply following a keytool command and then it worked. But when I try to do the same on the machine that has my k8s cluster, it doesn't seem to work whatsoever.</p>
<p>I saw a couple of people adding the cer to cacerts in their docker file but I don't have one as i'm using google's Jib so I'm not sure how it's supposed to go from here, or is it a configuration I should add to my k8s deployment file?</p>

Ali_Nass
<h3>Background</h3>
<p>Here I assume that your application being deployed to Kubernetes is connecting to an external server protected by its server certificate outside Kubernetes. For example, like the case in <a href="https://medium.com/@paraspatidar/add-self-signed-or-ca-root-certificate-in-kubernetes-pod-ca-root-certificate-store-cb7863cb3f87" rel="noreferrer">this article</a>.</p>
<p>Inasmuch as can be seen in the link above, there are really multiple ways to resolve this. However, note the methods explained in the article are not really applicable to Java as-is, because Java <a href="https://www.benecke.cloud/java-runtime-environment-jre-how-to-import-certificates/" rel="noreferrer">doesn't make use of the system CA cert store from the OS but uses its own truststore</a>:</p>
<blockquote>
<p>Instead of using the windows certificate store it uses its own implementation. Java certificates are stored in a file called <code>cacerts</code> located at <code>C:\Program Files (x86)\Java\jre1.x.x_xxx\lib\security\</code></p>
</blockquote>
<p>Because you said you successfully used keytool locally, I assume you are already aware of this Java behavior and where your server certificate should be imported into–that is, into the JRE's default <code>cacerts</code> file under the JRE directory (unless you use some system property to tell the JVM to find a CA truststore at a different location). Since you said you made it work locally, theoretically you can follow the same and it should work on Kubernetes too.</p>
<hr />
<h3>Embedding <code>cacerts</code> at build time</h3>
<p>One straightforward way is to bake your cert into your image at image build time (as you hinted with the <code>Dockerfile</code> approach). For this purpose, you can use Jib's <code>&lt;extraDirectories&gt;</code> feature to copy arbitrary files into an image (usage: <a href="https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#adding-arbitrary-files-to-the-image" rel="noreferrer">Maven</a> / <a href="https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#adding-arbitrary-files-to-the-image" rel="noreferrer">Gradle</a>). Just prepare a new <code>cacerts</code> file and place it into the JRE's default location in the image.</p>
<h3>Supplying <code>cacerts</code> at runtime</h3>
<p>If you don't like the idea of baking a cert into the image but rather want to supply it at runtime, I believe you can basically follow the last method described in the article I linked above (although for Java, you should put <code>cacerts</code> instead, of course). I am not a Kubernetes expert in this domain and unsure if Kubrenetes provides another dedicated solution, but the method in the article seems reasonable and should work.</p>
<p>For container runtimes other than Kubernetes, all of them will have their own way of supplying files or attaching volumes at runtime, so you should be able to achieve the same goal.</p>
<hr />
<p><strong>UPDATE</strong>: on many Linux distros, often <code>&lt;JRE&gt;/lib/security/cacerts</code> is a symlink to <code>/etc/ssl/certs/java/cacerts</code>, so you may opt to update the latter instead of the former.</p>
<pre><code># ls -l /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts
lrwxrwxrwx    1 root     root            27 Jan  1  1970 /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts -&gt; /etc/ssl/certs/java/cacerts
</code></pre>
