Pull to refresh

Comments 117

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

Так генерируй ключи на сервере и потом отдавай туда только CSR. Какие проблемы?

Ну почему же? Сайт обещает, что:
the keys will be generated on the server… and never stored

Честно-честно.
И на Google-analytics не обращайте внимания.
</sarcasm>
Если пользоваться нормальным браузером, то ключи не передаются на сервер.
Private Keys are generated in your browser and never transmitted.
For modern browsers we generate a private key in your browser using the Web Cryptography API and the private key is never transmitted. The private key also gets deleted off your browser after the certificate is generated. If your browser does not support the Web Cryptography API then the keys will be generated on the server using the latest version of OpenSSL and outputted over SSL and never stored. For the best security you are recommended to use a supported browser for client generation. You can also provide your own CSR when using manual verification in which case the private key is handled completely on your end.

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

Согласен со всем вашими аргументами. На самом деле я тоже считаю, что генерировать сертификат в браузере с помощью js скрипта с сайта, тем более вручную — не годится как основное решение.
Есть zerossl.com
Там ключ можно сгенерировать самому, и отдать только CSR.
вайлдкард же опасен немного…
вдруг утечет? скомпрометированы окажутся все хосты, а не только 1, на который был выдан обычный серт…
пересоздать его занимает несколько секунд (полностью автоматизировано), тем более по умолчанию он на 3 месяца даётся.
Wildcard надо подтверждать через DNS и пока нет плагина для nic.ru, так что полностью автоматизировано оно будет не у всех.
Вот уже давно жду такой плагин, и никто не напишет никак… Пытался было сам, но бросил, в виду того, что не программист.

Зачем держать DNS на nic.ru, который (1) платный и (2) неотказоустойчивый (прекрасно помню, как падали сразу все их ns1-nsX)? Полно других вариантов.

А где держать? Чтоб можно было от юрлица счета оплачивать
Сам домен можно держать и оплачивать у текущего регистратора, а вот ns сервера можно указать произвольные. Я использовал Azure DNS и AWS Route 53 — они надежные и стоят пол-доллара в месяц. Есть и бесплатные, вот, например. Смотрите мой коммент.

Мы для критичных нагрузок используем также Azure DNS с их traffic manager. Вопрос по большей части риторический был.
Когда ты личный проект пилишь, тебе не составит труда оплатить пару баксов с картой, но когда ты действуешь от лица ООО, то часто требуется договор и всяческие бухгалтерские документы. В нашей стране пока нельзя привязать карту к счёту организации вроде бы

В нашей стране пока нельзя привязать карту к счёту организации вроде бы
Можно. Спрашивайте в своём банке, почти у всех есть т.н. «бизнес-карты»
А яндекс.днс не катируются вообще?
У Яндекс.DNS, насколько я знаю, нет возможности управлять DNS записями.
UFO just landed and posted this here

selectel дает бесплатный dns хостинг с API, мы под него ansible модуль написали для управления, при желании можно сделать плагин для certbot, но нам массово wildcard ssl не нужен.

Сейчас посмотрел, в acme.sh уже есть поддержка selectel, круто!

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

Ещё DNS.he.net бесплатный от Hurricane Electric

Удобно, когда всё в одном месте. Да и стабильность после того DDoS'а нареканий не вызывает.

Я лет 5-6-7 назад купил там домен и сразу, чтобы не париться, днсы. Они легли этой же ночью, все пять. И это явно был не DDOS, там скорее легла какая-то центральная база, куда все днсы ходили, или что-то со внутренней сетью произошло — выглядело совсем не похоже на забитый канал, да и зачем ддосить российские нсы ночью?


Может, так совпало, и это было один раз в жизни, но с тех пор — не хочу.

КМК, 99% случаев компрометации обычно позволяют скомпрометировать всё остальное. Получил доступ к директории с ключами — получил доступ ко всем ключам. Зато выгоды всё перевешивают.
Ну и если не надо — не используйте, конечно.
А кому-то штрафы за SEO опасны, за сайты, на которые простой человек даже войти не может

доверять приватный ключ кому-либо — это ай-ай-ай! я пользуюсь acme.sh, где получение нового сертификата делает одна команда:


acme.sh --issue --dns -d *.example.com 
Я пример написал для «ручногого» получения. У acme.sh есть поддержка моего ДНС провайдера, поэтому проблем с автоматическим renew нет. У меня даже ssl для iLo автоматически обновляется, но это уже другая история.
Почитал их гитхаб, действительно мощный продукт. Только я не понял, можно с помощью acme.sh автоматом для nginx'а прописывать сертификаты, как с помощью certbot'а?

Можно. Хотя я не знаю как сделано в certbot — он у меня на centos6 не захотел в какой-то момент заводиться и просил рут, я тогда нашёл замену lego, а позднее нашел и acme.sh, который работает везде, где мне надо.

Там есть ключ, позволяющий копировать сертификат в нужное место, а также рутина, дёргающая nginx reload после выполнения самого acme — так что проблем никаких. Один раз прописать локацию для ключей в конфиге хоста, и после этого всё будет отлично.
Да, это можно легко делать параметрами --cert-file/--key-file/--fullchain-file для того, чтобы положить в нужное место сертификат/ключ и командой --reloadcmd задаётся действие.
Так же он запоминает эти параметры и потом сам по cron'у их выполняет.
Вот спасибо! Он даже умеет dns-01 challenge для duckdns.org из коробки!
Я правильно понимаю, что для продления сертификата, если днс находится на cloudflare, например, acme.sh необходимо предоставить API token от cloudflare? В случае компрометации которого можно потерять доступ к домену вообще.
любая авто-регистрация через плагин от вашего днс провайдера требует токен на запись в него, собственно. Так что, в случае вскрытия сервака, утечет все.
UFO just landed and posted this here

Ну наконец-то можно выбросить всю эту обвязку с динамической генерацией!

Не получится не только выбросить, придется ещё и усложнять! Подтверждение только через DNS, т.е. нужно давать доступ к доменной зоне и/или работать через API регистратора.

Для обычных сертификатов достаточно один раз создать txt-запись, для wildcard разве не так?

Присоединяюсь к вопросу. Где собака зарыта?
На странице acme.sh:
Take care, this is dns manual mode, it can not be renewed automatically. you will have to add a new txt record to your domain by your hand when you renew your cert.

Please use dns api mode instead.

НИКОГДА НЕ ГЕНЕРИРУЙТЕ ПРИВАТНЫЕ КЛЮЧИ НА САЙТАХ!
Приватный ключ должны быть сгенерирован только на сервере, и никогда его не покидать!


Сами смотрите что случилось с Trustico https://habrahabr.ru/company/1cloud/blog/350768/

Строго говоря, одно другому не мешает. Сертификат вполне может быть сгенерирован через web, на сайт достаточно передать CSR (руками или через соответствующий API).

Я абсолютно согласен, что генерировать сертификат через браузер это не самый лучший и безопасный способ. Однако в приведенном примере приватный ключ генерируется в самом браузере, и более того, можно использовать CSR (Certificate Signing Request).

Если он генерируется в браузере, значит он генерируется с помощью JS, а значит там так же может быть JS который сливает все ваши ключи.


Готовы ли вы использовать сгенерированный онлайн пароль в качестве своего мастер пароля? Почему тогда доверяете приватным ключам которые кто-то генерирует за вас?

Если он генерируется на сервере, значит он генерируется с помощью С++, а значит там так же может быть С++, который сливает все ваши ключи.

Готовы ли вы использовать сгенерированный онлайн пароль в качестве своего мастер пароля? Почему тогда доверяете приватным ключам, которые кто-то генерирует за вас?

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


Так что у меня есть достаточно причин доверять моему серверу с подписанной, доверенной openssl, и не доверять всяким сайтам.

Прошу прощения, был невнимателен. :)

UFO just landed and posted this here

Вы носите TLS ключи с собой? 0_о

А 1 Вайлкадр-сертификат на 2 разных домена — возможно?


To create a wildcard certificate for multiple domains such as example.org and example.com enter .example.org .example.com. Manual DNS verification will be required.
(с) https://www.sslforfree.com

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

Немного деконволюции и… не, показалось =)

В данном случае да, но в общем случае размытие заставляет меня насторожиться. Лучше замазывать. :)

Для текста такое только в фильмах работает(ну и если размытие 20% — тоже).
Очень уж много свободного места вокруг каждого символа.
Интересно, как как на счет *.ru?
Корневики могут это сделать весьма просто…
UFO just landed and posted this here
*.ru — нельзя, дает ошибку
*.org.ru — можно )
Add TXT record with the name/host _acme-challenge.org.ru with the value vlwTnpiyF0kdNPyQy7MfWyvsHgAcPNhNet2IwKI8B6U
Скорее всего защита на выписывание на домены первого уровня, а org.ru уже второй.
С другой стороны, как они должны проверять все эти домены на подходимость для выписывания, чтобы кто-то не выписал на «слишком публичный» домен?
org.ru, собственно, формально обычный домен:

domain: ORG.RU
nserver: a.dns.ripn.net.
nserver: b.dns.ripn.net.
nserver: d.dns.ripn.net.
nserver: e.dns.ripn.net.
nserver: f.dns.ripn.net.
state: REGISTERED, DELEGATED, VERIFIED
org: ANO "MSK-IX"
registrar: RU-CENTER-RU
admin-contact: https://www.nic.ru/whois
created: 1997-07-10T13:04:39Z
paid-till: 2018-07-31T21:00:00Z
free-date: 2018-09-01
source: TCI


так же, кстати, как и co.uk — вот там интереснее будет получить wildcard.

Вероятно, имело бы смысл иметь какую-то пометку в whois записях, если домен из тех, в которых пользователи покупают/заказывают домены для себя, или же перед нами «просто домен» — для первых чтобы wildcard заказать было нельзя. А пока LE может только по черным/белым спискам какую-то защиту пилить, или по простым правилам («не ниже 2 уровня»).
Есть такие списки. Их браузеры ведут. Вроде у лисы такой есть. Там и официальные зоны и неофициальные.
А зачем браузерам список доменов «для заведения доменов» и доменов, которые «просто домены для сайтов»? Не могу взять в толк.
И для этого (встречал что-то еще из безопасности) и для правильной раскраски урлов в адресной строке (у некоторых по разному выделяется), и для улучшения поиска подсказок при вводе урла и много еще для чего.
Есть такая интересная вещь как Public Suffix List. Это список «публичных» доменов различных уровней, чьи суб-домены — по сути различные сайты. Let's Encrypt использует его для расчета ограничений по выпуску сертификатов. Вот этот список, *.org.ru туда входит.

По логике, они должны его же и использовать для запрета выдачи wildcard. Я проверил несколько штук, почему-то не все под запретом. Например, *.chiba.jp — нельзя, а *.spb.ru — можно. Странно.
хммм… а можно зарегать домен _acme-challenge.org.ru? :D

(да-да, я знаю, что _ не нормальный символ)
А я использую СерБот с ручным выписыванием. Так удобней, чем давать ему право манипулировать вебсервером.
А что вас смущает в возможности опенсорсного скрипта (того же acme.sh) записать на диск машины в указанный вами каталог несколько файлов с сертификатами?

Технически, конечно, чем меньше лишних чужих скриптов на машине, тем лучше, но лично меня acme.sh смущает гораздо меньше, чем список пакетов, который средний серверный линуксовый дистр в наше время кладет мне на диск сервера при установке, даже не спрося меня, для чего я сервер думаю использовать. Acme.sh (как и certbot) я хотя бы способен пробежать глазами и поискать крамолу, а в десятках библиотек не разобраться, как ни называй их открытыми: может просто квалификации не хватить, и остается только верить в благие намерения мэинтейнеров.
Ничего против не имею. Мне не нравится, что какое-то сторонее приложение или скрипт будет редачить мой конфиг nginx
Так ведь, внезапно, никто ваш конфиг ни при каких условиях не будет трогать. Любой скрипт получает для вас сертификат, кладет его на диск в указанное место и под указанным именем, а вы уже сами пишете (один раз) путь к положенным для вас файлам сертификата — по имени указываете.
В сертБоте, когда Вы указываете выписывать сертификат через http, вообще-то он переписывает ыашиконфиг, ребутит nginx, а после возвращает как было. Мне это и не нравится
Ну это кто на что учился какой скрипт как написан. acme.sh имеет два варианта, который обходится без этой ереси:
1. Stateless mode:
получаете отпечаток ключа вашего аккаунта на LE:

root@ed:~# acme.sh --register-account
[Mon Feb 6 21:40:18 CST 2017] Registering account
[Mon Feb 6 21:40:19 CST 2017] Already registered
[Mon Feb 6 21:40:21 CST 2017] Update success.
[Mon Feb 6 21:40:21 CST 2017] ACCOUNT_THUMBPRINT='6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd'


и указываете его в конфиге на 80 порту:

location ~ "^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$" {
default_type text/plain;
return 200 "$1.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd";
}


либо

2. Выкладывание в вашем webroot временного файлика с проверочными данными, чтобы через веб можно было проверить, что он виден во время проверки.

Писать в конфиг апача acme.sh точно не хочет.
Не всегда это просто реализуемо. А описанный Вами первый вариант и требует переписывания конфигурации. Второй не решает проблемы с несколькими серверами за одним доменом.
Так первый способ тогда про вас. Прописали один раз аккаунт, и все. На всех серверах. Один раз. Есть еще вариант через DNS проверяться — там вообще все просто, если ваш ДНС-провайдер умеет API.

Но если не хотите автоматизировать, и вам кажется, что вы за всем руками проследите, в чем мы вас уговариваем? Разговор только о том, что LE такое позволяет, а у многих ЦС обновлять серты обязательно нужно руками.
А чем вас webroot не устраивает?
Ничего нигде не ребутит и не переписывает. Нужно только другую рут-папку для acme-challenge в конфиге веб-сервера указать.
Все элементарно! У меня домен привязан не к одному IP. Поэтому у меня мануальный режим. Я беру токен с валидацией и записываю их в БД, а потом уже отдаю на любом сервере эти данные по запросу из БД
Точнее хостится на многих хостах
Поэтому у меня используется плагин manual

В голосовании не хватает варианта ответа «Нет, буду как раньше получать через LE отдельно для каждого поддомена, потому что некогда перенастраивать».

Нельзя получить отдельно для поддомена серт от LE
У меня серт на главный домен и на сотню поддоменов. Если появился новый — генерим новый (до ста штук на сертификат).
Лично мой выбор — подожду полгодика пока во всех панелях оно будет работать из коробки, и тогда обновлюсь.

Почему нельзя? Я с помощью Certbot без проблем получил сертификаты для двух поддоменов одного домена.

Я не понимаю че они так долго тянули, и что именно мешало раньше это сделать.

По поводу DNS challenge. Чтобы пройти его автоматом ваш домен должен резолвиться через nameserver с поддержкой API + бот/скрипт должен уметь им пользоваться. В админке регистратора всегда можно перейти на другой nameserver, для которого уже есть готовое решение. Вот пример, я только что перевел свой домен на AWS Route 53 — он стоит пол-доллара в месяц.


Скриншоты кликабельны

клик


клик


клик

Есть еще частный случай — когда у вас свой nameserver. Нашел интересную штуку https://github.com/joohoi/acme-dns — простой DNS сервер с REST API специально для ACME DNS challenge.
Вообще, так как достаточно создать TXT запись для фиксированного суб-домена _acme-challenge.baur.im, то вовсе не обязательно давать боту/скрипту токен доступа на все DNS записи. Достаточно создать отдельный DNS zone для _acme-challenge.baur.im — в ней скрипт и будет раз в 3 месяца создавать TXT запись. А в самой админке домена baur.im — добавить эти NS адреса для _acme-challenge.baur.im.
UFO just landed and posted this here
Я сделал так: в AWS Route 53 создал DNS zone для _acme-challenge.baur.im. Там сразу отображается 4 NS адреса для входящих запросов. Эти адреса (можно не все) я указал у своего регистратора как NS записи для _acme-challenge.baur.im. Все, теперь можно в этой зоне создать TXT запись в корне (а можно было и сразу).

Добавлю, что при экспериментах с DNS надо учитывать TTL — время кэширования в секундах, иногда надо подождать. Также удобно изучать DNS записи через dig/nslookup/их онлайн эквиваленты — можно явно указывать через какой NS сервер опрашивать.
UFO just landed and posted this here
UFO just landed and posted this here
Нужно именно _acme-challenge. В dns админке моего регистратора name.com это работает. Похоже, ваш регистратор не разрешает создавать такие dns записи. Советую попробовать переключить ns сервера на что-нибудь из этого.
UFO just landed and posted this here
/var/lib/knot/zones/objective.pe.zone.gen.sh:
#!/bin/sh

NOW_DATE_TIME=`date -u +'%Y%m%d%H%M'`

{

echo 'objective.pe. 3600  IN SOA   objective.pe. hostmaster.octagram.name. ( '`date -u +'%s'`' 86400 7200 3600000 200 )
objective.pe. 86400 IN NS    ns3.toom.su.
objective.pe. 86400 IN NS    ns4.toom.su.
objective.pe. 86400 IN A     173.249.20.221
*             86400 IN A     173.249.20.221
localhost     86400 IN A     127.0.0.1'

if [ "X$CERTBOT_VALIDATION" != "X" ]; then
    echo '_acme-challenge 86400 IN TXT   ( "'"$CERTBOT_VALIDATION"'" )'
fi

} > /var/lib/knot/zones/objective.pe.zone

/usr/sbin/knotc reload > /dev/null

sleep 4


monthly cron:
certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /var/lib/knot/zones/objective.pe.zone.gen.sh -d \*.objective.pe --manual-public-ip-logging-ok --expand --renew-by-default --text --agree-tos > /dev/null 2>&1
certbot certonly --manual --preferred-challenges=dns --manual-auth-hook /var/lib/knot/zones/objective.pe.zone.gen.sh -d objective.pe --manual-public-ip-logging-ok --expand --renew-by-default --text --agree-tos > /dev/null 2>&1
/var/lib/knot/zones/objective.pe.zone.gen.sh # cleanup

# sftp to all servers
# reload config, ssh to reload config on all servers
UFO just landed and posted this here
Как только кто-то умудрится подтвердить, что он умеет управлять этим доменом — так сразу же.

Раньше, конечно, «было не так» — раньше такой могущественный злоумышленник должен был выписывать для своих хацкерских хостов домены, указывая каждое имя (примерно по 100 вариантов на сертификат влезает).

А что вас пугает-то? В чем ненадежность?
UFO just landed and posted this here
LE молодцы, согласен, на их фоне любой ЦС выглядит «не очень». Внутри они все об одном, только LE меньше щеки надувает, и больше работает, а некоторые из других ЦС за антураж берут заметные деньги — притом антураж часто чисто организацинно-юридический.

Обычная критика LE сводится к тому, что LE выдает сертификаты всем, кто их попросит, и кто может подтвердить управление доменом — так это их прямая обязанность, и их процесс выдачи DV-сертификатов хорош и быстр. Вот что при этом его услугами воспользовались те или иные обманщики, которые попросили серты на paaypal.com или paypai.com — согласитесь, не дело ЦС решать, что похоже, что нет. Компьютер должен работать, человек — думать. Если я зайду на какой-нибудь online.sbepbank.ru (где окажется аккуратная копия морды с online.sberbank.ru), и введу там данные кредитки — то думать должен был бы я, а не ЦС, согласитесь!

Зато могу уверенно сказать, что, хотя те же банки юзают дорогущие сертфикаты от Symantec и прочих (где в цену еще и некая «страховка» заложена), но при этом есть масса людей, называющих банки обманиками. Так что, ЦС не должны выдавать сертификаты банкам и прочим потенциально разорительным для клиентов компаниям?

P.S. Я понял, что вы не любите LE, тогда как я считаю, что они меньше понтуются и больше работают. Но пока число скандалов с LE сильно меньше, чем у многих других ЦС, а реакция на вопросы быстра и действенна, в отличиии от политики замалчивания, которую некоторых другие ЦС демонстрировали во время кризисов.
А SSL и не должен никак вас защищать от фишинга или организаций с плохой репутацией.
Он лишь гарантирует, что вы передаёте данные на именно тот сервер что действительно обслуживает определённый домен и их по пути не перехватит Вася подменивший ваш wi-fi SSID.

Какую-то защиту от фишинга обеспечивают EV SSL сертификаты. А то что их не используют повсеместно все юрлица связано как раз со сложностью и стоимостью их получения. Да и по сути ничего не мешает зарегистрировать ООО «Сбербинк лимитед» и получить соответствующий сертификат.
Я проверил, даже DNS админы PayPal не смогут получить сертификат на paypal.com от Let's Encrypt — очевидно, этот домен в черном списке: Policy forbids issuing for name. Также под запретом google.com, mail.ru, vk.com. Логичный шаг.

Думаю, все проще:


$ host -t caa paypal.com
paypal.com has CAA record 0 issue "digicert.com"
paypal.com has CAA record 0 issue "symantec.com"

$ host -t caa google.com
google.com has CAA record 0 issue "pki.goog"
Хм, интересно, с CAA записями раньше не встречался. Но у mail.ru и vk.com их нет. Гугл подсказал, что у Let's Encrypt действительно есть некий черный список, скорее даже, секретный алгоритм определения high-risk доменов. И по запросу они могут наоборот добавить домен в белый список.
Да что вы, многие ДНС-сервисы до сих пор не в курсе. С другой стороны, вот Яндекс (даром что он имеет рейтинг B, и список хостов чуть пугает, почему-то «турецкое» имя как первое), они уже юзают:
целиком не влезло
"

Но, вообще, список high risk нужно иметь, совсем оно будет неглупо.
UFO just landed and posted this here
Новость эпохальная! Спасибо огромное!
txt запись должна обновляться каждый раз при запросе нового серта, или достаточно один раз её создать в начале?
Да, при каждой проверке DNS challenge. После получения нового сертификата, TXT запись можно удалить.
Sign up to leave a comment.

Articles