颁发证书为“秘密”不存在

时间：2020-08-10 19:23:49

标签： google-kubernetes-engine cert-manager

以下是我的describe和clusterissuer资源的certificate输出。我是cert-manager的新手，因此不能100％地确保此设置正确-我们需要使用http01验证，但是我们没有使用nginx控制器。目前，我们只有2个微服务，因此面向公众的IP地址仅属于k8s服务（类型loadbalancer），该服务将流量路由到Pod，其中Extensible Service Proxy容器位于运行应用程序代码的容器前面。使用此设置，我无法获得以下错误之外的任何信息，但是正如我提到的，我是cert-manager＆ESP的全新用户，因此此配置可能不正确... 

Name:         clusterissuer-dev
Namespace:    
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
API Version:  cert-manager.io/v1beta1
Kind:         ClusterIssuer
Metadata:
  Creation Timestamp:  2020-08-07T18:46:29Z
  Generation:          1
  Resource Version:    4550439
  Self Link:           /apis/cert-manager.io/v1beta1/clusterissuers/clusterissuer-dev
  UID:                 65933d87-1893-49af-b90e-172919a18534
Spec:
  Acme:
    Email:  email@test.com
    Private Key Secret Ref:
      Name:  letsencrypt-dev
    Server:  https://acme-staging-v02.api.letsencrypt.org/directory
    Solvers:
      http01:
        Ingress:
          Class:  nginx
Status:
  Acme:
    Last Registered Email:  email@test.com
    Uri:                    https://acme-staging-v02.api.letsencrypt.org/acme/acct/15057658
  Conditions:
    Last Transition Time:  2020-08-07T18:46:30Z
    Message:               The ACME account was registered with the ACME server
    Reason:                ACMEAccountRegistered
    Status:                True
    Type:                  Ready
Events:                    <none>


Name:         test-cert-default-ns
Namespace:    default
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
API Version:  cert-manager.io/v1beta1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2020-08-10T15:05:31Z
  Generation:          2
  Resource Version:    5961064
  Self Link:           /apis/cert-manager.io/v1beta1/namespaces/default/certificates/test-cert-default-ns
  UID:                 259f62e0-b272-47d6-b70e-dbcb7b4ed21b
Spec:
  Dns Names:
    dev.test.com
  Issuer Ref:
    Name:       clusterissuer-dev
  Secret Name:  clusterissuer-dev-tls
Status:
  Conditions:
    Last Transition Time:        2020-08-10T15:05:31Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
    Last Transition Time:        2020-08-10T15:05:31Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
  Next Private Key Secret Name:  test-cert-default-ns-rrl7j
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Requested  2m51s  cert-manager  Created new CertificateRequest resource "test-cert-default-ns-c4wxd"

最后一项-如果运行命令kubectl get certificate -o wide，则会得到以下输出。

  NAME                           READY   SECRET                         ISSUER                     STATUS                                         AGE
  test-cert-default-ns           False   clusterissuer-dev-tls          clusterissuer-dev          Issuing certificate as Secret does not exist   2d23h

2 个答案:

答案 0 :(得分：5)

我遇到了同样的问题，我遵循了@Popopame 在评论中给出的建议，建议查看 troubleshooting guide of cert-manager 以了解如何对证书管理器进行故障排除。或 [cert-managers acme 问题故障排除指南] 以找出 acme 过程的哪一部分破坏了设置。

这似乎是一个极端的挑战，letencrypt 通过请求在特定路径的端口 80 上提供特定代码来验证域所有权。例如：http://example.com/.well-known/acme-challenge/M8iYs4tG6gM-B8NHuraXRL31oRtcE4MtUxRFuH8qJmY。请注意，显示 letencrypt 的 http:// 将尝试验证所需域的端口 80 上的域所有权。

所以常见的错误之一是，证书管理器无法将正确的挑战放在端口 80 后面的正确路径中。例如，由于防火墙阻止了裸机服务器上的端口 80 或仅转发端口的负载均衡器443到kubernetes集群，直接重定向到443。

另请注意，cert-manager 也会尝试验证 ACME 质询，因此您应该配置防火墙以允许来自您的服务器的请求。

如果您在将证书获取到不同的命名空间时遇到问题，this 将是一个很好的起点。

在您的具体情况下，我猜测 ACME 挑战存在问题，因为 CSR（证书签名请求）是按照最底部的描述行所示创建的，但没有其他任何事情发生。

答案 1 :(得分：2)

1.使用 Helm 进行设置

到目前为止，我发现的最简单的方法是使用 helm v3 来安装 cert-manager。我能够在 k3s 集群上设置它，如下所示：

$   helm repo add jetstack https://charts.jetstack.io
$   helm repo update
$   helm install \
        cert-manager jetstack/cert-manager \
        --namespace cert-manager \
        --version v1.2.0 \
        --create-namespace \
        --set installCRDs=true

2.设置 ClusterIssuer

安装后，您需要创建一个 ClusterIssuer，然后可以在从 let's encrypt 请求证书时使用它。

$ more cert-clusterissuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-stg
  namespace: cert-manager
spec:
  acme:
    email: my_letsencrypt_email@mydom.com
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource that will be used to store the account's private key.
      name: le-issuer-acct-key
    solvers:
    - dns01:
        cloudflare:
          email: my_cloudflare_email@mydom.com
          apiTokenSecretRef:
            name: cloudflare-api-token-secret
            key: api-token
      selector:
        dnsZones:
        - 'mydomdom.org'
        - '*.mydomdom.org'

部署它，注意它将被部署到与 cert-manager 相同的命名空间中：

$ kubectl apply -f cert-clusterissuer.yaml

$ kubectl -n cert-manager get clusterissuers
NAME              READY   AGE
letsencrypt-stg   True    53m

3.设置 Cloudflare API 令牌密钥

将您的 Cloudflare API 令牌部署到密钥中，再次将其放入 cert-manager 命名空间：

$ more cloudflare-api-token.yaml
apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-api-token-secret
  namespace: cert-manager
type: Opaque
stringData:
  api-token: <my cloudflare api token key>

$ kubectl -n cert-manager -f cloudflare-api-token.yaml

4.创建测试证书

现在尝试从 let's encrypt 请求生成证书：

$ more test-certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: le-test-mydomdom-org
  namespace: cert-manager
spec:
  secretName: le-test-mydomdom-org
  issuerRef:
    name: letsencrypt-stg
    kind: ClusterIssuer
  commonName: 'le-test.mydomdom.org'
  dnsNames:
  - "le-test.mydomdom.org"

$ kubectl -n cert-manager apply -f test-certificate.yaml

5.调试证书创建

然后，您可以在请求流经各个阶段时对其进行观察。我相信流程是 certificates -> certificaterequests -> orders -> challenges。

注意：了解此一般流程对我在尝试调试时了解 kubernetes 中请求失败的位置非常有帮助。

在调试时，您通常希望执行 kubectl -n cert-manager <stage> -A 以查看该阶段中所有未完成资源的列表。请记住，在完成 challenge 后，它将不再显示在 kubectl -n cert-manager challenges 的输出中。

另请记住，为完成挑战阶段而创建的任何 DNS 条目通常会将其 TTL 设置为 ~2 分钟，因此如果您查看 Cloudflare UI 并没有看到它们，它们可能已经超时并退出。

例如：

ss#1

参考资料

相关问题
最新问题