Тут вот nataraj рассказывает о своем опыте приобретения коммерческих сертификатов для https сайтов.

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

Поэтому я использую letsencrypt. В качестве клиента я использую acme-tiny, которую обвязал своими скриптами с тем, чтобы процесс был полностью автоматизирован и сертификаты перевыпускались автоматически.

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

Второй - от специального непривилегированного юзера и выполняет собственно взаимодействие с letsencrypt.
Можно было бы в контейнер какой засунутЬ, но я счел это лишним. acme-tiny я доверяю, потому что я ее читал. (там всего 200 строк на питоне).

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

Скрипты можно посмотреть здесь.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1911851.html. Please comment there using OpenID. Now there are comments

Продолжаю разбираться с letsencrypt. Понятно что это гадость. вроде systemd, но деваться некуда. Все альтернативные бесплатые CA за этот год были успешно уничтожены.

Обнаружил, что автор acme-tiny рекомендует по крону повторно выписывать сертификат на тот же самый ключ.

По-моему, в этом вопросе он глубоко неправ. Плтому что с точки зрения пользователя сайта смена сертификата и смена ключа полностью эквивалентны. Браузер не смотрит на ключ, браузер смотрит на то, что ключ соответствует указанному в сертификате.

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

Правда, как обычно, идея перегенерации ключа по крону несет свои собственные риски.
В текущем виде acme-tiny требует доступа только к ключу аккаунта на letsencrypt и к CSR. То есть скрипт, активно работающий с сетью и теоретически могущий быть проэксплойченным через дырки в стандартной библиотеке питона, самом питоне и libc, не имеет доступа к вашему закрытому ключу.

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

То есть нужно аккуратно поделить задачу на три части

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

2. Посредством acme-tiny или еще какого auditable клиента к letsencrypt получить сертификат.

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

Обдумывал мысль, как бы запихнуть операцию 2 в chroot но решил что для acme-tiny это явно не вариант - в chroot придется тащить всю питоновскую инфраструктуру. Пожалуй, с dehydrated это бы лучше получилось.

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

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1238540.html. Please comment there using OpenID. Now there are comments

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

Начинать написание нового материала после столь продолжительного отдыха от этого дела — труднее всего. Но раз цель поставлена — надо идти до конца. Начну немного издалека.

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

Под хабракатом вы найдете Quick Start по использованию Docker на уровне, необходимом для решения конкретных задач, обозначенных ниже, без углубления в "дебри" виртуализации и прочих сопутствующих тем. Если вы до сих пор хотите начать успешно использовать эту современную технологию, тем самым значительно упростив целый ряд процессов: от разработки веб-продуктов и до разворачивания и переноса оных под какое-либо современное оборудование — прошу под кат!

Читать дальше →

StartSSL, pionera en esto de dar certificados gratutitos, ha lanzado una agresiva campaña de respuesta a Let’s Encrypt ofreciéndonos su propio servicio para automatizar la instalación, gestión y renovación de certificados: StartEncrypt. Si alguien lo ha probado ya que avise y, si no, tendremos que hacerlo por aquí en breve. Que remedio

“Papá” Google dejó claro hace unos meses que quería darle un empujoncito en sus rankings a quienes usaran https en lugar de http. Y allá vamos todos como tiernos corderitos a hacer la migración. ¡Faltaría más! Lo bueno (por verle algo) es que a los que esto no nos va ni nos viene nos sirve … Continuar leyendo "Pasar de http a https en una web con nginx y wordpress"