Certificate¶
cert-manager 有Certificates的概念，它定义了所需的 X.509 证书，该证书将被更新并保持最新。 一个Certificates是一个引用Issuer 或 ClusterIssuer的命名空间源，它们决定了什么将履行证书请求。
当创建Certificates时，相应的CertificateRequest源由 cert-manager 创建，其中包含编码的 X.509 证书请求、Issuer引用以及基于Certificates源规范的其他选项。
下面是一个Certificate源的例子。
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: acme-crt
spec:
secretName: acme-crt-secret
dnsNames:
- example.com
- foo.example.com
issuerRef:
name: letsencrypt-prod
# We can reference ClusterIssuers by changing the kind here.
# The default value is Issuer (i.e. a locally namespaced Issuer)
kind: Issuer
group: cert-manager.io
该Certificate将告诉 cert-manager 尝试使用名为letsencrypt-prod的Issuer来获取example.com 和 foo.example.com域的证书密钥对。 如果成功，生成的 TLS 密钥和证书将存储在名为acme-crt-secret的密钥中，密钥分别为tls.key和tls.crt。 这个秘密将位于与Certificate源相同的名称空间中。
当一个证书是由中间 CA 颁发的，并且Issuer可以提供颁发的证书链时，tls.crt的内容将是所请求的证书，后面是证书链。
此外，如果知道证书颁发机构，相应的 CA 证书将存储在密钥为ca.crt的秘密中。 例如，对于 ACME 颁发者，CA 是未知的，ca.crt将不存在于acme-crt-secret中。
cert-manager 有意避免向tls.crt添加根证书，因为它们在安全执行 TLS 的情况下是无用的。有关更多信息，请参见RFC 5246 章节 7.4.2，其中包含以下解释:
因为证书验证要求独立地分发根密钥，在假设远端必须已经拥有它才能在任何情况下验证它的前提下，指定根证书颁发机构的自签名证书可以从链中省略。
Warning
当配置客户端以使用由私有CA签名的服务证书连接到TLS服务器时，您将需要向客户端提供CA证书，以便其验证服务器。 ca.crt可能包含您需要信任的证书，但 不要挂载与服务器相同的Secret 来访问ca.crt。
这是因为:
- 这个
Secret还包含服务器的私钥，应该只有服务器可以访问。 您应该使用RBAC来确保包含服务证书和私钥的Secret只有需要它的Pods才能访问。 - 安全轮换CA证书依赖于能够同时信任旧CA证书和新CA证书。 通过直接从源代码使用CA，这是不可能的;为了轮换证书，您将 被迫 有一些停机时间。
在配置客户端时，您应该独立地选择并获取您想要信任的CA证书。 从带外下载CA，并将其存储在与包含服务器私钥和证书的Secret分开的Secret或ConfigMap中。
这确保了如果Secret中包含服务器密钥和证书的材料被篡改， 客户端将无法连接到受威胁的服务器。
同样的概念也适用于为相互验证的TLS配置服务器; 不要让服务器访问包含客户端证书和私钥的Secret。
dnsNames 字段指定了一个与证书相关联的主题替代名称列表。
引用的Issuer必须与Certificate存在于相同的名称空间中。 Certificate也可以引用非命名空间的ClusterIssuer，因此可以从任何命名空间引用。
你可以阅读更多关于如何配置你的Certificate源这里。
证书生命周期¶
该图显示了使用 ACME / Let's Encrypt 颁发者的名为cert-1的证书的生命周期。 使用 cert-manager 不需要理解所有这些步骤;对于那些对这个过程好奇的人来说，这更多的是对发生在引擎盖下的逻辑的解释。
