即使正确生成了 acme.json 文件，Traefik 仍在使用默认证书

Question

我在使用 Traefik 时遇到了一个奇怪的问题。我想使用 ACME 生成 TLS 证书。在使用 DNS 执行验证后，我的 acme.json 文件似乎已正确填充，但是，当我使用 OpenSSL 验证证书时，它似乎使用的是 Traefik 提供的默认证书。

这些是我的设置：

[acme]
acmelogging= true
caServer = "https://acme-staging-v02.api.letsencrypt.org/directory"
delayBeforeCheck = 0
email = "<REDACTED>"
entryPoint = "https"
storage = "/etc/traefik/acme.json"
  [acme.dnsChallenge]
  delayBeforeCheck = 0
  provider = "route53"
  [[acme.domains]]
  main = "<REDACTED>"

[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
    address = ":443"
    [entryPoints.https.tls]

这是证书的主题：

➜  Docker git:(master) ✗ openssl s_client -connect localhost:443 -servername <REDACTED> 2>/dev/null | openssl x509 -noout -subject

subject= /CN=TRAEFIK DEFAULT CERT

Answer 1

昨天下午我也遇到了同样的问题。就我而言，它是在服务器上运行的，所以我让它继续运行以在今天早上继续进行故障排除。

当我今天早上尝试时，Traefik 的行为符合预期！ （提供 ACME 证书）。我将尝试进行更多调查或在 Github 中打开一个问题以进行澄清。

如果您想测试是否遇到相同的行为，只需添加此答案。启动您的环境，并让它运行几个小时。

顺便说一句，这是我第二次遇到这种情况。我第一次遇到相同的行为（最初无法正常工作，经过几个小时的故障排除后开始按预期工作）。

查看日志，我发现了正常工作时应该出现的消息：

{"level":"debug","msg":"Certificates obtained for domains [*.<REDACTED>]","time":"2019-03-21T18:59:44Z"}
{"level":"debug","msg":"Configuration received from provider ACME: {}","time":"2019-03-21T18:59:44Z"}
.....
{"level":"debug","msg":"Add certificate for domains *.<REDACTED>","time":"2019-03-21T18:59:45Z"}
{"level":"info","msg":"Server configuration reloaded on :443","time":"2019-03-21T18:59:45Z"}
{"level":"info","msg":"Server configuration reloaded on :8080","time":"2019-03-21T18:59:45Z"}
{"level":"info","msg":"Server configuration reloaded on :80","time":"2019-03-21T18:59:45Z"}

我还备份了我认为有效的 acme.json 文件，因此我与今天的文件进行了比较。

旧的（不工作）

{
  "Account": {
    "Email": "REDACTED",
    "Registration": {
      "body": {
        "status": "valid",
        "contact": [
          "mailto:REDACTED"
        ]
      },
      "uri": "https://acme-staging-v02.api.letsencrypt.org/acme/acct/ACCOUNT_ID_1"
    },
    "PrivateKey": "REDACTED",
    "KeyType": "4096"
  },
  "Certificates": null,
  "HTTPChallenges": {},
  "TLSChallenges": {}
}

新（工作）

{
  "Account": {
    "Email": "REDACTED",
    "Registration": {
      "body": {
        "status": "valid",
        "contact": [
          "mailto:REDACTED"
        ]
      },
      "uri": "https://acme-staging-v02.api.letsencrypt.org/acme/acct/ACCOUNT_ID_2"
    },
    "PrivateKey": "REDACTED",
    "KeyType": "4096"
  },
  "Certificates": [
    {
      "Domain": {
        "Main": "*.REDACTED",
        "SANs": null
      },
      "Certificate": "REDACTED",
      "Key": "REDACTED"
    }
  ],
  "HTTPChallenges": {},
  "TLSChallenges": {}
}

所以主要的2个变化：

• 生成了一个新的帐户 ID（不知道为什么）

• 证书字段未填充。我在 acme.json 文件中的内容可能只是letsencrypt 生成帐户的私钥，但尚未颁发证书。证书仅在 1 小时 30 分左右发布（无法判断，因为我删除了几次 Pod 以查看它是否有帮助，上次我杀死它是 18:03 UTC，它在 18:59 UTC 开始工作。

  李>

所以我现在将重点放在 acme 部分（到目前为止，我一直假设从一开始就已正确生成证书）

编辑：最新发现

最后，我发现在我的场景中（不确定它是否适用于您，但您可以启用 acme 日志记录来找出问题）与 DNS 验证有关。

日志（如果 acmeLogging 在 traefik 配置中设置为 true，则会显示这些日志）：

{"level":"info","msg":"legolog: [INFO] [*.REDACTED] Server responded with a certificate.","time":"2019-03-22T11:14:44Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Validations succeeded; requesting certificates","time":"2019-03-22T11:14:39Z"}
{"level":"info","msg":"legolog: [INFO] dreamhost: record_removed","time":"2019-03-22T11:14:39Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Cleaning DNS-01 challenge","time":"2019-03-22T11:14:39Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] The server validated our request","time":"2019-03-22T11:14:39Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Waiting for DNS record propagation.","time":"2019-03-22T11:13:34Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Waiting for DNS record propagation.","time":"2019-03-22T11:12:34Z"}
... (1 line per minute)
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Waiting for DNS record propagation.","time":"2019-03-22T10:58:32Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Waiting for DNS record propagation.","time":"2019-03-22T10:57:32Z"}
{"level":"info","msg":"legolog: [INFO] Wait for propagation [timeout: 1h0m0s, interval: 1m0s]","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Checking DNS record propagation using [10.96.0.10:53]","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Trying to solve DNS-01","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] dreamhost: record_added","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Preparing to solve DNS-01","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: use dns-01 solver","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] AuthURL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/REDACTED","time":"2019-03-22T10:57:31Z"}
{"level":"info","msg":"legolog: [INFO] [*.REDACTED] acme: Obtaining bundled SAN certificate","time":"2019-03-22T10:57:30Z"}
{"level":"info","msg":"legolog: [INFO] acme: Registering account for REDACTED,"time":"2019-03-22T10:57:30Z"} 

Lego（以及因此使用 Lego 的 Traefik）将等待 DNS 的权威服务器回复正确的质询（避免让 LetsEncrypt 在准备好之前执行质询的机制）。

就我而言，Dreamhost 需要一段时间才能执行此更新。即使更改立即反映在 Web 门户中（已创建 TXT 记录），Dreamhost DNS 也需要一段时间才能为其返回更新的记录。

在上面的日志中只花了几分钟，但在其他迭代中我看到了长达 30 分钟的延迟（可能更多，不确定）。也许您对route53 有类似的问题。

有趣的是，cloudflare DNS (1.1.1.1) 比dreamhost 更早地解决了这个问题（dreamhost 是权威的）。

我认为您也可以通过将delayBeforeCheck 设置为>0 值来绕过此逻辑，但这听起来不是一个好习惯，因为 LetsEncrypt 质询可能会失败（不确定 LetsEncrypt 是否为此查询权威服务器）。

希望这也是您的情况。顺便说一句，这种情况的另一个症状是 DNS 记录仍然创建，因为它不会被删除，直到 DNS 质询成功（或者我假设达到超时）