Comments 117
через браузерный клиент https://www.sslforfree.com
Кроме как для тестов так делать не рекомендуется.
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.
Не важно какой браузер. Сайты пишут одно, делают другое. Сайты взламывают. Плагины видят контент вашей страницы. Это ужасная идея генерировать приватные ключи на сайтах!
Там ключ можно сгенерировать самому, и отдать только CSR.
вдруг утечет? скомпрометированы окажутся все хосты, а не только 1, на который был выдан обычный серт…
Зачем держать DNS на nic.ru, который (1) платный и (2) неотказоустойчивый (прекрасно помню, как падали сразу все их ns1-nsX)? Полно других вариантов.
Мы для критичных нагрузок используем также Azure DNS с их traffic manager. Вопрос по большей части риторический был.
Когда ты личный проект пилишь, тебе не составит труда оплатить пару баксов с картой, но когда ты действуешь от лица ООО, то часто требуется договор и всяческие бухгалтерские документы. В нашей стране пока нельзя привязать карту к счёту организации вроде бы
cloudflare.com
yandex dns
selectel дает бесплатный dns хостинг с API, мы под него ansible модуль написали для управления, при желании можно сделать плагин для certbot, но нам массово wildcard ssl не нужен.
Сейчас посмотрел, в acme.sh уже есть поддержка selectel, круто!
Если кому-то понадобится, учтите, что acme.sh не работает с.рф доменами без этого PR — https://github.com/Neilpang/acme.sh/pull/1500
От юрлица счет оплачивать можно где угодно. Это делается через корпоративную карту. Если ваш бухгалтер говорит иное, он либо некомпетентен, либо ленив (либо вы как-то умудрились выбрать такой банк, где такой услуги нет, бегите оттуда).
Ещё DNS.he.net бесплатный от Hurricane Electric
Я лет 5-6-7 назад купил там домен и сразу, чтобы не париться, днсы. Они легли этой же ночью, все пять. И это явно был не DDOS, там скорее легла какая-то центральная база, куда все днсы ходили, или что-то со внутренней сетью произошло — выглядело совсем не похоже на забитый канал, да и зачем ддосить российские нсы ночью?
Может, так совпало, и это было один раз в жизни, но с тех пор — не хочу.
Ну и если не надо — не используйте, конечно.
Ну наконец-то можно выбросить всю эту обвязку с динамической генерацией!
НИКОГДА НЕ ГЕНЕРИРУЙТЕ ПРИВАТНЫЕ КЛЮЧИ НА САЙТАХ!
Приватный ключ должны быть сгенерирован только на сервере, и никогда его не покидать!
Сами смотрите что случилось с Trustico https://habrahabr.ru/company/1cloud/blog/350768/
Строго говоря, одно другому не мешает. Сертификат вполне может быть сгенерирован через web, на сайт достаточно передать CSR (руками или через соответствующий API).
Я специфично сказал ключи.
Если он генерируется в браузере, значит он генерируется с помощью JS, а значит там так же может быть JS который сливает все ваши ключи.
Готовы ли вы использовать сгенерированный онлайн пароль в качестве своего мастер пароля? Почему тогда доверяете приватным ключам которые кто-то генерирует за вас?
Готовы ли вы использовать сгенерированный онлайн пароль в качестве своего мастер пароля? Почему тогда доверяете приватным ключам, которые кто-то генерирует за вас?
Открытым, проверенным годами библиотекам, которыми все пользуются я более доверяю, чем любым сайтам. Все таки модификация openssl, подпись, заливка, авторизация при установке сложнее чем тупо подменить js файл
Так что у меня есть достаточно причин доверять моему серверу с подписанной, доверенной openssl, и не доверять всяким сайтам.
Прошу прощения, был невнимателен. :)
А 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
Небольшой оффтопик, просто увидел приватный ключ, зацензурированный с помощью размытия. Лучше замазывать чёрным. Даже такой, казалось бы нечитаемый, текст можно восстановить, так как при размытии информация не столько теряется, сколько размазывается по соседним пикселям.
Корневики могут это сделать весьма просто…
*.org.ru?
*.org.ru — можно )
Add TXT record with the name/host _acme-challenge.org.ru with the value vlwTnpiyF0kdNPyQy7MfWyvsHgAcPNhNet2IwKI8B6U
С другой стороны, как они должны проверять все эти домены на подходимость для выписывания, чтобы кто-то не выписал на «слишком публичный» домен?
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 уровня»).
По логике, они должны его же и использовать для запрета выдачи wildcard. Я проверил несколько штук, почему-то не все под запретом. Например, *.chiba.jp — нельзя, а *.spb.ru — можно. Странно.
(да-да, я знаю, что _ не нормальный символ)
Технически, конечно, чем меньше лишних чужих скриптов на машине, тем лучше, но лично меня acme.sh смущает гораздо меньше, чем список пакетов, который средний серверный линуксовый дистр в наше время кладет мне на диск сервера при установке, даже не спрося меня, для чего я сервер думаю использовать. Acme.sh (как и certbot) я хотя бы способен пробежать глазами и поискать крамолу, а в десятках библиотек не разобраться, как ни называй их открытыми: может просто квалификации не хватить, и остается только верить в благие намерения мэинтейнеров.
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 точно не хочет.
Но если не хотите автоматизировать, и вам кажется, что вы за всем руками проследите, в чем мы вас уговариваем? Разговор только о том, что LE такое позволяет, а у многих ЦС обновлять серты обязательно нужно руками.
Ничего нигде не ребутит и не переписывает. Нужно только другую рут-папку для acme-challenge в конфиге веб-сервера указать.
В голосовании не хватает варианта ответа «Нет, буду как раньше получать через LE отдельно для каждого поддомена, потому что некогда перенастраивать».
Лично мой выбор — подожду полгодика пока во всех панелях оно будет работать из коробки, и тогда обновлюсь.
Почему нельзя? Я с помощью Certbot без проблем получил сертификаты для двух поддоменов одного домена.
По поводу DNS challenge. Чтобы пройти его автоматом ваш домен должен резолвиться через nameserver с поддержкой API + бот/скрипт должен уметь им пользоваться. В админке регистратора всегда можно перейти на другой nameserver, для которого уже есть готовое решение. Вот пример, я только что перевел свой домен на AWS Route 53 — он стоит пол-доллара в месяц.
Добавлю, что при экспериментах с DNS надо учитывать TTL — время кэширования в секундах, иногда надо подождать. Также удобно изучать DNS записи через dig/nslookup/их онлайн эквиваленты — можно явно указывать через какой NS сервер опрашивать.
#!/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
Раньше, конечно, «было не так» — раньше такой могущественный злоумышленник должен был выписывать для своих хацкерских хостов домены, указывая каждое имя (примерно по 100 вариантов на сертификат влезает).
А что вас пугает-то? В чем ненадежность?
Обычная критика LE сводится к тому, что LE выдает сертификаты всем, кто их попросит, и кто может подтвердить управление доменом — так это их прямая обязанность, и их процесс выдачи DV-сертификатов хорош и быстр. Вот что при этом его услугами воспользовались те или иные обманщики, которые попросили серты на paaypal.com или paypai.com — согласитесь, не дело ЦС решать, что похоже, что нет. Компьютер должен работать, человек — думать. Если я зайду на какой-нибудь online.sbepbank.ru (где окажется аккуратная копия морды с online.sberbank.ru), и введу там данные кредитки — то думать должен был бы я, а не ЦС, согласитесь!
Зато могу уверенно сказать, что, хотя те же банки юзают дорогущие сертфикаты от Symantec и прочих (где в цену еще и некая «страховка» заложена), но при этом есть масса людей, называющих банки обманиками. Так что, ЦС не должны выдавать сертификаты банкам и прочим потенциально разорительным для клиентов компаниям?
P.S. Я понял, что вы не любите LE, тогда как я считаю, что они меньше понтуются и больше работают. Но пока число скандалов с LE сильно меньше, чем у многих других ЦС, а реакция на вопросы быстра и действенна, в отличиии от политики замалчивания, которую некоторых другие ЦС демонстрировали во время кризисов.
Он лишь гарантирует, что вы передаёте данные на именно тот сервер что действительно обслуживает определённый домен и их по пути не перехватит Вася подменивший ваш wi-fi SSID.
Какую-то защиту от фишинга обеспечивают EV SSL сертификаты. А то что их не используют повсеместно все юрлица связано как раз со сложностью и стоимостью их получения. Да и по сути ничего не мешает зарегистрировать ООО «Сбербинк лимитед» и получить соответствующий сертификат.
Думаю, все проще:
$ 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"
Но, вообще, список high risk нужно иметь, совсем оно будет неглупо.
Let’s Encrypt начал выдавать wildcard сертификаты