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文件中的内容可能只是letencrypt生成的帐户的私钥，但尚未颁发证书。证书仅在大约1h30之后发布（无法告诉我删除Pod几次以查看它是否有帮助，我上次杀死它的时间是18：03UTC，它在18：59UTC开始工作。

所以我现在将重点放在acme部分上（到目前为止，我一直认为自开始以来就已经正确生成了证书）

编辑：最新发现

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

日志（如果在traefik配置中将acmeLogging设置为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质询成功（或者我认为是超时），它才会被删除

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

1 个答案: