Challenges
ACME 颁发者使用Challenge资源来管理 ACME“challenge”的生命周期,必须完成该生命周期才能完成对单个 DNS name/identifier的“授权”。
当一个Order资源被创建,order控制器将创造Challenges的资源正在被授权与ACME服务器的每个DNS名称。
作为最终用户,您永远不需要手动创建challenge资源。challenge一经创建便无法更改。相反,必须创建新的challenge资源。
Challenge lifecycle
创建Challenge resource后,它将首先排队等待处理。在“安排”开始challenge之前,不会开始处理。此调度过程可防止一次尝试过多的质询,或一次尝试针对同一 DNS 名称的多个质询。
一旦安排了质询,它将首先与 ACME 服务器“同步”以确定其当前状态。如果challenge已经有效,则其“状态”将更新为“有效”,并且自身也设置为“取消 调度”。status.processing = false
如果质询仍处于“待处理”状态,质询控制器将使用配置的求解器(HTTP01 或 DNS01 之一)“呈现”质询。一旦“提出”challenge,它将设置status.presented=true。
一旦“呈现”,challenge控制器将执行“自检”以确保challenge已“传播”(即权威 DNS 服务器已更新以正确响应,或者已观察到入口资源的变化并进入)由入口控制器使用)。
如果自检失败,cert-manager 会以固定的 10 秒重试间隔重试自检。从未完成自检的challenge将继续重试,直到用户干预。
一旦自检通过,与此challenge相关的 ACME“授权”将被“接受”(TODO:添加链接到 ACME 规范的接受challenge部分)。
接受后授权的最终状态将被复制到challenge的status.state字段,如果在 ACME 服务器尝试验证challenge时发生错误,则会复制“错误原因”。
一旦challenge赛已经进入valid,invalid,expired或 revoked状态时,将设置status.processing=false防止ACMEchallenge的任何进一步的处理,并允许,如果有challenge,完成积压为计划的另一项challenge。
challenge调度
不是尝试一次处理所有challenge,而是由证书管理器“安排”challenge。
此调度程序对同时质询的最大数量设置了上限,并且不允许同时完成针对相同 DNS 名称和求解器类型(http-01 或 dns-01)的两个质询。
从ddff78 开始,一次可以处理的最大challenge数为 60 。
调试challenge resources
为了确定未颁发 ACME 证书的原因,我们可以使用 cert-manager 创建的“challenge”资源进行调试。
为了确定哪个challenge失败,您可以运行 :kubectl get challenges
$ kubectl get challenges
NAME STATE DOMAIN REASON AGE
example-com-1217431265-0 pending example.com Waiting for dns-01 challenge propagation 22s
这表明已成功使用 DNS01 求解器提出了challenge,现在 cert-manager 正在等待“自检”通过。
您可以使用以下方法获取有关challenge的更多信息:kubectl describe
$ kubectl describe challenge example-com-1217431265-0
...
Status:
Presented: true
Processing: true
Reason: Waiting for dns-01 challenge propagation
State: pending
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Started 19s cert-manager Challenge scheduled for processing
Normal Presented 16s cert-manager Presented challenge using dns-01 challenge mechanism
每个challenge状态的进展将被记录为事件或challenge的status块(如上所示)。