ssl free

Может кто поделится своим опытом получения бесплатного и легитимного сертификата?

Настраиваешь nginx на работу с webroot-плагином, пишешь systemd сервис/timer для выпуска/обновления сертификатов.

PS. Мимокрокодил-админ локалхоста, да.

Let's Encrypt.

Там с Let's Encrypt движений почти нет. Запустил скрипт их же и он все сделал за 2 минуты. Через 3 месяца повторил или можно автоматизировать весь процесс. Все легко гуглится.

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

Ты явно что-то делаешь не так.

letsencrypt

движений раз в десять больше

неосилятор? одна команда - получить, другая команда - обновить.

Сервер для верификации тоже нужно запустить. И скопипастить файл.

Оу, немного оффтоп, но в тему.

Был дебиан 7 и руками использовал certbot.

Переустановил ос, хочу теперь использовать какой-нибудь dehydrated. Тут вопрос, мне нужно какие-нибудь дополнительные телодвижения совершать или просто считать что выполняю всё с нуля? (остался бекап /etc/letsencrypt). А, ещё, если важно, ранее использовал ./letsencrypt-auto certonly --webroot, хотелось бы этот способ оставить.

Может кто поделится своим опытом получения бесплатного и легитимного сертификата?

Let's Encrypt + certbot --webroot.

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

Не выдумывай. В стартссл куда больше телодвижений.

В manual mode LE их тоже немало.

всем спасибо. переконфигурял все на LE.

Без телодвижений и бесплатно https можно получить, если cloudflare использовать

cloudflare использовать

А зачем тогда https?

движений раз в десять больше

Это шутка? le ваще ставится на изи.

Это шутка? le ваще ставится на изи.

Единственный момент, по умолчанию le каждый раз подписывает новый ключ, что несколько усложняет, мягко говоря, использование HPKP.

Кроме certbot'а есть и другие клиенты, в которых это поведение настраивается, насколько я знаю.

это поведение настраивается, насколько я знаю.

Ты можешь не менять ключ, и переподписывать один и тот же csr, правда при этом напрочь теряется весь смысл смены сертификата каждые три месяца.

Единственный момент, по умолчанию le каждый раз подписывает новый ключ, что несколько усложняет, мягко говоря, использование HPKP.

Не вижу сильного практического смысла в HPKP. А там где он есть, можно обойтись и самоподписными.

Можешь просто сделать HPKP, только к самому CA.

Не вижу сильного практического смысла в HPKP.

Некоторая защита от mitm и/или подмены с сертификатом, подписанным скомпрометированным центром.

А там где он есть, можно обойтись и самоподписными.

Особенно если знать, что Chrome отключает пиннинг, если цепочка доверия завершилась на самоподписанном сертификате, чтобы работали https прокси, антивирусы и прочий lawful interception.

Можешь просто сделать HPKP, только к самому CA.

И когда он поменяется, это обязательно произойдет, твой сайт превратится в тыкву. А если будет скомпрометирован, ты сам лишил себя защиты HPKP.

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

Они не так часто меняются. Например:
COMODO ECC Domain Validation Secure Server CA (expires in 12 years and 6 months)
COMODO ECC Certification Authority (expires in 3 years and 2 months)
Ну и резервные ключи никто не отменял. Главное ведь, чтобы какой-нибудь CN NIC, или вроде того сертификат не выпустил, остальное же излишняя паранойя и неудобства. Потому-что как раз если ты свой сертификат будешь указывать то при том же LE ты просто замучаешься обновлять pin'ы каждый 3 месяца. Частичная HPKP, это намного лучше, чем вообще без HPKP, и не сильно хуже, чем если ты будешь указывать конкретно свой сертификат. Но намного проще в обслуживании.

expires in 12 years and 6 months

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

просто замучаешься обновлять pin'ы каждый 3 месяца

Ты можешь придерживаться привычного интервала замены ключа, подписывая один и тот же csr в промежутке.

Частичная HPKP, это намного лучше

Польза HPKP в том, что он позволяет снять абсолютное доверие с CA.

Ты можешь придерживаться привычного интервала замены ключа, подписывая один и тот же csr в промежутке.

А если сертификат меняется случайно, и ты это не контролируешь? Потом субдоменов может быть больше десятка, так ты можешь одни настройки HPKP прямо в nginx.conf использовать, а не для каждого сайта отдельно.

А если сертификат меняется случайно, и ты это не контролируешь?

Пинится не сертификат, а публичный ключ. Или ты не контролируешь создание ключей? Cloudflare, другой CDN? В этом случае ты и так доверяешь непонятно кому, хуже уже не будет :)

субдоменов может быть больше десятка

Больше десятка субдоменов и нет wildcard? Отлаженный процесс перевыпуска ключа/сертификата для одного домена тривиально отмассштабировать его на любое количество.

Cloudflare, другой CDN?

Да, Cloudflare, конечно же, правда с HTTPS (strict) и с Authenticated Origin Pulls, ну и pin'ится CA, в данном случае COMODO.

Больше десятка субдоменов и нет wildcard

А зачем он нужен, если letsencrypt сертификаты выпускаются банально через API, в любом количестве. Основное удобство еще и в том, что можно просто сделать HPKP вместе с subdomains в nginx.conf, в не отдавать отдельные заголовки для каждого хоста (субдомена).

В этом случае ты и так доверяешь непонятно кому, хуже уже не будет :)

Это глупо не использовать СF, если у тебя нету своего CDN. Ну и даже если он, есть то его опять же можно к CF подключить.

pin'ится CA, в данном случае COMODO

Рекомендую тогда пинить оба: промежуточный и корневой, а также le и свой резервный ключ на всякий случай.

Это глупо не использовать СF, если у тебя нету своего CDN.

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

Рекомендую тогда пинить оба: промежуточный и корневой, а также le и свой резервный ключ на всякий случай

Да так и делаю, кроме le. Под CA имеются в виду и intermediate certificate, тоже. Вся цепочка короче.

Если ты неуловимый Джо, данные посетителей и свои доверяешь третьим лицам

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

Глупо не верить в криптографию

В какую «криптографию» я должен верить, если у Cloudflare твой трафик в расшифрованном виде? Они работают как кеширующий реверс-прокси на anycast. Твой трафик перепаковывают со своими ключами, если у тебя не Business или Enterprise тарифный план, где можно залить свои ключи или выдавать их on-demand.

Практически все клиенты умеют PFS. Да и вклиниться между origin сервер и сервером CF тоже нельзя, начиная с HTTPS и HTTPS (strict). Самое плохое, что по TOS они могут сделать это добавить дополнительные cookies для лучшей персонализации клиента. Если учитывать специфику сервиса, то если они что-то плохое делать начнут, например встраивать рекламу и т.д и количество юзеров CF, то это сразу станет известно. Кэшем, ты то же можешь сам управлять, удалить например оттуда можно спокойно. Ну и банально у них один из лучших DNS вообще, и заставить идти все напрямую, можно одним кликом. Алсо и в основном все платежи все равно у всех все равно идут через 3-rd party процессинг, т.е. ничего интересного и нет кроме самой статики, которая из кэша CF гораздо лучше отдается.