Назад | Перейти на главную страницу

обновление ssl-сертификата для gitlab с помощью certbot и позволяет шифровать

Я запускаю gitlab на ubuntu 14. Срок действия ранее настроенного сертификата истек (для продления не была настроена запись cron). Я пытаюсь настроить certbot (с функцией шифрования) для обновления сертификата, а затем настроить запись crontab для автоматического продления. Когда я запускаю certbot, я получаю сообщение, скопированное ниже (есть ли место, где я могу получить более подробное сообщение об ошибке):

выполняемая команда:

./certbot-auto certonly --webroot -w /opt/gitlab/ssl -d git.xyz.com

git.xyz.com - действительный домен (я заменил фактический домен на xyz). Каталог / opt / gitlab / ssl существует, и пользователь, используемый для запуска команды, имеет права чтения / записи в этом каталоге и его содержимом.

ошибка Ошибка авторизации. git.xyz.com (http-01): urn: acme: error: connection :: Серверу не удалось подключиться к клиенту для проверки домена :: Не удалось подключиться к git.xyz.com

ВАЖНЫЕ ЗАМЕТКИ:

- The following errors were reported by the server:

   Domain: git.xyz.com
   Type:   connection
   Detail: Could not connect to git.xyz.com

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Есть мысли о том, как я могу лучше отладить эту проблему?

забыл упомянуть: я могу получить доступ к URL-адресу из внешней сети (имя домена правильное), и в настоящее время брандмауэр не был настроен для остановки трафика на порте 80/443 (я даже отключил брандмауэр, чтобы проверить).

Я не уверен, что это поможет, но, по крайней мере, я мог представить, что это проблема:

  • Вы автоматически перенаправляетесь на https при подключении через http.
  • Это перенаправление также применимо к Let's Encrypt, поэтому они получат ваш недействительный сертификат, связанный с датой.
  • На этом этапе соединение не будет успешным, что приведет к отображаемой вам ошибке.
  • Кроме того, вы используете HSTS. Я не уверен, уважает ли Let's Encrypt этот заголовок, если они когда-то его видели.

Так что делать? Я тоже не уверен, но вот несколько советов:

  • Отключить http к https перенаправить и повторить попытку.

  • Если HSTS уважается:

    • Установить HSTS заголовок на что-то очень короткое, например, на одну секунду, поместите эту конфигурацию на место, снова запустите клиент Let's Encrypt, чтобы они получили новый заголовок, отключите перенаправление, подождите некоторое время и снова запустите клиент.

    • Если это не сработает: получите другой действительный сертификат, например, выданный StartSSL, установите и попробуйте еще раз.

Для будущего:

  • Настройте автоматическое обновление сертификата и, кроме того, поставьте мониторинг, который, по крайней мере, предупредит вас, если что-то подобное может повториться, прежде чем это произойдет.

Сделай что-нибудь хорошее:

  • Создайте заявку или напишите сообщение в их форум / электронное письмо, объясняя, что произошло, и спрашивая, могут ли они проверить эти ошибки, и дайте людям подсказку (также известную как более качественное сообщение об ошибке).

(Незначительное: если вы не хотите делать свой домен общедоступным, вам следует удалить его из своего сообщения.)