GreenLock (Let's Encrypt) с использованием существующего хранилища certbot, используемого apache - PullRequest
Новая
       64

GreenLock (Let's Encrypt) с использованием существующего хранилища certbot, используемого apache

0 голосов
/ 15 мая 2018

У меня есть веб-сайт, который обслуживает Apache. Я использую сертификаты LetsEncrypt, которые были созданы certbot с помощью плагина apache. ОС это Ubuntu. Сайт работает отлично.

Теперь я использую сервер API на основе NodeJS, использующий HTTPS. Для тестирования я успешно использовал файлы сертификатов в качестве опции TLS следующим образом: 

var tls = {
    key: FS.readFileSync("...."),
    cert: FS.readFileSync("...") };

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

Тогда я узнал о превосходной библиотеке GreenLock. Я думаю, что это то, что я хочу, но мне нужно немного разъяснений.

  1. Если я использую библиотеку GreenLock и указываю на существующий управляемый каталог certbot, он просто подберет существующий сертификат? Обратите внимание, что существует сервер apache, работающий на порту 80 для аутентификации этих сертификатов.

  2. Будет ли спор между керботом и гринлоком по поводу возобновления сертификата?

  3. Нужно ли перезапускать мой сервер API, чтобы он распознал обновленные сертификаты или GreenLock делает обновление прозрачным для сервера NodeJS?

По сути, я хочу, чтобы GreenLock просто использовал сертификаты из магазина и позволил certbot + apache управлять созданием и обновлением. Также при таком управлении мой сервер NodeJS продолжает работать и распознает обновление.

Ответы [ 2 ]

0 голосов
/ 16 мая 2018

@ CoolAJ

Основываясь на вашем ответе, я думаю, что нашел схему, которая подходит мне. Я хотел бы запустить его для комментариев.

Учитывая мои знания о Greenlock на этом этапе, я знаю, что могу разделить свой API-сервер на отдельную коробку, и он позаботится о приобретении и обновлении моего сертификата. Пальцы вверх! Но я оставляю это для моего запасного решения. У меня есть инфраструктурная причина для того, чтобы попытаться запустить мой сервер API вместе с сервером веб-контента Apache на одном и том же компьютере, говорящем по протоколу HTTPS, и я собираюсь продвинуться еще немного, чтобы получить полное пробное решение. И это то, что я имею в виду.

  1. Мой сервер веб-контента Apache + установка certbot работает нормально. Таким образом, этот apache уже отвечает на проверку домена (мои знания о процессе полностью отсутствуют) на порту 80

  2. Я хочу запустить сервер веб-API NodeJS, который говорит по протоколу HTTPS на том же компьютере, и хотел бы использовать Greenlock для управления получением и обновлением сертификатов для этого сервера API.

В своем первоначальном вопросе я хотел знать, могу ли я просто указать зеленому указателю на сертификатную директорию, которой управляет Certbot, и на это вы дали достаточно четкий ответ. Это привело меня к мысли, что я не хочу, чтобы greenlock работал из управляемого каталога certbot.

Таким образом, моя проблема в разделении (certbot и greenlock) на одном и том же компьютере заключается в том, что только один веб-сервер, работающий на порте 80, будет отвечать на проверку домена для обеих систем (certbot и greenlock).

Итак, я решил, что я сохраню certbot + acache как есть и буду использовать greenlock со схемой webroot, указывающей на веб-корень apache и его собственный configPath. Таким образом, Apache будет валидатором домена. Я буду использовать поддомен для сервера API. Таким образом, certbot управляет сертификатом для «blah.com», а greenlock управляет сертификатом для «api.blah.com».

Моя теория такова, что никто не наступает на пальцы ног других. Certbot использует плагин Apache, поэтому это вызов TLS-SNI-01, а Greenlock будет использовать запрос http-01 (используя Apache для обслуживания файлов).

И я вижу в вашем примере с полностью автоматическим HTTPS

https://git.coolaj86.com/coolaj86/greenlock.js

, чтобы я мог снабдить магазин certbot webrootPath.

Это означает, что когда мой сервер API пытается получить / обновить сертификаты, именно сервер apache будет отвечать на проверку домена, и мне не нужен мой сервер nodejs для запуска чего-либо на порту 80.

Что вы думаете об этом?

Спасибо за ваше время.

0 голосов
/ 15 мая 2018

Совместимость

Mozilla IOT недавно добавила несколько исправлений для плагина le-store-certbot, который исправил несколько ошибок с совместимостью с certbot.

Скрестим пальцы, последняя версия будет совместима с ранее созданной структурой папки certbot, просто установите configDir при необходимости.

Соперничество

Когда вы используете Greenlock & trade;, certbot не требуется, и я не уверен, насколько хорошо он будет работать для обеих систем в одной системе. В теории это должно работать ... но я бы этого не делал.

Однако, поскольку вы используете node.js в качестве сервера https, а не Apache, я не думаю, что есть какая-то причина, по которой вам все еще нужен certbot.

Автоматизированный HTTPS

Greenlock автоматически обновляет сертификаты на основе информации об истечении срока действия, которая есть в сертификате, а не в задании cron. Если для configDir установлено значение /etc/acme, а сертификат существует в /etc/acme/live/example.com/fullchain.pem, то этот сертификат будет использоваться.

Службу узла перезапускать не нужно. Всякий раз, когда в памяти нет сертификата, он проверяет диск и затем запрашивает его через ACME. Всякий раз, когда в памяти есть сертификат, у него есть информация об истечении срока действия, и когда он собирается обновить сертификат, он сначала проверяет наличие нового диска на диске, прежде чем фактически выполнить запрос (следовательно, он должен работать с certbot) .

...