<p>My kubernetes ingress is not accepting the self signed certificate and instead when opening the url on firefox the <strong>Kubernetes Ingress Controller Fake Certificate</strong> is added.</p>
<blockquote>
<p>All the things done locally on pc with minikube in Kali Linus. Kali
linus is running in a Virtual Machine by VMWare software.The doc which
I am referring is -
<a href="https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl" rel="nofollow noreferrer">https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl</a></p>
</blockquote>
<p>The Ingress Yaml file.</p>
<pre><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: first-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/force-ssl-redirect: &quot;true&quot;
    nginx.ingress.kubernetes.io/ssl-redirect: &quot;true&quot;
spec:
  tls:
  - hosts:
      - example.com
    secretName: myssl
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: first-service
            port:
              number: 8080
</code></pre>
<p>The &quot;192.168.49.2&quot; is the ingress ip address. So <a href="https://192.68.49.2" rel="nofollow noreferrer">https://192.68.49.2</a> opens my app on the browser.</p>
<p>The certificate is generated with Openssl with the following commands:</p>
<pre><code>openssl genrsa -out s.key 2048
openssl req -new -key s.key -out s.csr -subj &quot;/CN=example.com&quot;
openssl x509 -req -days 365 -in s.csr -signkey s.key -out s.crt
</code></pre>
<p>The certificate is added to k8s secret.</p>
<pre><code>kubectl create secret tls myssl --cert s.crt --key s.key
</code></pre>
<p>The <code>curl -kv https://192.168.49.2</code> command output is:</p>
<pre><code>* Trying 192.168.49.2:443...
* Connected to 192.168.49.2 (192.168.49.2) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: O=Acme Co; CN=Kubernetes Ingress Controller Fake Certificate
*  start date: Oct 22 09:57:19 2022 GMT
*  expire date: Oct 22 09:57:19 2023 GMT
*  issuer: O=Acme Co; CN=Kubernetes Ingress Controller Fake Certificate
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: 192.168.49.2]
* h2h3 [user-agent: curl/7.85.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x561c242ff950)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
&gt; GET / HTTP/2
&gt; Host: 192.168.49.2
&gt; user-agent: curl/7.85.0
&gt; accept: */*
&gt; 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
&lt; HTTP/2 200 
&lt; date: Sat, 22 Oct 2022 10:05:50 GMT
&lt; content-type: text/html; charset=utf-8
 ..... html of the page
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection #0 to host 192.168.49.2 left intact
</code></pre>
<p>Kindly help.</p>
<p><strong>Update 2 days Later:</strong></p>
<p>I debugged and found I have installed nginx ingress with the command:</p>
<pre><code>minikube addons enable ingress
</code></pre>
<p>It installs the ingress in <code>ingress-nginx</code> namespace while my secret is in <code>default</code> namespace. Can this be the problem, if so what is the solution?</p>

yogihosting
<p>You have an error in your ingress manifest, here:</p>
<pre><code>rules:
- host: example.com
- http:
    paths:
</code></pre>
<p>You have created two rules, the first matches <code>host: example.com</code> but defines no paths or backends; the second matches path <code>/</code> but doesn't set a <code>host</code>. You want:</p>
<pre><code>rules:
- host: example.com
  http:
    paths:
</code></pre>
<hr />
<blockquote>
<p>It installs the ingress in ingress-nginx namespace while my secret is in default namespace. Can this be the problem, if so what is the solution?</p>
</blockquote>
<p>This is not a problem: it is the expected configuration. Your SSL secrets should be installed in the same namespace as your application and Ingress.</p>
<hr />
<p>I've been playing with this a bit over the past couple of days, and I'm not sure you can get this to operate the way you want without using a hostname. Fortunately, setting up a hostname to use during local development is relatively straightforward.</p>
<p>In most cases you can edit your <code>/etc/hosts</code> file. For example, if your application is hosted on 192.168.49.2, then you would add an entry like this to <code>/etc/hosts</code> to access your application at <code>https://example.com</code>:</p>
<pre><code>192.168.49.2    example.com
</code></pre>
<p>You can add multiple hostname aliases, which allows you to use multiple hostname-based Ingress resources on your cluster:</p>
<pre><code>192.168.49.2    example.com myapp.internal anotherapp.dev
</code></pre>
<p>When you're testing with <code>curl</code>, you can use the <code>--resolve</code> option to accomplish the same thing:</p>
<pre><code>curl --resolve example.com:443:192.168.49.2 -kv https://example.com
</code></pre>
<p>So for example, if I deploy the following Ingress on my local cluster:</p>
<pre><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami
spec:
  tls:
    - secretName: myssl
      hosts:
        - example.com
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: whoami
                port:
                  name: http
</code></pre>
<p>With the following entry in <code>/etc/hosts</code>:</p>
<pre><code>$ grep example.com /etc/hosts
193.168.1.200 example.com
</code></pre>
<p>Running <code>curl -skv https://example.com</code> shows that the ingress is using my custom certificate rather than the default ingress certificate:</p>
<pre><code>[...]
* Server certificate:
*  subject: CN=example.com
*  start date: Oct 23 12:52:45 2022 GMT
*  expire date: Oct 23 12:52:45 2023 GMT
*  issuer: CN=example.com
[...]
</code></pre>
