GKE上WSO2 API管理集成Cert-Manager获证失败：显示假证书

Let's break down why your WSO2 APIM ingress is returning the Kubernetes Ingress Controller's fake certificate while your HelloWorld app works fine, and walk through actionable fixes:

Key Observations from Your Configs #

First, comparing your two ingress resources, the most critical difference is:

• Namespace Isolation: Your HelloWorld app lives in the default namespace, while WSO2 APIM is deployed in wso2-apim.
• Issuer Scope: If you created a regular Issuer (not ClusterIssuer) named letsencrypt-production, it’s namespace-scoped—meaning it only works within the namespace it was created in (likely default for your HelloWorld app). The WSO2 APIM ingress in wso2-apim can’t access this issuer, so Cert-Manager can’t generate a valid certificate, forcing the ingress controller to fall back to its default fake cert.

Step-by-Step Troubleshooting & Fixes #

1. Verify Certificate Resource Status #

First, check if the certificate for your WSO2 APIM host was actually created and is in a Ready state:

kubectl get certificates -n wso2-apim

• If am-japangly-xyz-tls doesn’t exist or shows a status other than Ready, that’s the immediate root cause.

2. Fix the Issuer Scope Issue #

You have two ways to resolve the cross-namespace issuer access problem:

Option A: Switch to a ClusterIssuer

ClusterIssuers work across all namespaces in your cluster. If you originally used an Issuer, redefine it as a ClusterIssuer (your existing ingress annotation cert-manager.io/issuer will work with both types as long as the name matches).

Option B: Create a Duplicate Issuer in the WSO2 APIM Namespace

Copy your existing letsencrypt-production Issuer YAML, update the namespace to wso2-apim, then apply it:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-production
  namespace: wso2-apim
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your-email@example.com # Replace with your actual email
    privateKeySecretRef:
      name: letsencrypt-production
    solvers:
    - http01:
        ingress:
          class: nginx

Apply the file with:

kubectl apply -f wso2-apim-issuer.yaml

3. Inspect Cert-Manager Logs for Specific Errors #

If the certificate still isn’t ready, check Cert-Manager logs to pinpoint issues like DNS validation failures or permission errors:

kubectl logs -n cert-manager $(kubectl get pods -n cert-manager -l app=cert-manager -o name)

Look for entries related to am-japangly-xyz-tls—this will tell you exactly why certificate issuance failed.

4. Validate Ingress TLS Configuration #

Double-check your WSO2 APIM ingress TLS section:

• Ensure the hosts value exactly matches your domain (am.japangly.xyz).
• Ensure the secretName (am-japangly-xyz-tls) matches what Cert-Manager is configured to create.

5. Force Nginx Ingress Controller to Reload Config #

After fixing the issuer and getting a ready certificate, verify Nginx is using the correct cert:

kubectl exec -n ingress-nginx $(kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=nginx-ingress -o name) -- cat /etc/nginx/nginx.conf | grep -A 10 am.japangly.xyz

If you don’t see a reference to the TLS secret in the wso2-apim namespace, delete and reapply the ingress to trigger a config reload:

kubectl delete ingress wso2am-pattern-1-am-ingress -n wso2-apim
kubectl apply -f wso2am-pattern-1-am-ingress.yaml

内容的提问来源于stack exchange，提问作者Japang LY