Автоматическое обновление сертификатов LetsEncrypt в почтовом сервере MDaemon: пошаговая инструкция / Хабр

Adobe air signing

Для подписи файлов .air

Требуется для всех приложений, основанных на AIR

Android

Для подписи и оптимизации .apk файлов для платформы Android

Code signing for apple

Позволяет разработчикам подписывать программы для Mac OS, а также обновления для программного обеспечения

Essl — embedded secure socket layer

Дальше я представлю на Ваш суд результаты моих исследований данного вопроса проверенные опытным путем. Термин

eSSL

пришел мне в голову в процессе написания этой статьи, так что любые упоминания прошу употреблять вместе со ссылкой на

Итак, освещу немного

важные аспекты строения сертификатов

, которые позволяют использовать их нужным нам способом. Любой сертификат представляет собой совокупность строковых полей подписанную закрытым ключем (

private key

). Сертификат также содержит в себе открытый ключ для проверки подлинности данных содержащихся в этих строковых полях. Перечень полей определен в формате Х.509 v3 и описан в документе

RFC 5280

(это последняя на данный момент редакция документа, до этого действовал

RFC 3280

). Сертификат содержит поле

commomName

которое описывает имя субъекта сертификации, обычно оно совпадает с доменом веб-сайта для которого выпущен сертификат, но в стандарте нет никаких запретов на то что будет вписано в эту строку, например, строка “Вася Пупкин” будет так же валидна для этого поля с точки зрения стандарта — это

первый аспект

. Но веб-браузеры проверяют именно это поле на соответствие с именем сайта который предъявляет сертификат. К счастью для нас в формате X509 v3 определены дополнительные расширения, одно из которых

subjectAltName

, которое позволяет добавить идентификаторы, связанные с основным именем субъекта сертификации (

commomName

). Такими идентификаторами могут быть:

и это

второй

и, пожалуй, наиболее важный

аспект

строения сертификатов 3й версии стандарта. Дело в том что таких идентификаторов можно добавить несколько, т.е. можно вписать несколько IP адресов для которых будет валиден выпущенный сертификат. А это и есть то что нам нужно в случае если некое устройство имеет два Ethernet интерфейса для работы в разных под-сетях, да еще и возможность выхода в сеть через различные типы модемов, если соединение будет по PPP, то это будет третий интерфейс со своим IP адресом. Опытным путем мною был установлен

один важный момент

в назначении альтернативных IP адресов. Браузеры Internet Explorer и FireFox по разному производят проверку альтернативных имен. FireFox сверяет адрес который указан в идентификаторе

IP

, а IE — сверяет адрес с идентификатором

DNS

. Поэтому, для осуществления проверки сертификата в обоих браузерах, каждый необходимый IP адрес

должен быть указан и как IP и как DNS

. О том как это сделать будет рассказано дальше.

Java code signing

Для подписи Java апплетов. Позволяет подписывать .jar файлы и Java приложения для настольных и мобильных устройств.

Распознается Java Runtime Environment (JRE)

Kernel mode signing

Сертификаты разработчика Kernel-Mode позволяют подписывать, так называемые kernel-mode приложения и драйвера устройств. 64 битная версия Windows Vista и Windows 7 требуют, чтобы все kernel-mode приложения были подписаны сертификатом и доверенного центра сертификации.

Microsoft authenticode

Для подписи 32 и 64 битных файлов (.exe, .cab, .dll, .ocx, .msi, .xpi и .xap файлы). Также позволяет подписывать код для Microsoft® Office, Microsoft VBA, Netscape Object Signing и Marimba Channel Signing.

Поддерживает приложения на Silverlight 4

Microsoft office vba signing

Подписывает VBA объекты, скрипты и макросы для файлов Microsoft Office .doc, .xls, и.ppt

Для Microsoft Office и дополнений, которые используют VBA

Microsoft windows phone

Для цифровой подписи приложений для Windows Phone и Xbox 360. Требуется для сервиса Microsoft App Hub

New-selfsignedcertificate: командлет powershell для генерации самоподписанного сертификата

Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).

Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:

Get-Command -Module PKI

Самоподписанные сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.

Для создания сертификата нужно указать значения –DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и —CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат).

Qualcomm brew

Для тех, кто разрабатывает приложения под платформу BREW (Binary Runtime Environment for Wireless)

Импорт корневого сертификата в firefox 6(linux)

В FireFox 6 это делается черех меню

Preferences

->

Encryption

->

View Certificates

, выбираем вкладку

Authorities

Далее нажимаем

Import

и открываем файл нашего корневого сертификата

ca.crt

, на вопрос об использовании, ставим галочку на идентификацию WEB-серверов.

И мы можем лицезреть наш сертификат в списке доверенных центров

Импорт корневого сертификата в ie8 (windows 7 64bit)

В меню Пуск в строке поиска наберите certmgr и нажмите комбинацию клавиш Ctrl Shift Enter, ответьте утвердительно на запрос прав администратора. У Вас запустится менеджер сертификатов.

Дважды кликните на разделе Trusted Root Certification Authorities

Кликните правой кнопкой мыши на Certificates -> All Tasks -> Import…

Запустится мастер импорта сертификатов, следуйте его инструкциям и в качестве сертификата укажите ca.crt. Если в результате получите ошибку

То поправьте ключ в реестре

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftSystemCertificatesRootProtectedRootsFlags

установите его в

0

и перезапустите менеджер сертификатов.

Мы рассмотрели некоторые возможности SSL сертификатов позволяющие идентифицировать систему имеющую несколько IP адресов и/или Доменных имен, а так же рассмотрели простейший сценарий применения сертификатов во встраиваемых системах. Можно ли улучшить этот сценарий?

Конечно можно. Например можно сделать так чтобы корневой сертификат генерировался прямо на устройстве и отдавался пользователю по запросу, например на USB Stick. В этом случае кража корневого сертификата не повлечет за собой опастность для подобных устройств у других покупателей.

Часть информации относящуюся к сертификатам пользователей можно использовать и при покупке сертификатов подписываемых доверенными центрами сертификации. В этом случае обеспечивается наивысший уровень безопастности который может обеспечить технология SSL.

Использование самоподписанного ssl сертификата sha-256 в iis

Обратите внимание, что при создании самоподписанный сертификат для IIS через консоль Internet Information Manager (пункт меню Create Self-Signed Certificate), создается сертификат с исопльзованием алгоритма шифрования SHA-1.

Вы можете привязать самоподписанный сертификат SHA-256, созданный в PowerShell, к сайту IIS. Если вы с помощью PowerShell создали SSL сертификат и поместили его в хранилище сертификатов компьютера, он будет автоматически доступен для сайтов IIS.

Запустите консоль IIS Manager, выберите ваш сайт, затем в настройке Site Binding, выберите созданный вами сертификат и сохраните изменения.

Использовать образы со вшитыми сертификатами

Рано или поздно многие компании обнаруживают потребность контролировать свою инфраструктуру. Админам надоедает отвечать на одинаковые вопросы разработчиков («почему у меня не качает с гитхаба?, «что значит x509?»), безопасникам надоедает наблюдать за тем, как все докер-файлы начинаются со строчки FROM vasyapupkin/zvercd, а разработчикам надоедает решать головоломки с изменчивыми промежуточными сертификатами и прочими вещами вне их области экспертизы. Тогда ответственные за платформу идут и пишут много-много докер-файлов наподобие такого:

Как всё это применять?

Итак, мы создали 2 вида сертификатов, корневой сертификат и сертификат пользователя. Корневой сертификат, как правило, создается один раз и в дальнейшем используется для подписи пользовательских сертификатов, которые мы раздаем пользователям, т.е. помещаем на наши девайсы. Разберемся, как их применять.

Сертификат пользователя и ключ к нему нужно поместить на целевое устройство, у меня это некая плата с ARM контроллером и Linux-ом на борту. Не буду описывать этот процесс, т.к. он зависит от WEBсервера, что у нас там установлен.

Монтирование с хостов

Если прописать в config.toml

[[runners]]
  executor = "kubernetes"
  (...)
  [runners.kubernetes]
    (...)
    [runners.kubernetes.volumes]
      [[runners.kubernetes.volumes.host_path]]
        host_path = "/usr/local/share/ca-certificates"
        mount_path = "/usr/local/share/ca-certificates"
        name = "certs-volume"
        read_only = true

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

[runners.docker]
  (...)
  volumes = ["/usr/local/share/ca-certificates:/usr/local/share/ca-certificates:ro"]

Минус подхода в том, что ответственность за актуальность сертификатов сдвигается на конфигурацию инфраструктуры, поэтому подход удобен, если вы этой инфраструктурой управляете. Если же вы, например, работаете в отдельной команде, которая в многопользовательском кластере Kubernetes сама подняла свой раннер, но не имеет админского доступа туда, вы не можете быть уверены в актуальности сертификатов на хосте, да и можете вовсе не иметь прав на монтирование hostPath.

 kubectl create secret generic -n runner-namespace certs --from-file=/usr/local/share/ca-certificates

а config.toml исправить следующим образом:

[[runners]]
  executor = "kubernetes"
  (...)
  [runners.kubernetes]
    (...)
    [runners.kubernetes.volumes]
      [[runners.kubernetes.volumes.secret]]
        name = "certs"
        mount_path = "/usr/local/share/ca-certificates"
        read_only = true

Если используется докер-экзекьютор на недоступном вам build-сервере, из этого тут же следует, что у вас нет доступа к конфигурации раннера, если только не используется экзотичный вариант подключения к сокету докер-демона по tcp (подобный доступ почти всегда означает, что и доступ к хосту получить тривиально).

Один из плюсов такого подхода в том, что можно делать следующее:

build:
  stage: build
  image: docker:stable
  services:
    - name: docker:18.09.6-dind
      entrypoint:
        - /bin/sh
      command:
        - -c
        - update-ca-certificates && dockerd-entrypoint.sh

Ключевой шаг, естественно, update-ca-certificates.

Поскольку для сервисных контейнеров нельзя прописать последовательность команд аналогично script, а писать длинные скрипты для установки сертификатов под ключом command не очень удобно, меньшим из зол является подобное монтирование сертификатов и сравнительно короткая последовательность команд.

Немного лирики

Что перво-наперво приходит в голову нормальному человеку, когда ему задают вопрос про замену сертификата? Вариантов два: или — а почему бы вам не купить его? Или — так есть же замечательная артель Let’s Encrypt, которая бесплатно раздаёт сертификаты направо и налево!

Первый вариант был смущённо отвергнут как несостоятельный, ввиду того, что, как было сказано ранее, сервер работал, каши не просил, и объяснять руководству, почему оно должно расстаться с энной суммой вечнозелёных денег желания не было никакого. Второй вариант был просто суперпривлекательным, но на горизонте маячили кое-какие проблемы, которые предстояло объехать: оконность почтовика наводила на грустные размышления о его совместимости со скриптами LetsEncrypt, а получать и устанавливать сертификат вручную каждые три месяца совершенно не хотелось.

Поэтому был выбран второй вариант — только нужно было найти способ автоматизировать процессы получения сертификата и привязки его к почтовику.

Начали мы, естественно, с перекапывания великого и ужасного Интернета в поисках уже готового решения. И, о чудо! Оказалось, что доблестные программисты из Alt-N Technologies уже озаботились этим и выдали на-гора скрипты, делающие всё что нужно! Как говорится — снимаю шляпу!

Но и тут не обошлось без ложки дёгтя: эти скрипты просто так всем и каждому не раздавались, а были включены в состав последних версий MDaemon. Однако наш подопечный сервер имел на борту довольно старую версию MDaemon — 13.6.3. Софт был совершенно легальный, купленный некогда за самые что ни на есть настоящие деньги, работал замечательно и его апгрейд в планы руководства конечно же не входил (см. пункт про покупку сертификата).

Поэтому было принято решение попытаться хирургическим путём пересадить скрипты из новой версии MDaemon в старую и заставить их там заработать. Подумано — сделано: на виртуальную машину была установлена самая свежая на тот момент триальная версия MDaemon и из неё изъята папка LetsEncrypt со всем содержимым. Что теперь делать с этим добром? — читайте ниже.

Немого общей имформации об ssl

Технология SSL позволяет шифровать трафик между двумя устройствами. Вы, наверное знаете, что SSL сертификаты выдаются web-сайтам и приязываются на домены или поддомены. Сертификаты выдаются доверенными центрами сертификации (

Certification Authority

) и подписываются электронными подписями. Сертификаты подтверждаются в браузерах путем проверки цепочки сертификатов (

Certification Path

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

Проблема

встраиваемых систем

в том, что,

• во-первых, это не web-сайт в общем понимании этого слова (вспомните, например, веб-интерфейс Wi-Fi роутера), в момент выпуска изделия он не имеет окончательного IP адреса, и еще менее вероятно чтобы он имел какой то домен.
• во-вторых, конечный пользователь может сменить и IP, и домен, если таковой был, хотя бы в целях все той же безопастности.
• в-третьих, покупать сертификат довольно дорого, а вопрос снижения себестоимости стоит всегда.

Как же решать эти проблемы?

Несколько слов про timestamp.

Timestamp или временная метка используется для указания времени, когда цифровая подпись была сделана. Если такая метка присутствует, то приложение, которое проверяет подпись проверит был ли сертификат, связанный с подписью валидным на момент подписи.

Пример:Сертификат действителен с: 01.01. 2008Сертификат действителен до: 31.12.2021Подпись сделана: 04.07.2009Подпись проверена: 30.04.2021

C временной меткой (timestamp) подпись пройдет проверку, поскольку на момент подписи сертификат был действителен. Без такой метки сертификат не пройдет проверку, поскольку на момент проверки у сертификата уже закончился срок.То есть такая метка позволяет использовать подписанный код, даже после срок окончания сертификата.

Несколько советов.

1. Заявку на сертификат желательно оформлять с той же машины, с которой вы потом будете выполнять подпись ПО.
2. Большинство центров сертификации рекомендуют генерировать заявку на сертификат через Internet explorer, хотя при генерации заявок через другие браузеры у нас также не было проблем.

Буду рад ответить на вопросы по сертификатам разработчика, в рамках своей компетенции, так как сам разработчиком не являюсь.Также буду рад дополнениям и уточнениям от тех, кто такими сертификатами пользуется.

UPD: добавил важную информацию про timestamp (временную метку), спасибо TolTol и crea7or

Обязательные требования

Как было написано в

, скрипты LetsEncrypt для MDaemon не являются абсолютно универсальными и предполагают выполнение следующих обязательных условий:

Как видим — часть из этих требований исходно не выполнялась, поэтому сначала была выполнена привязка WorldClient к IIS с целью пересадки его на порт 80. Информация о том, как это сделать была получена из

с сайта Alt-N.

Отступление про сборку docker-образов

Если вы в пайплайнах собираете докер-образы, то, независимо от того, используется docker-in-docker, kaniko или другой сборщик в пайплайне, в контексте сборки сертификаты снова отсутствуют, если их не вшили в базовый образ. Предположим, что каким-либо образом в контейнер пайплайна сертификаты были доставлены (либо примонтированы с хоста, либо получены из другого источника командами в before_script). Тогда конфигурация пайплайнов должна будет выглядеть так:

build:
  stage: build
  # допустим, сборка докером
  image: docker:stable
  services:
    - name: docker:18.09.6-dind
      entrypoint:
        - /bin/sh
      command:
        - -c
        - update-ca-certificates && dockerd-entrypoint.sh
  # before_script:
  #   - script_to_get_certs.sh
  script:
    - mkdir -p certs
    - cp /usr/local/share/ca-certificates/* certs/
    - docker build (...) # или канико или что угодно ещё
    - (...)

а в докер-файлах придётся всегда указывать что-нибудь вроде

Пайплайны

Действия выше выполняются относительно редко, однако если используется Docker или Kubernetes экзекьютор, то каждый джоб будет выполняться в свежесозданном контейнере, в котором снова нет нужных сертификатов. Поэтому необходим способ динамически доставлять сертификаты в контейнеры. Есть несколько таких способов:

Пара слов о «граблях»

Прежде чем приступить к описанию пошаговой инструкции хочу задержать ваше внимание на кое-каких непредвиденных заморочках, осложнивших процесс пересадки скриптов и получения сертификатов.

Во-первых, практически в самом начале скрипта была реализована проверка на то, что параметр ‘EnableWCServer’ в файле ‘Mdaemon.ini’ установлен в ‘Yes’. И если это было не так, то скрипт немедленно завершал свою работу с выдачей сообщения о критической ошибке ‘Error:

WorldClient must be enabled’. Но, как это ни странно, в нашем случае этот параметр был установлен в ‘No’ — несмотря на то, что нами уже была выполнена привязка WorldClient к IIS и WorldClient прекрасно открывался из интернета. Недолго думая, мы отключили эту проверку, закомментарив её в скрипте. Это позволило скрипту продолжить работу.

Получать сертификаты из первоисточника

Если источник корневых сертификатов предоставляет удобный API для их получения, можно не утруждать себя хранением сертификатов на своих серверах с последующим монтированием в пайплайны. Допустим, корневой сертификат можно получить командой

Пример простой автоматизации letsencrypt

Удостоверяющий центр «Let’s Encrypt» (далее просто letsencrypt) вышел из беты пару месяцев назад, пообтерся в реальных условиях, избавился от детских болезней и оброс различными клиентами. И к этому моменту выдал 5 миллионов сертификатов. Самое время внедрять, т.е. получать сертификаты на свои домены и обновлять их в автоматическом режиме. Но как внедрить так, чтобы приблизиться к любимому админскому «поставил и забыл»? Чтобы было просто получать новые сертификаты, а старые при этом обновлялись автоматом? Ну и как добавить немного безопасности в этот процесс?
Ответ под катом.

Как я уже сказал, letsencrypt оброс различными клиентами, которые позволяют получить сертификат. Этих самых клиентов, кстати, уже

десятки

под разные системы и языки программирования. В статье будет рассказано про реализацию клиента на bash от lukas2511,

letsencrypt.sh

. Это один скрипт на bash, который лежит в своей папке и для работы ему нужен только openssl. Запускаться он будет под отдельным пользователем. Конечно, при желании, всегда можно ещё сильнее закрутить гайки в плане безопасности — запускать в chroot и т.д.

Сначала нужно скачать и настроить скрипт.
Предположим, что ОС — linux, веб сервер — nginx, рабочая папка скрипта — /opt/letsencrypt, а пользователь — le.
Создадим системного пользователя, из под которого будет работать скрипт. При создании системного пользователя в debian/ubuntu, ему выставляется оболочка /bin/false и назначается группа nogroup, что нам вполне подходит.

$ sudo adduser --system --home /opt/letsencrypt le

Теперь можно стать этим пользователем и все делать под ним (кроме настройки nginx).

Скачиваем скрипт и смотрим содержимое.

$ sudo -u le -s
$ git clone https://github.com/lukas2511/letsencrypt.sh.git /opt/letsencrypt/
$ ls -la /opt/letsencrypt/
total 84
drwxr-xr-x 4 le   le    4096 Jun 25 15:56 .
drwxr-xr-x 3 root root  4096 Jun 25 15:53 ..
-rw-r--r-- 1 le   le    1406 Jun 25 15:56 CHANGELOG
drwxr-xr-x 3 le   le    4096 Jun 25 15:56 docs
drwxr-xr-x 8 le   le    4096 Jun 25 15:56 .git
-rw-r--r-- 1 le   le     108 Jun 25 15:56 .gitignore
-rwxr-xr-x 1 le   le   37634 Jun 25 15:56 letsencrypt.sh
-rw-r--r-- 1 le   le    1080 Jun 25 15:56 LICENSE
-rw-r--r-- 1 le   le    3040 Jun 25 15:56 README.md
-rwxr-xr-x 1 le   le    8048 Jun 25 15:56 test.sh
-rw-r--r-- 1 le   le     107 Jun 25 15:56 .travis.yml

Для работы скрипту нужна папка, куда он будет складывать файлы для валидации доменов.

По умолчанию скрипт настроен использовать папку

/opt/letsencrypt/.acme-challenges

и будет падать с ошибкой, если такой папки нет.

Так же желательно создать конфиг с нужными параметрами. Параметры для работы скрипт пытается брать из файла

/opt/letsencrypt/config

. По умолчанию файла нет и скрипт использует значения по умолчанию, но есть хорошо документированный конфиг в папке с документацией, который можно взять за основу.

Создаем папку и копируем конфиг

$ mkdir /opt/letsencrypt/.acme-challenges
$ cp /opt/letsencrypt/docs/examples/config /opt/letsencrypt/config

Чтобы посмотреть, с какими значениями работает скрипт, его можно вызвать с ключем

--env

$ /opt/letsencrypt/letsencrypt.sh --env
# letsencrypt.sh configuration
#
# !! WARNING !! No main config file found, using default config!
#
declare -- CA="https://acme-v01.api.letsencrypt.org/directory"
declare -- LICENSE="https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2021.pdf"
declare -- CERTDIR="/opt/letsencrypt/certs"
declare -- CHALLENGETYPE="http-01"
declare -- DOMAINS_TXT="/opt/letsencrypt/domains.txt"
declare -- HOOK=""
declare -- HOOK_CHAIN="no"
declare -- RENEW_DAYS="30"
declare -- ACCOUNT_KEY="/opt/letsencrypt/accounts/aHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2RpcmVjdG9yeQo/account_key.pem"
declare -- ACCOUNT_KEY_JSON="/opt/letsencrypt/accounts/aHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2RpcmVjdG9yeQo/registration_info.json"
declare -- KEYSIZE="4096"
declare -- WELLKNOWN="/opt/letsencrypt/.acme-challenges"
declare -- PRIVATE_KEY_RENEW="yes"
declare -- OPENSSL_CNF="/usr/lib/ssl/openssl.cnf"
declare -- CONTACT_EMAIL=""
declare -- LOCKFILE="/opt/letsencrypt/lock"

Описание некоторых параметров

CA

— какой удостоверяющий центр использовать. Их, как минимум два — боевой (по умолчанию) и

тестовый

. Дело в том, что у боевого есть

разные ограничения

по частоте запросов и количеству доменов. В эти ограничения легко упереться при тестировании. Поэтому я рекомендую для тестовых запусков указать тестовый центр. Он работает так же, как боевой, просто генерирует невалидные сертификаты.

Вот тестовый CA:

CA="https://acme-staging.api.letsencrypt.org/directory"

CERTDIR

— папка для сертификатов. Внутри неё отельные папки по имени хоста. А в этих папках уже сертификаты для каждого хоста. Нужно будет настроить nginx читать сертификаты из этих папок (см. ниже).

DOMAINS_TXT — список доменов. Одна строчка — один сертификат. В одной строчке может быть несколько доменов, тогда создается один сертификат для них. Скрипт берет первый домен, как название сертификата, а остальные домены указывает, как дополнительные. Например, для такого файла, скрипт создаст два сертификата: some.domain.com и test.com.
some.domain.com another.domain.net example.domain.org
test.com www.test.org ftp.test.net

HOOK — скрипт, который запускается при различных действиях (при валидации доменов, при генерации сертификатов и т.д.).
Скрипту передаются разные параметры: название операции, пути к новым сертификатам и т.д.
Указание своего скрипта может помочь, если вам нужно выполнять чуть больше действий на каждом шаге.
Например, сертификат нужно разложить на несколько серверов, или нужно проводить валидацию домена через dns, а не через файл.
Скрипт, который ничего не делает, но содержит массу комментариев, лежит по адресу /opt/letsencrypt/docs/examples/hook.sh

RENEW_DAYS — через сколько дней обновлять сертификат. Максимум 90, по умолчанию 30.

CONTACT_EMAIL — рабочий email администратора.

Я рекомендую указать в конфиге свой email в

CONTACT_EMAIL

и на время тестов прописать тестовый

CA

.

Установка и первоначальная настройка скрипта на этом завершены. Теперь можно получать сертификаты.

Для начала получим сертифкат для одного домена: letest.lexore.net
В nginx для теста сделаем простой конфиг виртуального хоста, который будет выводить протокол, http или https.

server {
    listen 80;
    server_name letest.lexore.net;
    location /.well-known/acme-challenge/ { alias /opt/letsencrypt/.acme-challenges/; }

    location / {
         default_type text/plain;
         return 200 "scheme: $scheme";
    }
}

Ключевой параметр:

location /.well-known/acme-challenge/

В папке

/opt/letsencrypt/.acme-challenges/

создаются файлы для подтверждения, что вы управляете сайтом.

Они должны быть доступны по адресу

имя_сайта/.well-known/acme-challenge/

, иначе сертификат не подпишут.

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

В конце скрипт удаляет созданный файл, так что папка не будет захламляться.

Перезагрузим nginx и проверим сайт:

$ curl -i letest.lexore.net
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 Jun 2021 13:13:18 GMT
Content-Type: text/plain
Content-Length: 12
Connection: keep-alive

scheme: http

Теперь нужно прописать имя хоста в domains.txt и запустить сам скрипт

$ echo letest.lexore.net > /opt/letsencrypt/domains.txt
$ /opt/letsencrypt/letsencrypt.sh --cron
# INFO: Using main config file /opt/letsencrypt/config
Processing letest.lexore.net
   Signing domains...
   Creating new directory /opt/letsencrypt/certs/letest.lexore.net ...
   Generating private key...
   Generating signing request...
   Requesting challenge for letest.lexore.net...
   Responding to challenge for letest.lexore.net...
   Challenge is valid!
   Requesting certificate...
   Checking certificate...
   Done!
   Creating fullchain.pem...
   Done!

Сертификат готов, файлы сертификата и ключа лежат в папке “

/opt/letsencrypt/certs/letest.lexore.net

“.

Осталось добавить настройки в nginx. Нужно добавить следующие строки в конфиг виртуального хоста:

listen   443 ssl;
ssl_certificate /opt/letsencrypt/certs/letest.lexore.net/fullchain.pem;
ssl_certificate_key /opt/letsencrypt/certs/letest.lexore.net/privkey.pem;

После перезагрузки nginx, можно пробовать сайт в браузере.

Если в конфиге скрипта был указан тестовый CA, браузер заругается на сертификат.

Про сертификаты:  Список организаций, имеющих сертифицированных «1С:Экспертов по технологическим вопросам»

Но это все равно значит, что скрипт и nginx настроены правильно.

Теперь нужно просто поменять CA в конфиге на боевое значание и запустить скрипт ещё раз, добавив параметр

--force

.

Без этого параметра скрипт не станет заново генерировать сертификат, т.к. ещё не подошел срок устаревания, указанный в конфиге.

le@endor:~$ /opt/letsencrypt/letsencrypt.sh --cron --force
# INFO: Using main config file /opt/letsencrypt/config
Processing letest.lexore.net
   Checking domain name(s) of existing cert... unchanged.
   Checking expire date of existing cert...
   Valid till Sep 24 12:13:00 2021 GMT (Longer than 80 days). Ignoring because renew was forced!
   Signing domains...
   Generating private key...
   Generating signing request...
   Requesting challenge for letest.lexore.net...
   Responding to challenge for letest.lexore.net...
   Challenge is valid!
   Requesting certificate...
   Checking certificate...
   Done!
   Creating fullchain.pem...
   Done!

После запуска скрипта и перезагрузки nginx у сайта появится правильный сертификат.

Сертификат готов, https работает.

Пару слов про несколько доменов.

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

subdomain.letest.lexore.net

.

Запуск скрипта:

$ /opt/letsencrypt/letsencrypt.sh --cron --force
# INFO: Using main config file /opt/letsencrypt/config
Processing letest.lexore.net with alternative names: subdomain.letest.lexore.net
   Checking domain name(s) of existing cert... changed!
   Domain name(s) are not matching!
   Names in old certificate: letest.lexore.net
   Configured names: letest.lexore.net subdomain.letest.lexore.net
   Forcing renew.
   Checking expire date of existing cert...
   Valid till Sep 24 12:48:00 2021 GMT (Longer than 80 days). Ignoring because renew was forced!
   Signing domains...
   Generating private key...
   Generating signing request...
   Requesting challenge for letest.lexore.net...
   Requesting challenge for subdomain.letest.lexore.net...
   Responding to challenge for letest.lexore.net...
   Challenge is valid!
   Responding to challenge for subdomain.letest.lexore.net...
   Challenge is valid!
   Requesting certificate...
   Checking certificate...
   Done!
   Creating fullchain.pem...
   Done!

Правка конфига nginx, перезапуск, и вот новый сертификат работает уже на два домена.

Домены не обязаны быть как-то связаны, можно сделать один домен для domain.com и ftp.example.net.

Максимум можно указать

100 доменов

в одном сертификате.

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

Правда, этот сертификат придется пересоздавать на каждый новый домен в списке, и можно упереться в лимиты.

А теперь самое приятное — автоматизация.
Для того, чтобы скрипт сам обновлял все сертификаты из файла domains.txt и вы забыли про манипуляции руками, нужно добавить одну строчку в крон пользователя le:

0 1 * * * /opt/letsencrypt/letsencrypt.sh --cron

Таким образом, алгоритм перевода последующих сайтов на https:

Это не единственный способ автоматизации, многие клиенты letsencrypt позволяют свести всю работу к запуску одного скрипта по крону.
Данный скрипт мне понравился за простоту- всю работу делает один скрипт на bash.
А так же, за свои дополнительные возможности — кроме простой автоматизации, он из коробки поддерживает «сложную» автоматизацию, запуск своих скриптов и переопределение параметров.
Например, я уже упомянул про параметр HOOK в конфиге, который позволяет запускать свой скрипт.
Так же из коробки есть параметр CONFIG_D — папка, в которой будут запускаться все .sh скрипты для переопределения параметров основного конфига.
Плюс, поддержка разных «аккаунтов» через указание разных ACCOUNTDIR — папок с приватными ключами для подписи запросов.
Мне кажется, это позволит использовать скрипт в больших и сложных инфраструктурах.

Процесс подписи кода.

1. Издатель (разработчик) запрашивает Code Signing сертификат у центра сертификации
2. Используя SIGNCODE.EXE или другую утилиту для подписи кода издатель, cоздает хеш кода, используя алгоритмы MD5 или SHA
3. Кодирует хеш, с помощью приватного ключа
4. Создает пакет, который включает в себя: код, зашифрованный хеш и сертификат издателя

Процесс проверки подписанного кода.

1. Пользователь скачивает или устанавливает подписанное ПО и платформа или система пользователя проверяет сертификат издателя, который подписан корневым приватным ключем центра сертификации
2. Система запускает код, используя тот же самый алгоритм создания хеша, как издатель и создает новый хеш
3. Используя публичный ключ издателя, который содержится в сертификате, система расшифровывает зашифрованный хеш
4. И сравнивает между собой 2 хеша

Сертификаты для устройств

Теперь нам нужно создать сертификат конечного пользователя или сервера и подписать его корневым сертификатом, что мы создали в предыдущем разделе. Основная проблема для меня была в том, что мое устройство имеет несколько сетевых интерфейсов, которые подключаются в разные сети и, соответственно, имеют разные IP адреса.

Создать самоподписанный сертфикат типа code signing для подписывания кода

В PoweShell 3.0 командлет New-SelfSifgnedCertificate позволял генерировать только SSL сертификаты, которые нельзя было использоваться для подписывания кода драйверов и приложений (в отличии сертификатов, генерируемых утилитой MakeCert).

В версии PowerShell 5 новая версия командлета New-SelfSifgnedCertificate теперь может использоваться для выпуска сертификатов типа Code Signing.

Для создания самоподписанного сертфиката для подписывания кода приложений, выполните команду:

$cert = New-SelfSignedCertificate -Subject “Cert for Code Signing” -Type CodeSigningCert -CertStoreLocation cert:LocalMachineMy

Теперь можно подписать ваш PowerShell скрипт эти сертификатом:

Set-AuthenticodeSignature -FilePath C:PStest_script.ps1 -Certificate $cert

Если при выполнении команды появится предупреждение UnknownError, значит этот сертификат недоверенный, т.к. находится в персональном хранилище сертификатов пользователя.

Нужно переместить его в корневые сертификаты (не забывайте периодически проверять хранилище сертификатов Windows на наличие недоверенных сертфикатов и обновлять списки корневых сертификатов):

Сценарий использования ssl во встраиваемых системах

Приведу для примера один из возможных сценариев использования сертификатов во встраиваемых системах. Этот сценарий не требует покупки сертификатов, но имеет ограничения в использовании. Итак,

1. Нам потребуется создать самоподписанный корневой сертификат, в этом случае мы станем сами себе центром сертификации.
2. Далее нам нужно создать сертификат для нашего web-интерфейса и подписать его корневым сертификатом, созданным на первом шаге.
3. Этот сертификат мы помещаем в память  нашей встраиваемой системы где его сможет найти встроенный веб-сервер.
4. Всем пользователям веб-интерфейса мы должны выдать наш корневой сертификат, но не приватный ключ.
5. Пользователи веб-интерфейса должны импортировать наш корневой сертификат в свои веб-браузеры на всех компьютерах с которых предполагается вход на веб-интерфейс.

Особо отмечу

, что этот сценарий

не является безопасным

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

Часть 2: создание в iis сайта для доступа к серверу worldclient

Примечание 1:

если у вас используется встроенный в MDaemon сервер WorldClient и он уже монопольно сидит на порту 80, то можете смело пропустить эту часть и перейти сразу к части 3.

Примечание 2: ‘Host name’ сайта должно быть таким-же, как полное доменное имя хоста MDaemon, по которому он доступен из интернета.

Часть 5: удаление всех следов «тестовой» жизнедеятельности

Если этого не сделать, то скрипт ещё пару месяцев будет продолжать выдавать нам «фальшивый» сертификат, несмотря на то, что мы внесли в скрипт нужные изменения.

Часть 7: первый «боевой» запуск

Выполняем старт скрипта вручную:

1. Выделяем только-что созданную задачу в списке.
2. Нажимаем ‘Run’ в правой панели Actions’. Никакого окна при этом не откроется.
3. Время от времени рефрешим список задач — чтобы видеть изменения в поле ‘Status’: ‘Status’ должен смениться на ‘Run’. Рефрешим список, пока ‘Status’ снова не станет ‘Ready’.
4. Смотрим результат выполнения скрипта в лог-файле ‘MDaemonLogsLetsEncrypt.log’.

Часть последняя — заключительная

В заключение хочу сказать, что во время написания статьи у меня уже не было доступа к боевому серверу, поэтому все скриншоты делались с виртуальной машины, на которую была установлена ещё более старая версия MDaemon — 13.0.4 — из-за чего внешний вид окон может отличаться от других версий.

Ну вот и всё. Всё что знал — рассказал. Поздравляю всех с наступающим Новым Годом! Здоровья вам и удачи!

Подведем итог

Для выбора сертификата сначала нужно выбрать центр сертификации, который выпускает сертификаты под нужную вам платформу, а дальше выбор по сути сводится к выбору по цене и по известности центра сертификации, зачастую клиенты выбирают те центры сертификации, с которым уже работали ранее.