常见问题 (FAQ)¶

这些术语的定义见TLS术语页.

These terms are defined in the TLS Terminology page.

This is a feature in cert-manager starting in v0.16 using the cmctl CLI. More information can be found on the renew command's page

为了确定是否需要重新颁发证书，证书管理器会查看Certificate源规范和最新的CertificateRequest规范， 以及Secret中包含X.509证书的数据。

如果出现以下情况，发行过程将始终被触发:

• 在Certificate规范上命名的Secret，不存在，缺少私钥或证书数据或包含损坏的数据
• 存储在Secret 中的私钥与Certificate上的私钥规格不匹配
• 已发出证书的公开密匙与储存在Secret内的私钥不相符。
• Secret上的cert-manager颁发者注释与Certificate上指定的颁发者不匹配
• 颁发证书上的DNS名称、IP地址、url或电子邮件地址与Certificate规范上的不匹配
• 证书需要更新(因为已过期或更新时间已过)
• 证书已被标记为手动更新使用cmctl

此外，如果找到了Certificate的最新CertificateRequest，在以下情况下，证书管理器也会重新颁发:

• 在CertificateRequest中发现的CSR上的通用名称与Certificate规范上的不匹配
• 在CertificateRequest中发现的CSR的主题字段与Certificate规范的主题字段不匹配
• CertificateRequest上的持续时间与Certificate规范上的持续时间不匹配
• Certificate规范上的 isCA 字段值与CertificateRequest不匹配
• CertificateRequest规范中的DNS名称、IP地址、url或电子邮件地址与Certificate规范中的不匹配
• CertificateRequest规范上的关键用法与Certificate规范上的不匹配

Occasionally, people work with systems which have made a flawed choice regarding TLS chains. The TLS spec has the following section for the "Server Certificate" section of the TLS handshake:

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

In a standard, secure and correctly configured TLS environment, adding a root certificate to the chain is almost always unnecessary and wasteful.

There are two ways that a certificate can be trusted:

• explicitly, by including it in a trust store.
• through a signature, by following the certificate's chain back up to an explicitly trusted certificate.

Crucially, root certificates are by definition self-signed and they cannot be validated through a signature.

As such, if we have a client trying to validate the certificate chain sent by the server, the client must already have the root before the connection is started. If the client already has the root, there was no point in it being sent by the server!

The same logic with not sending root certificates applies for servers trying to validate client certificates; the same justification is given in the TLS RFC.

cert-manager publishes all events to the Kubernetes events mechanism, you can get the events for your specific resources using kubectl describe <resource> <name>.

Due to the nature of the Kubernetes event mechanism these will be purged after a while. If you're using a dedicated logging system it might be able or is already also storing Kubernetes events.

{/_ This empty link preserves old links to #what-happens-if-a-renewal-doesn't happen?-will-it-be-tried-again-after-some-time?", which matched the old title of this section _/}

cert-manager will retry a failed issuance except for a few rare edge cases where manual intervention is needed.

If an issuance fails because of a temporary error, it will be retried again with a short exponential backoff (currently 5 seconds to 5 minutes). A temporary error is one that does not result in a failed CertificateRequest.

If the issuance fails with an error that resulted in a failed CertificateRequest, it will be retried with a longer binary exponential backoff (1 hour to 32 hours) to avoid overwhelming external services.

You can always trigger immediate renewal using the cmctl renew command

cert-manager supports ECDSA key pairs! You can set your certificate to use ECDSA in the privateKey part of your Certificate resource.

For example:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ecdsa
spec:
  secretName: ecdsa-cert
  isCA: false
  privateKey:
    algorithm: ECDSA
    size: 256
  dnsNames:
    - ecdsa.example.com
  issuerRef: [...]

Default duration is 90 days. If renewBefore has not been set, Certificate will be renewed ⅔ through its actual duration.

Kubernetes has a Certificate Signing Requests API, and a [kubectl certificates command] which allows you to approve certificate signing requests and have them signed by the certificate authority (CA) of the Kubernetes cluster.

This API and CLI have occasionally been misused to sign certificates for use by non-control-plane Pods but this is a mistake. For the security of the Kubernetes cluster, it is important to limit access to the Kubernetes certificate authority, and it is important that you do not use that certificate authority to sign certificates which are used outside of the control-plane, because such certificates increase the opportunity for attacks on the Kubernetes API server.

In Kubernetes 1.19 the Certificate Signing Requests API has reached V1 and it can be used more generally by following (or automating) the Request Signing Process.

cert-manager currently has some limited experimental support for this resource.

cert-manager should always be written in lowercase. Even when it would normally be capitalized such as in titles or at the start of sentences. A hyphen should always be used between the words, don't replace it with a space and don't remove it.