Comments 51
У большинства DNS поставщиков есть API с авторизацией.
Для них гораздо проще использовать скрипт, построенный на базе Posh-ACME, запускаемый по расписанию. В скрипт прикручивается и остальная автоматизация, включая установки сертификата, его перепаковки под все разные закидоны (full_chain / стопка файлов), проверки, уведомления, и т.п.
Ваш вариант тоже рабочий. Кому-то будет проще с ним.
Чтобы не заниматься всем этим вручную, я использую https://github.com/linuxserver/docker-swag. Это образ для Докера, содержащий nginx и самостоятельно следящий за сертификатом. Он даже уведомит на почту, если сертификат всё таки скоро протухнет. Точнее, попросит LetsEncrypt уведомить.
Затем из него можно копировать сертификаты куда надо или просто использовать его как proxy.
Лучше тогда более легкий https://github.com/nginx-le/nginx-le
Тоже порекомендую нафаршированный веб-сервер Caddy, который, помимо автообновления SSL любым из способов, автоматически обновляет свой конфиг при появлении контейнера с лейблами caddy в его сети. Очень удобно, конфиг становится ненужным в явном виде, не нужно ничего хардкодить - всё происходит динамически и декларативно, запускай себе docker compose'ы сколько хочешь.
В бою на пет-проектах на 20+ серверов уже полгода.
Топ материал, он бы идеально добавил бы мою статью про SSL, о которой идет речь в начале =D
Ахуительный контент, я искренне считаю, что они прям ИДЕАЛЬНО дополняют друг-друга.
Зачем использовать форк возрастом с говно мамонта, когда оригинал обновляется и работает? https://github.com/dehydrated-io/dehydrated
Зачем обновлять то, что работает? )
Это ж не московские бордюры....
1) В вашем форке от 2015 года не вижу использования ACME v2.
https://github.com/digint/letsencrypt.sh
2) В оригинальном скрипте
Use new ACME v2 endpoint by default
2018-03-13
https://github.com/dehydrated-io/dehydrated/releases/tag/v0.6.1
3) С ноября 2021 ACME v1 не работает.
https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/2
Что там у вас работает? Тут нужна гифка с Тиньковым.
Проверять не буду, мне теперь кажется что вы накопипастили мусор из чатика с нейросеткой.
Начнем с того, что это не мой форк. Я его просто использую.
А во-вторых, я его использую - он работает. Вот прямо пару часов назад.
Правда, я совершенно не помню откуда конкретно этот скрипт взял, это было 5 лет назад - возможно это не тот который на конкретно этом Гитхабе, а другой, правильный - но он тоже называется letsencrypt.sh. если вы так хорошо разбираетесь в форках - может быть тогда правильную ссылочку на ТОТ letsencrypt.sh дадите?
Что там у вас за отношения с гифками и нейросетками - этого не знаю.
Для ленивых есть ещё вариант - Certify The Web
Что, если он "не умеет обслуживать именно вашу программу"?
Последовательность решения такая:
Ставим утилиту на отдельный сервер.
На сервере поднимаем IIS
Утилиту нацеливаем на этот IIS
Балансировщику на входе , который что-то публикует, объясняем, что запросы на /.well-known отправлять надо на этот сервер, например , для HAProxy это примерно так:
haproxy.cfg
..
# ACME
acl app-acme-path path -i /.well-known
acl app-acme-path path_beg -i /.well-known
..
use_backend backend_http_acme if app-acme-path
..
backend backend_http_acme
mode http
balance source
server webserver1acme 10.11.12.13:80 check # Web server 1
Утилите задаем post execution script, вся задача которого будет создать в журнале приложений событие с каким-то вашим уникальным кодом
В планировщике создаем триггер на этот уникальный код в журнале, который будет запускать ваш скрипт, занимающийся установкой полученного сертификата, куда нужно и от той учетной записи, которая имеет нужные права.
Вариант рабочий, несложный в отладке, расширяемый и достаточно стабильный.
Для ленивых есть ещё вариант - Certify The Web
К сожалению, в Requirements написано, что эта штука не работает на Windows XP.
Зачем? Есть acme.sh есть прямая интеграция и горячее подключение сертификатов через deploy и admin.sock https://habr.com/ru/articles/904038/
Зачем?
Затем, что линуксом потребности в сертификатах не ограничиваются.
Через install можно развернуть куда угодно нужно указать только директорию
Есть ли возможность с помощью этого или какого либо другого решения выдать сертификат для сайта, недоступного извне сети? То есть для внутреннего сайта
Если есть контроль над публичной зоной DNS, совпадающей с внутренней, то можно сделать проверки исключительно через DNS без всяких сайтов.
Можно поподробнее? Что-то никак не придумать как именно это сделать.
Как вариант: https://github.com/joohoi/acme-dns-certbot-joohoi
Запускаете, создаете CNAME, ждете несколько минут, продолжаете процесс. Больше DNS трогать не надо, запускаете просто certbot renew.
И можно без отдельной зоны DNS. Неоднократно встречал у больших дядек когда в днс есть и публичные записи и внутренние в духе servicename IN A 192.168.x.x. Да это некрасиво и так делать нехорошо, но кто вам запретит? :)
Есть.
Делается внешний сайт, единственный контент которого - секретная строка.
Делается внутренний сайт с тем же доменным именем, которое прописывается на своем локальном DNS сервере в интранете.
Снаружи - виден сайт-заглушка, этого достаточно для получения сертификата. Внутри виден настоящий внутренний сайт.
Доменное имя - из серии бесплатных, таких сервисов несколько есть.
А ещё есть caddy, который используется вместо nginx. Он сам запрашивает все сертификаты и сам их обновляет.
Есть. И он работает не точно как nginx, и под него надо переписывать конфиги, непонятно как у него с нагрузкой, балансировкой, перемаршрутизацией запросов, и неплохо бы разобраться как именно "он сам" что-то делает - на это нужно время, это изменение инфраструктуры.
Вообще же, как правило, чем больше разных функций в одной программе - тем хуже, не надёжнее и сложнее в поддержке.
Может caddy исключение из этого правила, но есть сомнения...
Есть acme.sh - в нем много вариантов обновления LE сертификатов и для случаев, когда нужно для верификации поднять http/https сервер, скрипт его поднимает сам. Причем тот "сервер" буквально из говна и палок сделан, но большего для верификации домена и не нужно.
Никогда не было проблем с cerbot.
Автоматом получает сериификаты доя моих серверов.
Веб сервер выступает как прокси
Существенный косяк в проверке файлов локальных сертификатов, а именно по времени создания самого файла. Более правильный путь - openssl проверяет expiration date самого сертификата и если ему осталось менее 30 дней запускает renewal процесс для этого сертификата.
Это особенно полезно когда у тебя стопка wildcard сертификатов для разных доменов.
Более правильный, да, но не видно практической разницы, в случае если эти файлы никаким иным образом не модифицируются.
Не могу придумать сценарий обновления времени их модификации при сохранении старого expiration date, кроме шаловливых ручек админа, зачем-то пересохранившего открытый в редакторе файл. При просто копировании туда-сюда копируется и время модификации.
Но если такая возможность допускается - правильнее проверять, конечно.
Случаи бывают разные: от ... и до ...))
Проверять какой-либо критерий по некоему другому косвенному критерию - прямая дорога к длительному траблшутингу )
А что не так с сертботом? Работает практически везде. Лишь бы была DNS A record. Ваял даже когда-то шеллскрипт для мини хостинга, прописывающий все конфиги для пачки доменов, в т.ч. и LE серт с автообновлением.
Хотелось бы добавить - современные версии nginx умеют самостоятельно обновляться сертификаты, без этого набора "костыликов".
Как попроще приделать S к сайту на awebserver через duckdns.org? torzhok.duckdns.org:8080
Это какое-то приложение для Андроида, вроде? Пишут, что на базе Апача.
Значит надо в эту сторону смотреть, как оно там устроено, где там апач и потом его настраивать.
Другой вариант - повесить на отдельном сервере (железном или VDS) всё тот же nginx, настроить сертификаты там, и обращаться к вашему серверу как к аплинку - тогда на нем вообще ничего менять не нужно.
Или через Cloudflare - но там уже могут быть проблемы со стороны duckdns...
Смотря какая цель была в том, чтобы запускать сервер на Андроиде.
Примерно таким же скриптом пользуюсь для домашних нужд, только года 3-4 назад пришлось его обновить до v2 ибо у вас v1 и он работать сейчас не будет.
Так же сразу скажу минус этого варианта - вот эти "а раз в 2 дня" вы рано или поздно попадете что сертификат протух а крон еще не наступил, и все у вас уйдет в сертификат не Валид что критично для того же python и много кого еще.
Я так понимаю смысл автора просто рассказать как это работает и что происходит в краце. Статья не плохая но если бы вы переделали все под v2 было бы совсем здорово
Видимо у меня действительно v2, но я не помню откуда его брал, если не с того Гитхаба.
Он работает сейчас.
39655 Aug 18 2020 letsencrypt.sh
Срок действия сертификата 90 дней, если пытаться его обновлять хотя бы раз в 10 дней - выходит что за последние пару месяцев уже 6 экземпляров скрипта всё пытаются раз в 5 секунд обновить несчастный сертификат, и все никак не могут. И никто этого не замечает.
Ну только если сервер сертификатов помер, но тогда уже без разницы
сертификат протух а крон еще не наступил,
Сертификат даётся на 90 дней, при этом общепринято начинать его менять на 60-й. Как раз чтобы админ успел из отпуска выйти, если что-то не работает.
В статье не раскрыта тема получения сертификата на поддомены для нескольких сайтов. А она тоже интересная и полезная.
Направьте пожалуйста в какую бы сторону покопать. Есть пачка сервисов требующих сертов. Часть только внутри, часть опубликована через один IP через haproxy с ssl offload/раскидыванием по sni (http там нет вообще, только https). Среди зоопарка сервисов nextcloud, exchange, ms Terminal Gateway и еще пачка. Даже Cisco ASA. Все это постепенно вводилось в эксплуатацию и подключалось.
Сейчас получаю wildcard cert на шлюзе и раскатываю по всем линуксам (кроме винды, еще не добрался) ансиблем. На выходе уже какой-то монстроидальный скрипт и единая точка отказа. Вот как-то хотя бы часть сервисов заставить серты самим через web получать при этом http не открывая да и haproxy с его ssl offload лучше вообще не трогая.
хотя бы часть сервисов заставить серты самим через web получать
Забудьте. IMHO будет только хуже. Мониторить кучу разных костылей вместо одного скрипта.
при этом http не открывая
DNS валидация. API поддерживается у доменного регистратора?
Среди зоопарка сервисов nextcloud, exchange, ms Terminal Gateway и еще пачка. Даже Cisco ASA. ...
Примерно такой зоопарк у меня обслуживается PowerShell скриптом из под винды. Рулить Linux системами из под WIndows - элементарно. В обратную сторону, как по мне, мрак полный. Особенно, если речь про Exchange через Posh Remoting. CISCO ISE и ASA через API тоже оттуда рулится, кстати.
А powershell скриптом можете поделитесь? Хотя бы для exch и term gw блоком, чтобы не писать все с нуля.
Для Exchange, включая Send connector в облако:
Копирует, назначает на IIS и SMTP, назначает на Send connector в M365
$CertStoreLocation = 'Cert:\Currentuser\My'
$CertStoreLocationM = 'Cert:\LocalMachine\My'
..
$exchServers = "exch01.domain.local" , "exch01.domain.local"
foreach ( $remoteEXCH in $exchServers ) {
$remoteEXCH
$message = "Processing " + $remoteEXCH
write-log -Message $message -Path $LogFileName -Level Info
$remoteCertPath = "\\" + $remoteEXCH + "\temp$\"
Copy-Item -Path $newPFXfileName -Destination $remoteCertPath -Force
$message = "$newPFXfileName copyed to $remoteCertPath"
write-log -Message $message -Path $LogFileName -Level Info
Invoke-Command -ComputerName $remoteEXCH -ScriptBlock { param( $filename , $pwd , $CertLoc) Import-PfxCertificate -FilePath $filename -Password $pwd -CertStoreLocation $CertLoc } -ArgumentList "c:\temp\FullChain-v2024v2.pfx", $mypwd, $CertStoreLocationM
$message = "Certificate $Thumbprint import to server $remoteEXCH completed"
write-log -Message $message -Path $LogFileName -Level Info
$ConnectionUri = "http://" + $remoteEXCH + "/PowerShell/"
try {
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ConnectionUri -Authentication Kerberos -ErrorAction Stop
Import-PSSession $Session -DisableNameChecking -ErrorAction Stop
$OldGlobalErrorActionPreference = $Global:ErrorActionPreference
$Global:ErrorActionPreference = 'Stop'
Try {
Enable-ExchangeCertificate -thumbprint $thumbprint -confirm:$false -force -services SMTP,IIS
$message = "Certificate $Thumbprint assignment on server $remoteEXCH was succesful"
write-log -Message $message -Path $LogFileName -Level Info
}
Catch {
$_.ErrorDetails | Format-List *
$message = "Certificate $Thumbprint assignment on server $remoteEXCH failed!"
write-log -Message $message -Path $LogFileName -Level Error
}
Try {
$cert = Get-ExchangeCertificate -Server $remoteEXCH -Thumbprint $Thumbprint
$tlscertificatename = "<I>$($cert.Issuer)<S>$($cert.Subject)"
$tlscertificatename
Set-SendConnector "Outbound to Office 365 - e3ab09a8-feb8-4357-88ec-xxxxxxxxxxxxx" -TlsCertificateName $tlscertificatename -Force
$message = "Certificate $Thumbprint name $tlscertificatename on server $remoteEXCH set to send connector"
write-log -Message $message -Path $LogFileName -Level Info
}
Catch {
$message = "Certificate $Thumbprint name $tlscertificatename on server $remoteEXCH set to send connector failed!"
write-log -Message $message -Path $LogFileName -Level Error
}
$Global:ErrorActionPreference = $OldGlobalErrorActionPreference
}
Catch {
$message = "Can't connect to server $remoteEXCH via powershell , script can not be executed, exiting"
write-log -Message $message -Path $LogFileName -Level Error
}
Finally {
Remove-PSSession $Session
}
}Я пользуюсь acme.sh
https://habr.com/ru/articles/904038/
Так же легко через dns api получать сертификаты
Подключаем SSL от Let's Encrypt