<p>I'm trying to setup TLS for a service that's available outside a Kubernetes cluster (AWS EKS). With cert-manager, I've successfully issued a certificate and configured ingress, but I'm still getting error <code>NET::ERR_CERT_AUTHORITY_INVALID</code>. Here's what I have:</p>
<ol>
<li><p><strong>namespace</strong> <code>tests</code> and <code>hello-kubernetes</code> in it (both <strong>deployment and service</strong> have name <code>hello-kubernetes-first</code>, serivce is ClusterIP with <code>port</code> 80 and <code>targetPort</code> 8080, deployment is based on <code>paulbouwer/hello-kubernetes:1.8</code>, see details in my <a href="https://stackoverflow.com/q/69888157/3995261">previous question</a>)</p>
</li>
<li><p><strong>DNS and ingress</strong> configured to show the service:</p>
<pre><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-kubernetes-ingress
  namespace: tests
spec:
  ingressClassName: nginx
  rules:
  - host: test3.projectname.org
    http:
      paths:
      - path: &quot;/&quot;
        pathType: Prefix
        backend:
          service:
            name: hello-kubernetes-first
            port:
              number: 80
</code></pre>
<p>Without configuring TLS, I can access test3.projectname.org via http and see the service (well, it tries to redirect me to https, I see <code>NET::ERR_CERT_AUTHORITY_INVALID</code>, I go to insecure anyway and see the hello-kubernetes page).</p>
<ul>
<li><p>note: I have nginx-ingress <strong>ingress controller</strong>; it was installed before me via the following chart:</p>
<pre><code>apiVersion: v2
name: nginx
description: A Helm chart for Kubernetes
type: application
version: 4.0.6
appVersion: &quot;1.0.4&quot;
dependencies:
- name: ingress-nginx
  version: 4.0.6
  repository: https://kubernetes.github.io/ingress-nginx
</code></pre>
<p>and the values overwrites applied with the chart differ from the <a href="https://github.com/kubernetes/ingress-nginx/blob/main/charts/ingress-nginx/values.yaml" rel="nofollow noreferrer">original ones</a> mostly in <code>extraArgs</code>: <code>default-ssl-certificate: &quot;nginx-ingress/dragon-family-com&quot;</code> is uncommneted</p>
</li>
</ul>
</li>
<li><p><strong>cert-manager</strong> installed via <code>kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.4/cert-manager.yaml</code></p>
</li>
<li><p><strong>ClusterIssuer</strong> created with the following config:</p>
<pre><code>apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-backoffice
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # use https://acme-v02.api.letsencrypt.org/directory after everything is fixed and works
    privateKeySecretRef: # this secret is created in the namespace of cert-manager
      name: letsencrypt-backoffice-private-key
    # email: &lt;will be used for urgent alerts about expiration etc&gt;

    solvers:
    # TODO: add for each domain/second-level domain/*.projectname.org
    - selector:
        dnsZones:
          - test.projectname.org
          - test2.projectname.org
          - test3.projectname.org
      http01:
        ingress:
          class: nginx
</code></pre>
</li>
<li><p><strong>certificate</strong> in the <code>tests</code> namespace. It's config is</p>
<pre><code>apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: letsencrypt-certificate-31
  namespace: tests
spec:
  secretName: tls-secret-31
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt-backoffice
  commonName: test3.projectname.org
  dnsNames:
  - test3.projectname.org
</code></pre>
</li>
</ol>
<p>Now, certificate is ready (<code>kubectl get certificates -n tests</code> tells that) and to apply it, I add this to ingress's spec:</p>
<pre><code>  tls:
    - hosts:
      - test3.projectname.org
      secretName: tls-secret-31
</code></pre>
<p>However, when I try to open test3.projectname.org via https, it still shows me the <code>NET::ERR_CERT_AUTHORITY_INVALID</code> error. <strong>What am I doing wrong? How to debug this?</strong> I've checked up <code>openssl s_client -connect test3.projectname.org:443 -prexit</code><a href="https://stackoverflow.com/a/22814663/3995261">*</a> and it shows the following chain:</p>
<pre><code> 0 s:CN = test3.projectname.org
   i:C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
 1 s:C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
   i:C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
 2 s:C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
   i:C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
</code></pre>
<p>and tells, among other output</p>
<blockquote>
<p>Verification error: unable to get local issuer certificate</p>
</blockquote>
<p>Unfortunately, I haven't found anything useful to try further, so any help is appreciated.</p>

<p>Your ClusterIssuer refers to LetsEncrypt staging issuer. Remove that setting / the default should use their production setup. As pointed out in comments: <a href="https://acme-v02.api.letsencrypt.org/directory" rel="nofollow noreferrer">https://acme-v02.api.letsencrypt.org/directory</a></p>
<p>Deleting the previously generated secrets or switching to new secrets should ensure your certificates would be re-generated, using the right issuer.</p>
<p>The staging issuer could be useful testing LetsEncrypt integration, it shouldn't be used otherwise.</p>
