Mdaemon letsencrypt error the challenge did not complete

Solved - letsencrypt challenge not completing

Pages: [1] 2 3 … 6  All   Go Down

  • 96431 Views

Good Morning,
I have been unsuccessful in getting my serve to complete the challenge for letsencrypt. Here is the output of dehydrated -c

ERROR: Challenge is invalid! (returned: invalid) (result: {
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:unauthorized",
    "detail": "Invalid response from http://www.mercyh.org/.well-known/acme-challenge/FMTvp_V7itHCGh1yK9AjZJv2rmGawZYArY-5r3DpTX4: "u003c!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"u003enu003chtmlu003eu003cheadu003enu003ctitleu003e403 Forbiddenu003c/titleu003enu003c/headu003eu003cbodyu003enu003ch1u003eForbiddenu003c/h1u003enu003cp"",
    "status": 403
  },
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/FgNcud1f0aqdQ7akFN1NyrEz6BkKLGFTHN_HlxC7cUE/43197390",
  "token": "FMTvp_V7itHCGh1yK9AjZJv2rmGawZYArY-5r3DpTX4",
  "keyAuthorization": "FMTvp_V7itHCGh1yK9AjZJv2rmGawZYArY-5r3DpTX4.266BsZK-dHl_Lk8qUZQa6lxP_cNRbxz8lP3lFEP_1Rs",
  "validationRecord": [
    {
      "url": "https://www.mercyh.org/.well-known/acme-challenge/FMTvp_V7itHCGh1yK9AjZJv2rmGawZYArY-5r3DpTX4",
      "hostname": "www.mercyh.org",
      "port": "443",
      "addressesResolved": [
        "63.245.178.234"

the httpd error_log file simply gives the following entry:

(13)Permission denied: access to /.well-known/acme-challenge/fxiFyqyaNhfd7DQVFHfl2LgUdOQr-AZOyCuC10UCK-Q denied
(13)Permission denied: access to /.well-known/acme-challenge/cVQNMIHnlXVdH0qUUpcMyQ8xlbU-4eMmT-pr6GFE7FE denied
(13)Permission denied: access to /.well-known/acme-challenge/GdfqjRvzhE4viN5pY7xQzdcEJan-veIi9FOvBxkPz68 denied

can anyone give me a pointer toward what I am doing wrong?

« Last Edit: December 10, 2019, 08:53:38 AM by TerryF »


Logged

What are the permissions on /home/e-smith/files/ibays/Primary/html/.well-known and /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge?


Logged

……

Also are you running the commands as root ? If not try as root.


Logged

I knew it was simple. I had no domains hosted on Primary and somewhere down the line, the permissions on primary got skewed. I never even considered that the Primary Ibay was used here.

correcting the permissions made the challenge work perfectly.

THANKS,

Royce


Logged

guest22

I never even considered that the Primary Ibay was used here.

In my opinion (and some others) that remains a problem, letsencrypt demanding http access to the Primary domain.


Logged

In my opinion (and some others) that remains a problem, letsencrypt demanding http access to the Primary domain.

If you don’t want to give http access to your SME server (HTTPS access is OK, because SME implements a HTTP -> HTTPS redirect), you can always use DNS validation instead—but you’ll have to script it yourself.


Logged

……

guest22

AFAIK and in my experience (see also comments from Stafan) http is required by letsencrypt. e.g. having forced the Primary ibay inot httpS only, letsencrypt will fail.


Logged

AFAIK and in my experience (see also comments from Stafan) http is required by letsencrypt. e.g. having forced the Primary ibay inot httpS only, letsencrypt will fail.

From my own experience, this is incorrect.  When an ibay (including Primary) is set to HTTPS-only on SME, the system implements a HTTP -> HTTPS redirect—if you connect to http://yourhostname, it’s redirected to https://yourhostname.  The Let’s Encrypt servers will follow this redirect and authenticate without issue.  Now, if you have a firewall blocking access on port 80, the LE servers won’t be able to validate, but that isn’t an SME setting.  It also isn’t generally a good idea—even if you want your server to be SSL-only, people are going to (attempt to) connect from the outside using HTTP.

But, again, if you don’t want to open your SME server to web access, you can use DNS validation instead.  You’ll need to write some custom template fragments for that, though.  See https://github.com/lukas2511/dehydrated/blob/master/docs/dns-verification.md and https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hooks for more information on implementing DNS validation with dehydrated.

Edit:  There’s a third option, if the hostname for which you’re seeking the cert resolves to a different machine: deploy the challenge file automatically to the appropriate host.  In the simplest case, the contrib can handle the necessary automation.  See https://wiki.contribs.org/Letsencrypt#Obtaining_certificates_for_a_private_SME_Server.  More complicated cases will probably need custom template fragments.

« Last Edit: June 11, 2017, 04:02:34 AM by DanB35 »


Logged

……

I actually set the server to force SSL while I was trying to troubleshoot. The logs showed letsencrypt following the redirect but then failing with the permissions error. I made the assumption that it was following the domain direct on the server to the ibay where the site is hosted. I never considered that it was accessing the primary ibay and the paths in both the letsencrypt reply and the httpd logs were not complete. Thanks again for pointing me in the right direction!!!


Logged

Letsencrypt effectively HAS to follow a http redirect or logically you could not disable http access.

Remember that (if you are sensible) http would be disabled once you have your certs installed, but the auto renew still works….

All my boxes with letsencrypt have http disabled/redirected and I have zero issues.


Logged

To be completely clear, every time Let’s Encrypt issues a certificate (which will be about every 60 days if you’re following their recommendations), they must validate that you control every hostname for which you’re seeking a cert.  Their servers support three methods of validation:

  • Look for a specific file under http://$FQDN/.well-known/acme-challenge
  • Look for a specific TLS certificate to be served when connecting to https://$FQDN
  • Look for specific DNS TXT records for each hostname sought to be validated

Dehydrated, the client that @ReetP’s contrib works with, supports only the first and third challenges, and the contrib supports only the first—it wouldn’t be possible to come up with a consistent set of instructions for the third, since we’re all using different DNS hosts.  That means that, any time you’re seeking to issue or renew a certificate, the Let’s Encrypt servers must be able to connect to your hostname on port 80.  They’ll happily follow a redirect, but they must still be able to connect on port 80.  If you don’t want port 80 open to the Internet, yes, this is a problem for you.


Logged

……

However HF might have a point here, why put .well-known in the Primary ibay, it could be somewhere else and still work.

We could move it to /var/www/.well-known and make the httpd.conf template fragment to point http://mydomain.com/.well-known to it.
This would avoid customized chmod or chown on the Primary ibay to prevent apache to read the content of .well-known.
Also it would keep it away from the eyes of users not knowing what this is.


Logged

If you have more than domain they may point to different ibays….

I need to check my configs to demonstrate this but I think this proposal may break some stuff for me at least.

I think it is the due to a situation Tony showed me some while back regarding domains but need to check my configs.

Also if we start moving stuff to /var/www then either it should all go in there, or stay the way we are. Splitting locations could confuse some just as easily as helping others


Logged

why put .well-known in the Primary ibay,

Because the Primary ibay is the default web root of the SME Server, and therefore the logical place to put anything that’s going to be served out of the web root.  It doesn’t have to go there, of course—neither dehydrated nor the Let’s Encrypt servers care where on the filesystem the challenge file goes, as long as it’s served in response to a request for /.well-known/acme-challenge/whatever—but it does seem like the most logical place to put it.  Why not put it there?


Logged

……

If you have more than domain they may point to different ibays….

if a domain point to an ibay else than Primary, then it is already not pointing tothe Primary and hence there is already a fragment making the url well-known to point to the folder in the ibay, it could then point to somewhere else.

I need to check my configs to demonstrate this but I think this proposal may break some stuff for me at least.

go ahead, indeed i feel some tweaks might, at least with use of the hook script migh break

I think it is the due to a situation Tony showed me some while back regarding domains but need to check my configs.

Also if we start moving stuff to /var/www then either it should all go in there, or stay the way we are. Splitting locations could confuse some just as easily as helping others

well here we have a software indepedant from user data, and with nothing to backup from it, its place should be naturally out of /home/. Another example is horde that sit for a while in /home, but should be moved to a standard path, and has been for 10. Phpmyadmin is not either in /home….

So user accessible web data are kept in /home/e-smith, while software path, not needed to be accessible by the user are out of it.

Because the Primary ibay is the default web root of the SME Server, and therefore the logical place to put anything that’s going to be served out of the web root.  It doesn’t have to go there, of course—neither dehydrated nor the Let’s Encrypt servers care where on the filesystem the challenge file goes, as long as it’s served in response to a request for /.well-known/acme-challenge/whatever—but it does seem like the most logical place to put it.  Why not put it there?

Because this does not need to be accessible by the user. It is only for automatized access for cert renewal. I think it was placed in the Primary  ibay by John in the first time only because it was conveniant while developing the contribution and did avoid to play with the handling of virtual path vs absolute server path, but when it was time to handle also domain pointing to other ibays he had to play with alias or other means to point to the current absolute path of .well-known.


Logged

Pages: [1] 2 3 … 6  All   Go Up

  1. Koozali.org: home of the SME Server
  2. Obsolete Releases
  3. SME 9.x Contribs
  4. Topic:
    Solved — letsencrypt challenge not completing

Источник

Время прочтения
10 мин

Просмотры 11K


Всем привет!

Некоторое время назад ко мне обратился один мой хороший знакомый с внезапно образовавшейся у него проблемой и попросил помочь в её решении. Проблема заключалась в следующем: организация, в которой он работал, имела у себя Windows-сервер с поднятым на нём почтовиком MDaemon от компании Alt-N Technologies. Пару лет назад на этот почтовик был установлен SSL-сертификат StartSSL от компании StartCom. И всё работало вполне себе нормально, каши не просило, как вдруг от StartCom пришло грустное письмо, информирующее о том, что скоро всем их сертификатам придёт полный и безоговорочный кирдык. Мол, спасайтесь — кто может, пока не бомбануло. Сегодня я расскажу вам, как мы спасались — глядишь, кому-нибудь эта информация окажется полезной.

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

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

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

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

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

Исходные данные

  • Сервер под управением ОС Windows Server 2008 R2.
  • Почтовый сервер MDaemon версии 13.6.3.
  • На этом же сервере поднят IIS, обслуживающий корпоративный сайт организации.
  • MDaemon использовал собственный встроенный WEB-сервер WorldClient, который был доступен из интернета через порт 3000.

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

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

  • Наличие оболочки PowerShell версии 3.0.
  • Наличие установленного фреймворка Microsoft .NET версии не ниже 4.0.
  • Наличие установленного пакета IIS Management Scripts and Tools.
  • Из интернета через порт 80 должен быть доступен WorldClient сервера — либо напрямую, либо через IIS.

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

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

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

Во-первых, практически в самом начале скрипта была реализована проверка на то, что параметр ‘EnableWCServer’ в файле ‘Mdaemon.ini’ установлен в ‘Yes’. И если это было не так, то скрипт немедленно завершал свою работу с выдачей сообщения о критической ошибке ‘Error: WorldClient must be enabled’. Но, как это ни странно, в нашем случае этот параметр был установлен в ‘No’ — несмотря на то, что нами уже была выполнена привязка WorldClient к IIS и WorldClient прекрасно открывался из интернета. Недолго думая, мы отключили эту проверку, закомментарив её в скрипте. Это позволило скрипту продолжить работу.

Во-вторых, на этом же сервере был поднят корпоративный сайт и к кое-каким страницам этого сайта доступ выполнялся по протоколу https с использованием самоподписанного сертификата. А старые Windows-сервера предполагают, что к одному IP может быть привязан только один сертификат. Мы наступили на эти грабли в самом конце пути — когда сертификат от LE уже успешно получался, но никак не мог прибиндиться к адресу 0.0.0.0. В итоге проблема была решена быстрым, но несколько кривоватым способом: WorldClient был отсажен на отдельный IP-адрес (благо он был в наличии) и опять же пришлось править скрипт — в список его входных параметров был добавлен IP-адрес, к которому нужно было привязывать сертификат. А так как привязка WorldClient к IIS была уже полностью выполнена, то мы не стали запускать собственный WEB-сервер MDaemon-а и оставили всё как есть.

Поехали.

Часть 1: предварительная подготовка

  1. Любым известным вам способом делаем бакап сервера!
  2. Устанавливаем .NET версии выше или равной 4.0.
  3. Добавляем Role Services: идём в ‘Control Panel’ -> ‘Administrative Tools’ -> ‘Server Manager’ -> ‘Roles’ и нажимаем на линк ‘Add Role Services’.

    Ставим крыжики на:

    • Web Server/Application Development/ISAPI Extensions
    • Web Server/Application Development/ISAPI Filters
    • Management Tools/IIS Management Scripts and Tools

    Нажимаем ‘Next’, ну и так далее.

  4. Устанавливаем Windows Management Framework 3.0 — это установит в систему PowerShell версии 3.0 (см. раздел ‘Обязательные требования’):
    • Скачиваем WMF 3.0 с сайта Microsoft.
    • Устанавливаем нужный WMF. Для Windows Server 2008 R2 это ‘Windows6.1-KB2506143-x64.msu’.
    • Перезагружаем сервер.

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

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

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

Чтобы узнать полное доменное имя хоста MDaemon: запускаем GUI Mdaemon, идём в меню: ‘Настройка’ -> ‘Первичный домен/серверы’ -> ‘Домен и серверы по умолчанию’ -> ‘Домен’ и смотрим поле ‘Полное доменное имя хоста’.

Итак, приступим. Запускаем IIS-менеджер и добавляем в нём новый сайт:

  1. В поле ‘Site name’ вводим название сайта — какое нравится.
  2. В поле ‘Physical path’ вводим путь к папке HTML World-клиента.
  3. В поле ‘Host name’ прописываем полное доменное имя хоста (см. примечание 2 выше).
  4. В поле ‘IP-address’ оставляем ‘All unassigned’, если интерфейс используется монопольно, или выбираем из списка IP, принадлежащий почтовику.
  5. Поля ‘Type’ и ‘Port’ оставляем как есть — ‘http’ и ’80’, соответственно.

Редактируем список дефолтных документов сайта — заходим в подраздел ‘Default Document’:

  1. Очищаем весь список.
  2. Добавляем документ ‘WorldClient.dll’: в правой панели ‘Actions’ нажимаем ‘Add…’ и в поле ‘Name’ набираем ‘WorldClient.dll’.
  3. Добавляем документ ‘MDSyncML.dll’: в правой панели ‘Actions’ нажимаем ‘Add…’ и в поле ‘Name’ набираем ‘MDSyncML.dll’.
  4. Ставим ‘WorldClient.dll’ первым в списке: выделяем его и нажимаем ‘Move Up’ в правой панели ‘Actions’.

Переходим в раздел ‘Handler Mappings’:

  1. Редактируем ‘Feature Permissions’: в правой панели ‘Actions’ нажимаем на ‘Edit Feature Permissions…’ и ставим все крыжики — ‘Read’, ‘Script’ и ‘Execute’.

  2. Находим в списке ‘ISAPI-dll’ и заходим в него.

  3. В поле ‘Request path’ пишем ‘WorldClient.dll’.
  4. В списке ‘Module’ выбираем ‘IsapiModule’.
  5. В поле ‘Executable (optional)’ указываем путь к WorldClient.dll.

  6. Добавляем новый обработчик: в правой панели ‘Actions’ нажимаем ‘Add Module Mapping…’

  7. В поле ‘Request path’ пишем ‘MDSyncML.dll’.
  8. В списке ‘Module’ выбираем ‘IsapiModule’.
  9. В поле ‘Executable (optional)’ указываем путь к MDSyncML.dll.
  10. В поле ‘Name’ пишем что-нибудь членораздельное. Например, ‘SyncML-ISAPI’.

Редактируем ‘MIME Types’ — если этого не сделать, то робот LetsEncrypt не сможет получить от нас файл без расширения:

  1. Переходим в раздел ‘MIME Types’.
  2. В правой панели ‘Actions’ нажимаем ‘Add…’.
  3. В поле ‘File name extension’ пишем точку.
  4. В поле ‘MIME type’ пишем ‘text/plain’.

Редактируем ‘Application Pool’, автоматически созданный при создании нашего сайта:

  1. Идём в ‘Application Pools’ -> ‘MDaemon WorldClient’ -> ‘Advanced Settings…’.
  2. В секции ‘Process Model’ меняем ‘Identity’ на ‘Network Service’.
  3. Если операционка — 64-разрядная, то в секции ‘General’ меняем ‘Enable 32-Bit Applications’ на ‘True’.

Закрываем консоль. IIS настроен.

Далее, даём пользователям ‘IUSR’ и ‘NETWORK SERVICE’ полный доступ к папке MDaemon:

  1. Идём в проводник, открываем ‘Properties’ папки ‘MDaemon’, переходим на закладку ‘Security’, нажимаем ‘Edit’.
  2. Нажимаем ‘Add’ -> ‘Advanced’ -> ‘Find Now’ — выделяем в списке ‘Search Results’ пользователя ‘IUSR’, нажимаем ‘OK’.
  3. Ставим крыжик ‘Full control’ в списке ‘Permissions for IUSR’.
  4. Нажимаем ‘Add’ -> ‘Advanced’ -> ‘Find Now’ — выделяем в списке ‘Search Results’ пользователя ‘NETWORK SERVICE’, нажимаем ‘OK’.
  5. Ставим крыжик ‘Full control’ в списке ‘Permissions for NETWORK SERVICE’.
  6. Закрываем оба окна нажатием на ‘OK’.

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

Часть 3: установка и настройка скриптов LetsEncrypt

  1. Скачиваем архив со скриптами отсюда и распаковываем его в корень папки ‘MDaemon’. Важное примечание: в скрипте основной сервер LetsEncrypt заменён на тестовый — чтобы предотвратить бан из-за многократных попыток получить сертификат во время процесса отладки. В следующей части будет написано — как переключиться на основной сервер.

  2. Дописываем в переменную окружения ‘PSModulePath’ путь к модулям, используемым скриптом:

    • Идём в ‘Control Panel’ -> ‘System’ -> ‘Advanced system settings’ -> ‘Advanced’ -> ‘Environment Variables’.
    • Ищем в списке ‘System Variables’ переменную ‘PSModulePath’.
    • Дописываем через ‘;’ в её конец путь к папке ‘Modules’, находящейся внутри папки ‘LetsEncrypt’. В моём случае такой: ‘c:MDaemonLetsEncryptModules’
    • Перелогиниваемся.
  3. Запускаем консоль cmd.
  4. Запускаем скрипт letsencrypt.ps1 командой: 
    powershell -ExecutionPolicy ByPass -File c:mdaemonletsencryptletsencrypt.ps1

    Здесь параметром ‘File’ задаётся путь к скрипту.

    Можно использовать дополнительные параметры:

    • -IISSiteName «MDaemon WorldClient»
      Если WorldClient работает через IIS, то этим параметром нужно указать скрипту имя сайта WorldClient (см. часть 2)
    • -WCIPAddress xxx.xxx.xxx.xxx
      Этим параметром задаётся IP-адрес, к которому скрипт должен прибиндить полученный сертификат. Его нет необходимости указывать, если к порту 443 не привязано никаких других сертификатов.
    • -To «admin@server.com»
      Этим параметром задаётся имейл, на который будет отправлен лог работы скрипта в случае возникновения какой-либо ошибки.

    Смотрим в окно консоли — скрипт должен выполниться без ошибок.

    Если что-нибудь пойдёт не так — вам придётся разобраться с этой проблемой самостоятельно.

    Если всё выполнилось успешно, то можно попробовать зайти в WorldClient браузером по протоколу https: так как мы использовали тестовый сервер LetsEncrypt, то браузер должен выругаться на сертификат сайта сообщением ‘SEC_ERROR_UNKNOWN_ISSUER’.

    Кстати говоря, помните — я рассказывал про «грабли» с параметром ‘EnableWCServer’ в файле ‘Mdaemon.ini’ — что при использовании связки с IIS он установлен в ‘No’? Так вот после успешной отработки скрипта этот параметр изменился на ‘Yes’. Однако произошло это несколько поздновато, поэтому раскомментаривать проверку этого параметра в скрипте мы не стали.

Часть 4: перевод скрипта в «боевой режим»

  1. Открываем в текстовом редакторе скрипт letsencrypt.ps1 из папки LetsEncrypt.
  2. Находим в нём строки: 
    
#Initialize-ACMEVault -ErrorVariable LogText
Initialize-ACMEVault -BaseURI https://acme-staging.api.letsencrypt.org/ -ErrorVariable LogText
  3. Первую строку раскомментариваем, а вторую закомментариваем: 
    
Initialize-ACMEVault -ErrorVariable LogText
#Initialize-ACMEVault -BaseURI https://acme-staging.api.letsencrypt.org/ -ErrorVariable LogText
  4. Сохраняем скрипт.

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

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

  1. Удаляем тестовый сертификат из MDaemon:

    • Запускаем GUI MDaemon и идём в меню ‘Безопасность’ -> ‘Параметры безопасности’ -> ‘SSL & TLS’.
    • В списке сертификатов выделяем наш тестовый сертификат (у него в поле ‘Отправитель’ будет ‘Fake LE Intermediate X1’) и нажимаем кнопку ‘Удалить’ под списком.
    • Если список сертификатов стал пуст — придётся создать самоподписанный сертификат, иначе MDaemon будет ругаться при попытке закрыть окно.
  2. Удаляем хранилище ключей, созданное скриптом: если работали под админским аккаунтом, то идём в ‘c:ProgramData’, а если под пользовательским — в ‘C:Usersимя_пользователяAppDataLocal’ и удаляем оттуда папку ‘ACMESharp’ вместе со всем содержимым.
  3. Удаляем XML-файл, созданный скриптом: идём в папку ‘MDaemonLetsEncrypt’ и удаляем файл LetsEncrypt.XML оттуда.
  4. Удаляем тестовый сертификат: идём в папку ‘MDaemonPem’, находим там сертификат (файл с расширением ‘pfx’) и удаляем его.

Часть 6: Настройка запуска скрипта по расписанию

  1. Идём в ‘Control Panel’ -> ‘Administrative Tools’ -> ‘Computer Management’ -> ‘System Tools’ -> ‘Task Scheduler’ -> ‘Task Scheduler Library’.
  2. Создаём новую задачу: нажимаем ‘Create Task…’ в правой панели ‘Actions’.

  3. На закладке ‘General’:

    • В поле ‘Name’ пишем имя задачи — произвольно по вашему желанию.
    • В подразделе ‘Security Options’ выбираем пункт ‘Run whether user is logged on or not’.

  4. На закладке ‘Triggers’:

    • Нажимаем кнопку ‘New…’ — откроется окно ‘New Trigger’.
    • В списке ‘Begin the task’ выбираем ‘On a schedule’.
    • Устанавливаем подходящую периодичность запуска: например, раз в неделю по воскресеньям. Скрипт при каждом старте будет проверять — сколько сертификату осталось жить: и если меньше месяца, то обновит его.

  5. На закладке ‘Actions’:

    • Нажимаем кнопку ‘New’ — откроется окно ‘New Action’.
    • В списке ‘Action’ выбираем ‘Start a program’.
    • В поле ‘Program/script’ пишем ‘powershell’.
    • В поле ‘Add arguments (optional)’ пишем ‘-ExecutionPolicy ByPass -File c:MDaemonLetsEncryptletsencrypt.ps1’. В хвост строки дописываем требуемые дополнительные параметры (см. часть 3).
  6. На закладке ‘Conditions’ ставим крыжики по своему усмотрению.

  7. На закладке ‘Settings’ ставим крыжики:

    • Allow task to be run on demand
    • Stop the task if it runs longer than 1 hour
    • If the running task does not end when requested, force it to stop
  8. Нажимаем кнопку ‘OK’. Вводим пароль текущего пользователя.

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

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

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

Если, судя по лог-файлу, всё прошло успешно, значит дело сделано — сертификат получен и можно проверять работоспособность приёма/отправки почты по защищённому каналу. И да, не забудьте зайти в почтовик браузером по протоколу https — чтобы убедиться, что WorldClient тоже работает без проблем.

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

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

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

Источник

Prior to placing the issue, please check following: (fill out each checkbox with a X once done)

  • I understand that not following below instructions might result in immediate closing and deletion of my issue.
  • I have understood that answers are voluntary and community-driven, and not commercial support.
  • I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description of the bug: What kind of issue have you exactly come across?

Unable to complete cert request which then loops after 30 minutes

Reproduction of said bug: How exactly do you reproduce the bug?

  1. Start the acme-mailcow container
  • In case of WebUI issue, I have tried clearing the browser cache and the issue persists.
  • I do run mailcow on a Synology, QNAP or any other sort of NAS.

System information

Tue Oct  1 17:42:28 BST 2019 - Waiting for Docker API...OK
Tue Oct  1 17:42:28 BST 2019 - Waiting for database... Uptime: 82992  Threads: 29  Questions: 163533  Slow queries: 0  Opens: 60  Flush tables: 1  Open tables: 52  Queries per second avg: 1.970
OK
Tue Oct  1 17:42:28 BST 2019 - Waiting for Nginx... OK
Tue Oct  1 17:42:28 BST 2019 - Waiting for domain table... OK
Tue Oct  1 17:42:28 BST 2019 - Initializing, please wait... 
Tue Oct  1 17:42:28 BST 2019 - Using existing domain key /var/lib/acme/acme/key.pem
Tue Oct  1 17:42:28 BST 2019 - Using existing Lets Encrypt account key /var/lib/acme/acme/account.pem
Tue Oct  1 17:42:28 BST 2019 - Detecting IP addresses... OK
Validated CAA for parent domain fred.it
Tue Oct  1 17:42:47 BST 2019 - Found A record for autodiscover.fred.it: 8.8.8.8
(skipping check, returning 0)
Tue Oct  1 17:42:47 BST 2019 - Confirmed A record 8.8.8.8, adding SAN
Tue Oct  1 17:42:47 BST 2019 - Found A record for autoconfig.fred.it: 8.8.8.8
(skipping check, returning 0)
Tue Oct  1 17:42:47 BST 2019 - Confirmed A record 8.8.8.8, adding SAN
Tue Oct  1 17:42:47 BST 2019 - Found A record for mail.fred.it: 8.8.8.8
(skipping check, returning 0)
Tue Oct  1 17:42:47 BST 2019 - Confirmed A record 8.8.8.8
Tue Oct  1 17:42:48 BST 2019 - Found new SAN autoconfig.fred.it autodiscover.fred.it
Tue Oct  1 17:42:48 BST 2019 - Creating backups in /var/lib/acme/backups/2019-10-01_17_42_48/ ...
Parsing account key...
Parsing CSR...
Found domains: autodiscover.fred.it, mail.fred.it, autoconfig.fred.it
Getting directory...
Directory found!
Registering account...
Already registered!
Creating new order...
Order created!
Verifying autoconfig.fred.it...
Traceback (most recent call last):
  File "/usr/bin/acme-tiny", line 10, in <module>
    sys.exit(main())
  File "/usr/lib/python3.7/site-packages/acme_tiny.py", line 194, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
  File "/usr/lib/python3.7/site-packages/acme_tiny.py", line 149, in get_crt
    raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
ValueError: Challenge did not pass for autoconfig.fred.it: {'identifier': {'type': 'dns', 'value': 'autoconfig.fred.it'}, 'status': 'invalid', 'expires': '2019-10-08T16:32:17Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:unauthorized', 'detail': 'Invalid response from http://autoconfig.fred.it/.well-known/acme-challenge/ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE [8.8.8.8]: 404', 'status': 403}, 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/587523149/Ul9K8Q', 'token': 'ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE', 'validationRecord': [{'url': 'http://autoconfig.fred.it/.well-known/acme-challenge/ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE', 'hostname': 'autoconfig.fred.it', 'port': '80', 'addressesResolved': ['8.8.8.8'], 'addressUsed': '8.8.8.8'}]}, {'type': 'dns-01', 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/587523149/zP849w', 'token': 'ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE'}, {'type': 'tls-alpn-01', 'status': 'invalid', 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/587523149/zsk52w', 'token': 'ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE'}]}
Tue Oct  1 17:42:55 BST 2019 - Retrying in 30 minutes...

I’ve tried each of the following settings but the HTTP validation always fails.

# Skip running ACME (acme-mailcow, Let's Encrypt certs) - y/n
SKIP_LETS_ENCRYPT=n
# Skip IPv4 check in ACME container - y/n
SKIP_IP_CHECK=n
# Skip HTTP verification in ACME container - y/n
SKIP_HTTP_VERIFICATION=n

Further information (where applicable):

Question Answer
My operating system Ubuntu 19.04
Is Apparmor, SELinux or similar active? Don’t think so
Virtualization technlogy (KVM, VMware, Xen, etc) None
Server/VM specifications (Memory, CPU Cores) 8GB RAM, 3rd Gen Intel
Docker Version (docker version) 19.03.2
Docker-Compose Version (docker-compose version) 1.23.2, build 1110ad01
Reverse proxy (custom solution) Traefik 2.0.1

I’ve changed the domain name and IP address of the above log

Traefik v2.0.1 is set to redirect http to https.

When I goto http://autoconfig.fred.it/.well-known/acme-challenge/ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE it redirects to https://autoconfig.fred.it/.well-known/acme-challenge/ejG-wVfy85jMG_do9Y-JVMin2oJT_nsP7Jybc-2P0IE and I can see the file correctly.

I understand the HTTP challenge is ok being redirected to HTTPS as per https://letsencrypt.org/docs/challenge-types/

This maybe the same issue as #2748 but I’ve checked the Nginx config and I don’t have the extra section which has been fixed here #2736

I’m running the latest Mailcow version, which has just been updated this morning using the update script.

Источник

  • #1

I’m getting problems with LetsEncrypt, which is now failing to renew existing SSL certificates for a number of domains. Here is one example error message in system messages relating to one of the domains.

Subject: Error during automated certificate renewal for exampledomain.com
grep: /usr/local/directadmin/data/users/admin/user.conf: No such file or directory
2020/07/07 00:16:05 [INFO] acme: Registering account for [email protected]
2020/07/07 00:16:05 Could not complete registration
acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: contact email «[email protected]» has invalid domain : Domain name needs at least one dot, url:
Certificate generation failed.
<br>

When I manually try and create the certificate from scratch whilst logged into that domain, I get this:-

Cannot Execute Your Request​

Details
grep: /usr/local/directadmin/data/users/admin/user.conf: No such file or directory
2020/07/07 02:22:47 [INFO] acme: Registering account for [email protected]
2020/07/07 02:22:47 Could not complete registration
acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: contact email «[email protected]» has invalid domain : Domain name needs at least one dot, url:
Certificate generation failed.​

Reading another post from 2016, I tried to rebuild LetsEncrypt, but still get the problem. I used this command set:

cd /usr/local/directadmin/custombuild
./build update
./build letsencrypt

Still getting the errors. I have no idea what’s causing this, and would appreciate some advice, please?

Regards

  • #2

Reading the error, I notice the line
grep: /usr/local/directadmin/data/users/admin/user.conf: No such file or directory

When I setup the server, I changed the name of the admin user to something else so it wasn’t easy to guess the main admin user. LetsEncrypt has not had a problem with this until around last week when the errors started when it came to renewal. It seems to be looking for the user.conf in the admin folder, and my admin username is different. Likewise the admin folder in /usr/local/directadmin/data/users/ is also different.

Any thoughts?

Last edited: Jul 6, 2020

  • #3

Emailadres / user for that letsencrypt domain account in DA working searcg Forum SMTALK did write react on kind of the same her for a while ago.

If you have ther none, a not working or maybe even admin email but not sure because not in my mind to remember all.

( the letsencrypt needs emailadres that is working)

I Guess we need a howto / help topic for that to solve it afterwards?

Last edited: Jul 7, 2020

  • #4

Hi ikkeben

Thank you for your response and help.

After resetting the email for the main admin user, I am still getting this error when I manually try and create a certificate for a user:

Cannot Execute Your Request​

​

Details
grep: /usr/local/directadmin/data/users/admin/user.conf: No such file or directory
2020/07/07 09:06:32 [INFO] acme: Registering account for [email protected]
2020/07/07 09:06:32 Could not complete registration
acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: contact email «[email protected]» has invalid domain : Domain name needs at least one dot, url:
Certificate generation failed.​

The error is actually different from the one in the link you provided. The error on my server is referring to this file…
/usr/local/directadmin/data/users/admin/user.conf:

This file does not exist, because my admin username is not the standard «admin» name, it was changed during the time I set up the server years ago. LetsEncrypt has been working well up until a week or so ago. DirectAdmin or LetsEncrypt is now assuming all admin users have the name «admin» I think. This is a change from before. (I’m assuming here).

Last edited: Jul 7, 2020

  • #5

Change the admin user’s email address

smtalk


  • #6

May you check if version 2.0.5 solves it? Just use custom_versions.txt for the override, or edit it in versions.txt (md5sum can be removed).

  • #7

Change the admin user’s email address

I already mentioned that I changed the admin email address after that was suggested by ikkeben . But thanks for your input.

  • #8

May you check if version 2.0.5 solves it? Just use custom_versions.txt for the override, or edit it in versions.txt (md5sum can be removed).

Should I run this set of commands?

cd /usr/local/directadmin/custombuild
echo «letsencrypt:2.0.5:a944b069ac70c3e574c25def6e1d6b2f» > custom_versions.txt
./build letsencrypt

Last edited: Jul 7, 2020

  • #9

When I ran the above, I got the output…

Let’s encrypt client 2.0.4 has been installed.

even though I specified 2.0.5 in the custom_versions.txt file

  • #10

OK, update. I tried to change customs versions from CustomBuild 2 instead of the command prompt.

/CMD_PLUGINS_ADMIN/custombuild/versions.html

Here I was able to specificy 2.0.5 and then update the software to 2.0.5, not sure why it failed at the command prompt.

I then logged in as a user and generated an SSL from scratch. I got this output:

Certificate and Key Saved.​

​

Details
2020/07/07 10:56:32 No key found for account [email protected]. Generating a 4096 key.
2020/07/07 10:56:34 Saved key to /usr/local/directadmin/data/.lego/accounts/acme-v02.api.letsencrypt.org/server.mydomain.com/keys/[email protected]
2020/07/07 10:56:35 [INFO] acme: Registering account for [email protected]
!!!! HEADS UP !!!!

Your account credentials have been saved in your Let’s Encrypt
configuration directory at «/usr/local/directadmin/data/.lego/accounts».

You should make a secure backup of this folder now. This
configuration directory will also contain certificates and
private keys obtained from Let’s Encrypt so making regular
backups of this folder is ideal.
2020/07/07 10:56:35 [INFO] [userdomain.com, www.userdomain.com] acme: Obtaining SAN certificate
2020/07/07 10:56:35 [INFO] [userdomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxx
2020/07/07 10:56:35 [INFO] [www.userdomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxx
2020/07/07 10:56:35 [INFO] [userdomain.com] acme: Could not find solver for: tls-alpn-01
2020/07/07 10:56:35 [INFO] [userdomain.com] acme: use http-01 solver
2020/07/07 10:56:35 [INFO] [www.userdomain.com] acme: Could not find solver for: tls-alpn-01
2020/07/07 10:56:35 [INFO] [www.userdomain.com] acme: use http-01 solver
2020/07/07 10:56:35 [INFO] [userdomain.com] acme: Trying to solve HTTP-01
2020/07/07 10:56:40 [INFO] [userdomain.com] The server validated our request
2020/07/07 10:56:40 [INFO] [www.userdomain.com] acme: Trying to solve HTTP-01
2020/07/07 10:56:47 [INFO] [www.userdomain.com] The server validated our request
2020/07/07 10:56:47 [INFO] [userdomain.com, www.userdomain.com] acme: Validations succeeded; requesting certificates
2020/07/07 10:56:51 [INFO] [userdomain.com] Server responded with a certificate.
Certificate for userdomain.com,www.userdomain.com has been created successfully!userdomain.com​

It appears to have allowed the certificate to be created again from scratch using version 2.0.5. However, I noticed from the above output, it is still referring to [email protected] and not the email I updated earlier. (I changed my actual server domain to mydomain.com for this thread.)

Last edited: Jul 7, 2020

  • #11

Can you tell me if v2.0.5 is the next version of letsencrypt and my above changes forced it to update to that? Why was it not already updating to that? I fail to understand why it was not already updating to the latest if it was meant to?

smtalk


  • #12

Can you tell me if v2.0.5 is the next version of letsencrypt and my above changes forced it to update to that? Why was it not already updating to that? I fail to understand why it was not already updating to the latest if it was meant to?

2.0.5 is not yet released, I placed it just for a test :) I’ll update it accordingly to find renamed admin’s email.

  • #13

2.0.5 is not yet released, I placed it just for a test :) I’ll update it accordingly to find renamed admin’s email.

OK, thanks for explaining. That makes some sense now.

I am hoping that when other domains come to renew their certificates, it’ll work smoothly now. I think I’ll remove the custom_versions.txt file now so it doesn’t interfere with future updates.

Many thanks. Please let me know if you have any further instructions once you have finished what you’re doing for the next version?

smtalk


  • #14

May you try 2.0.5 one more time? It should use your renamed admin’s email now :) If everything is alright — I’ll put it to public. Thanks.

  • #15

Hi

I rolled back to 2.0.4 and then updated to 2.0.5 using CustomBuild 2.0 method as before. It worked, I am now seeing the email address I entered in as the admin server when I updated the admin email. Here is the output from a user regenerating the SSL cert from scratch after the rollback and update again.

Certificate and Key Saved.​

Details
2020/07/07 22:59:34 No key found for account [email protected]. Generating a 4096 key.
2020/07/07 22:59:35 Saved key to /usr/local/directadmin/data/.lego/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys/[email protected]
2020/07/07 22:59:35 [INFO] acme: Registering account for [email protected]
!!!! HEADS UP !!!!

Your account credentials have been saved in your Let’s Encrypt
configuration directory at «/usr/local/directadmin/data/.lego/accounts».

You should make a secure backup of this folder now. This
configuration directory will also contain certificates and
private keys obtained from Let’s Encrypt so making regular
backups of this folder is ideal.
2020/07/07 22:59:36 [INFO] [exampledomain.com, www.exampledomain.com] acme: Obtaining SAN certificate
2020/07/07 22:59:36 [INFO] [exampledomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxxxx
2020/07/07 22:59:36 [INFO] [www.exampledomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxxxx
2020/07/07 22:59:36 [INFO] [exampledomain.com] acme: Could not find solver for: tls-alpn-01
2020/07/07 22:59:36 [INFO] [exampledomain.com] acme: use http-01 solver
2020/07/07 22:59:36 [INFO] [www.exampledomain.com] acme: Could not find solver for: tls-alpn-01
2020/07/07 22:59:36 [INFO] [www.exampledomain.com] acme: use http-01 solver
2020/07/07 22:59:36 [INFO] [exampledomain.com] acme: Trying to solve HTTP-01
2020/07/07 22:59:41 [INFO] [exampledomain.com] The server validated our request
2020/07/07 22:59:41 [INFO] [www.exampledomain.com] acme: Trying to solve HTTP-01
2020/07/07 22:59:47 [INFO] [www.exampledomain.com] The server validated our request
2020/07/07 22:59:47 [INFO] [exampledomain.com, www.exampledomain.com] acme: Validations succeeded; requesting certificates
2020/07/07 22:59:50 [INFO] [exampledomain.com] Server responded with a certificate.
Certificate for exampledomain.com,www.exampledomain.com has been created successfully!exampledomain.com​

It worked!

Many thanks!

  • #16

Good morning,

I discovered the same issue yesterday and I updated LetsEncrypt but still the same error:

Code: 

2020/07/14 09:30:45 [INFO] acme: Registering account for [email protected]
2020/07/14 09:30:49 Could not complete registration
acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-acct :: urn:ietf:params:acme:error:invalidEmail :: Error creating new account :: contact email "[email protected]" has invalid domain : Domain name needs at least one dot, url:
Certificate generation failed.

What to do next? I hope someone can help me….. Thanks a lot!

Vincent Volmer

  • #17

Please ignore my previous post. I changed the e-mail address and all is working fine now!

  • #18

Just had the same issue, if anyone is wondering where to change the password for the admin account:

Edit this file:
/usr/local/directadmin/data/users/admin/user.conf

Then restart directadmin and Letsencrypt should work again (it did for me).

Источник

Challenge failed for domain – Certbot error – How to fix?

I was setting up letsencrypt certificates to enable SSL on one of my ubuntu servers. I mapped a domain (zumpdo.xyz) to my server, installed nginx and I ran the certbot certificate generator using the following command.

sudo certbot --nginx -d zumpdo.xyz -d www.zumpdo.xyz

I got this error.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.zumpdo.xyz
http-01 challenge for zumpdo.xyz
Waiting for verification...
Challenge failed for domain www.zumpdo.xyz
Challenge failed for domain zumpdo.xyz
http-01 challenge for www.zumpdo.xyz
http-01 challenge for zumpdo.xyz
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.zumpdo.xyz
   Type:   connection
   Detail: Fetching
   http://www.zumpdo.xyz/.well-known/acme-challenge/_HsorBSWytofXEPBUOifaF8JC6DmWN2FE1zzUjh9zlk:
   Timeout during connect (likely firewall problem)

   Domain: zumpdo.xyz
   Type:   connection
   Detail: Fetching
   http://zumpdo.xyz/.well-known/acme-challenge/qS6VsLSQQulJK_z1dq02XO5JqYAvdcZBZtaxzz97V10:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA 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.

It gives a hint that it’s likely a firewall issue. The problem is http and https ports were not exposed from my server. I had to add a rule to allow inbound traffic to the port 80 for http and 443 for https.

I tried to create the certificates again and voila!

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.zumpdo.xyz
http-01 challenge for zumpdo.xyz
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://zumpdo.xyz and
https://www.zumpdo.xyz

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=zumpdo.xyz
https://www.ssllabs.com/ssltest/analyze.html?d=www.zumpdo.xyz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/zumpdo.xyz/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/zumpdo.xyz/privkey.pem
   Your cert will expire on 2021-04-25. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le
Источник

Понравилась статья? Поделить с друзьями:
  • Md5 error binary is invalid odin как исправить
  • Md unwind support h 65 47 error dereferencing pointer to incomplete type struct ucontext
  • Md 0011 30024 ошибка
  • Mcvr100 dll ошибка
  • Mcvcr100 dll как исправить