Traefik использует сертификат по умолчанию, хотя файл acme.json сгенерирован правильно - PullRequest
Новая
       3

Traefik использует сертификат по умолчанию, хотя файл acme.json сгенерирован правильно

1 голос
/ 21 марта 2019

У меня странная проблема с использованием Traefik. Я хотел бы использовать ACME для генерации сертификатов TLS. Мой acme.json файл, кажется, заполняется правильно после выполнения проверки с использованием DNS, однако, когда я использую 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

1 Ответ

1 голос
/ 22 марта 2019

У меня была та же проблема вчера днем.В моем случае это работало на сервере, поэтому я оставил его включенным, чтобы продолжить устранение неполадок сегодня утром.

Когда я попробовал сегодня утром, 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:

  • Был создан новый идентификатор учетной записи(не знаю почему)

  • Поле Сертификаты не заполнено.То, что у меня было в моем файле acme.json, было, вероятно, просто закрытым ключом сгенерированного letsencrypt аккаунта, но сертификат еще не выдан.Сертификат был выдан только около 1:30 позже (я не мог сказать, когда я удалял Pod несколько раз, чтобы посмотреть, помог ли он, в прошлый раз я убил его в 18: 03UTC, и он начал работать в 18: 59UTC.

Итак, сейчас я сосредоточусь на части acme (до сих пор я предполагал, что сертификат был сгенерирован правильно с самого начала)

РЕДАКТИРОВАТЬ: последние выводы

В конце я выяснил, что в моем сценарии (не уверен, будет ли он применяться к вам, но вы можете включить ведение журнала acme, чтобы выяснить), проблема была связана с проверкой DNS.

Журналы (они будут показаны, если acmeLogging установлен в true в конфигурации traefik): 

{"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 (и, следовательно, Traefik, который использует Lego) будет ждать, пока уполномоченный сервер для ответов DNSс правильным вызовом (механизм, позволяющий LetsEncrypt не выполнять вызов до того, как он будет готов).

В моем случае Dreamhost требуется некоторое время для выполнения этого обновления. Даже если это изменение отражаетНемедленно редактируя на веб-портале (создана запись TXT), Dreamhost DNS требуется некоторое время, чтобы вернуть обновленную запись для него.

В журналах выше это заняло всего несколько минут, но на других итерациях я видел задержку до 30 минут (может быть, больше, не уверен).Может быть, у вас есть похожая проблема с route53.

Забавно, что DNS DNS (1.1.1.1) с облачным разрешением решал это намного раньше, чем Dreamhost (авторитетный сон).

Я думаюВы также можете обойти эту логику, установив для delayBeforeCheck значение >0, но это не очень хорошая практика, так как вызов LetsEncrypt может завершиться неудачно (не уверен, если LetsEncrypt запрашивает об этом авторитетный сервер).

Надеюсь, это тоже ваш сценарий.Кстати, еще один признак этого сценария заключается в том, что запись DNS остается созданной, поскольку она не будет удалена до тех пор, пока вызов DNS не будет успешным (или я предполагаю, что тайм-аут достигнут)

...