| 英文 | 英文 - K8S CRD | 中文 | 备注 |
|---|---|---|---|
| certificates | Certificate |
证书 | certificates.cert-manager.io/v1 |
| certificate issuers | Issuer |
证书颁发者 | issuers.cert-manager.io |
ClusterIssuer |
集群证书颁发者 | clusterissuers.cert-manager.io |
|
| certificate request | CertificateRequest |
证书申请 | certificaterequests.cert-manager.io |
| order | Order |
（证书）订单 | orders.acme.cert-manager.io |
| challenge | Challenge |
（证书）挑战 | challenges.acme.cert-manager.io |
| SelfSigned | 自签名 | cert-manager Issuer 的一种 | |
| CA | 证书颁发机构 | Certificate Authority 的缩写； cert-manager Issuer 的一种 |
|
| Vault | 金库 | cert-manager Issuer 的一种，即 Hashicorp Vault | |
| Venafi | Venafi 在线证书办理服务，目前用的不多。 | ||
| External | 外部 | cert-manager Issuer 的一种 | |
| ACME | 自动证书管理环境 | Automated Certificate Management Environment 的缩写； cert-manager Issuer, 包括 HTTP01 和 DNS01 |
书接上回, 最后了解一下 cert-manager 的相关概念.
Issuers 和 ClusterIssuers 是 Kubernetes CRD，代表证书颁发机构（CA），能够通过兑现证书签名请求来生成签名证书。所有 cert-manager 证书都需要一个被引用的签发者，该签发者处于准备就绪的状态，可以尝试兑现请求。
Issuer 类型的一个例子是 "CA"。一个简单的CA Issuer如下。
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: ca-issuer
namespace: mesh-system
spec:
ca:
secretName: ca-key-pair
这是一个简单的Issuer，将根据私钥（私钥存储在 Secret 的ca-key-pair中）签署证书。
Issuer: 限定在一个 NameSpace 的资源；ClusterIssuer: 可以用于在所有命名空间中颁发 "证书"。cert-manager 有 Certificate 的概念，定义了所需的 X.509 证书，它将被更新并保持最新。一个 Certificate 是一个 Kubernetes 的 CRD，它引用了一个 Issuer 或 ClusterIssuer，决定了什么将被授予证书请求。
当一个 Certificate 被创建时，一个相应的 CertificateRequest 资源由 cert-manager 创建，其中包含编码的 X.509 证书请求，Issuer reference，以及其他基于 证书 资源规范的选项。
这个 Certificate 将告诉 cert-manager 尝试使用哪个 Issuer 来获取域名的证书密钥对。如果成功，得到的 TLS 密钥和证书将被保存在一个 secret 中，Key 分别为tls.key和tls.crt。这个 Secret 将与Certificate CRD 在同一个命名空间。示例如下：
当证书由中间 CA 签发，并且Issuer 可以提供签发的证书链时，tls.crt的内容将是请求的证书，后面是证书链。
此外，如果证书颁发机构是已知的，相应的 CA 证书将被存储在 Secret 中，密钥为ca.crt。例如，对于 ACME 发行者，CA 是不知道的，ca.crt将不存在于acme-crt-secret中。
cert-manager 有意避免在tls.crt中添加根证书，因为在安全进行 TLS 的情况下，这些证书是无用的。
当配置一个客户端连接到具有由私人 CA 签署的服务证书的 TLS 服务器时，你需要向客户端提供 CA 证书，以便它验证服务器。
dnsNames字段指定了与证书相关的 SAN 的列表。
这张图显示了使用 ACME/Let's Encrypt Issuer 的名为cert-1的证书的生命周期。
CertificateRequest是 cert-manager 中的一个 Kubernetes CRD，用于向 Issuer 申请 X.509 证书。该资源包含一个 Base64 编码的 PEM 编码的证书请求字符串，它被发送到被引用的签发者。一个成功的签发将返回一个基于证书签署请求的签名证书。CertificateRequests通常由控制器或其他系统消费和管理，不应该由人类使用 - 除非特别需要。
CertificateRequest的spec内的所有字段，以及任何管理的 cert-manager 注释，都是不可改变的，创建后不能修改。
成功签发证书签署请求将导致对资源的更新，用签署的证书、证书的 CA（如果可用）设置状态，并将 Ready 条件设置为 True。如下图：
无论证书签署请求的签发是否成功，签发的重试都不会发生。管理CertificateRequests的逻辑和生命周期是其他控制器的责任。
CertificateRequests 有一组强定义的条件，控制器或服务应该使用和依赖这些条件来决定下一步对资源采取什么行动。
每个准备好的条件由一对Ready--一个布尔值，和Reason--一个字符串组成。这组值和含义如下：
| Ready | Reason | 条件含义 |
|---|---|---|
| False | Pending | CertificateRequest目前正处于等待状态，等待其他操作的发生。这可能是由于Issuer'还不存在，或者Issuer'正在签发证书。 |
| False | Failed | 证书未能被签发--要么是返回的证书未能被解码，要么是用于签名的参考签发者的实例失败。它的控制器将不会对CertificateRequest采取进一步行动。 |
| True | Issued | 被引用的 Issuer 已成功签发了一份经签名的证书。 |
cert-manager 支持从 ACME 服务器请求证书，包括从 Let's Encrypt，使用 ACME Issuer。这些证书通常在公共互联网上被大多数计算机所信任。为了成功申请证书，cert-manager 必须解决 ACME challenge，完成这些 challenge 是为了证明客户拥有被申请的 DNS 地址。
为了完成这些 challenge，cert-manager 引入了两种 CRD 类型：Orders 和 Challenges。
Orders资源被 ACME 发行者用来管理 ACME '订单' 的生命周期，以获得签名的 TLS 证书。关于 ACME 订单和域名验证的更多细节可以在 Let's Encrypt 网站 这里 找到。一个订单代表了一个单一的证书请求，一旦一个新的 CertificateRequest 资源引用 ACME 发行人，该订单就会自动创建。一旦 Certificate 资源被创建、规格改变或需要更新，CertificateRequest资源将由 cert-manager 自动创建。
作为终端用户，您将永远不需要手动创建一个 Order 资源。一旦创建，Order 不能被改变。相反，必须创建一个新的 Order资源。
Order 资源封装了该 "订单" 的多个 ACME Challenge，因此，将管理一个或多个 Challenge 资源。
Challenges 资源被 ACME 发行者用来管理 ACME challenge 的生命周期，为了完成对一个 DNS 名称/标识的 "认证"，必须完成 challenge。
当一个 Order 资源被创建时，order 控制器将为每个正在被 ACME 服务器认证的 DNS 名称创建 Challenge资源。
作为终端用户，你永远不需要手动创建一个 Challenge 资源。一旦创建，Challenge就不能被改变。相反，必须创建一个新的 Challenge资源。
在 Challenges 资源被创建后，它最初将被排队处理。在 challenge 被 "安排" 开始之前，处理将不会开始。这种调度过程可以防止一次尝试太多的 challenge，或一次尝试对同一 DNS 名称的多个 challenge。
一旦 challenge 被安排，它将首先与 ACME 服务器进行 "同步"，以确定其当前状态。如果 challenge 已经有效，它的 status 将被更新为 valid，并且还将设置status.processing = false以 "取消计划"。
如果 challenge 仍然 "pending"，challenge 控制器将使用配置的解决方法（HTTP01 或 DNS01 之一）"present" challenge。一旦 challenge 被 "present"，它将设置status.presented = true。
一旦 "present"，challenge 控制器将执行 "self check"，以确保 challenge 已经 "propagated（已传播）"（即权威的 DNS 服务器已被更新以作出正确响应，或 ingress 资源的变化已被 ingress controller 观察到并正在使用）。
如果自检失败，cert-manager 将以固定的 10 秒重试时间间隔重试自检。没有完成自检的 challenge 将继续重试，直到用户通过重试 "订单"（通过删除 "订单 "资源）或修改相关的 "证书 "资源来解决任何配置错误进行干预。
一旦自检通过，与此 challenge 相关的 ACME "authorization（认证） "将被 "accepted（接受）"。
接受认证后的最终状态将被复制到 challenge 的status.state 字段，如果 ACME 服务器试图验证 challenge 时发生错误，也会复制 "error reason（错误原因）"。
一旦 challenge 进入 valid、invalid、expired 或 revoked （撤销）状态，它将设置 status.processing = false，以防止 ACME challenge 的任何进一步处理，如果有积压的 challenge 要完成，允许安排另一个 challenge。
cert-manager 并不试图一次处理所有的 challenge ，而是对 challenge 进行 "调度"。
这个调度器对同时进行的 challenge 的最大数量设置了上限，并且不允许对同一 DNS 名称和解算器类型（HTTP01或DNS01）的两个 challenge 同时完成。
一次可以处理的最大 challenge 数量是 60 个，原因是 ddff78
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.
近期用 cert-manager 申请的通配符证书续期失败了，然后过了几天又成功了。正好借着这个情况捋一下 cert-manager 的 SSL证书申请流程以及过程中涉及到的相关概念。