Comments 21
При сроке действия сертификата в 90 дней ещё через три месяца цифра выданных сертификатов должна удвоиться. Или один и тот же сертификат, продлённый пять раз по 90 дней — будет считаться за один и тот же?
Вообще, на днях думал, что пора уже переводить свои проекты с китайских WoSign на Let's encrypt… Вроде ещё в бета-тестировании, но, надеюсь, что большинство шишек уже набиты и поправлены.
Вообще, на днях думал, что пора уже переводить свои проекты с китайских WoSign на Let's encrypt… Вроде ещё в бета-тестировании, но, надеюсь, что большинство шишек уже набиты и поправлены.
Жаль, не приведена статистика по .ru — полез на plot.ly — но и там тоже всё спрятано в other.
Тут statonline.ru мы каждый месяц обновляем статистику по .ru.
Хотел перейти на Let's Encrypt, чтобы автоматизировать получение сертификатов. Но на деле всё оказалось не так удобно, как хотелось бы. nginx не запустится, если по указанному пути не найдёт сертификата. Либо придётся делать временный конфиг без указания пути, либо генерировать временный самоподписанный сертификат (или подсовывать старый действующий, если он был). Реализаций протокола ACME уже как грязи, но такую вот полную автоматизацию с самоподписанными сертификатами ни одна не умеет. Т.е. автоматизировать весь процесс разворачивания нового сайта можно только с собственными костылями.
Да, первоначальное получение сертификата ручками. Потом уже можно по крону настроить продление и обновление конфига nginx. Ждём плагина для nginx.
Официальный плагин, судя по тому, что о нём пишут, тоже странная вещь. Я надеялся, что он будет просто парсить конфиг и подкладывать сертификаты в прочитанные пути. А они хотят вместо этого генерировать часть конфига для https. Кому это надо?
Мой баттхерд вот к чему: хочется наконец решить этот вопрос с помощью SaltStack/Ansible/Puppet/etc, а они предлагают одну рутину заменить на другую.
Мой баттхерд вот к чему: хочется наконец решить этот вопрос с помощью SaltStack/Ansible/Puppet/etc, а они предлагают одну рутину заменить на другую.
Доки по офф. плагину нет. Есть только код, по которому мне, как человеку не знакомому с python, ничего не понятно. Вижу только, что он пытается парсить конфиги. Во всех манах рекомендуют использовать способ с webroot.
Где вы вообще нашли информацию как его юзать?
Где вы вообще нашли информацию как его юзать?
Есть довольно несложное решение на базе acmetool. Общая идея в том, что в момент запроса сертификата, acmetool изображает из себя http сервер, а в nginx по известному url на default сервер стоит прокси в acmetool.
Поэтому автонастройка https в nginx происходит в 3 шага:
1) прописываем cname на хост с nginx+acmetool
2) через acmetool запрашиваем сертификат. При правильно настроеном пробросе, запрос по ненастроеному (пока) домену провалится в acmetool,
проходит авторизацию, и выданный сертификат кладетс в заранее известное место.
3) Из темплейта генерим конфиг сервера для nginx и делаем рестарт — все.
Еще 2 момента:
1) в уже настроеном конфиге все равно надо оставить прокси на acmetool для
автоматического обновления сертификатов (у меня вообще на 80-м порту никого нет, потому оно так и проваливается по default)
2) Прописать acmetool в cron — он сам проверяет, надо ли обновить сертификаты, и сам же обновляет.
Если есть интерес, могу завтра выложить соответствующие куски из своего ansible playbook
Поэтому автонастройка https в nginx происходит в 3 шага:
1) прописываем cname на хост с nginx+acmetool
2) через acmetool запрашиваем сертификат. При правильно настроеном пробросе, запрос по ненастроеному (пока) домену провалится в acmetool,
проходит авторизацию, и выданный сертификат кладетс в заранее известное место.
3) Из темплейта генерим конфиг сервера для nginx и делаем рестарт — все.
Еще 2 момента:
1) в уже настроеном конфиге все равно надо оставить прокси на acmetool для
автоматического обновления сертификатов (у меня вообще на 80-м порту никого нет, потому оно так и проваливается по default)
2) Прописать acmetool в cron — он сам проверяет, надо ли обновить сертификаты, и сам же обновляет.
Если есть интерес, могу завтра выложить соответствующие куски из своего ansible playbook
Интересно, будет ли в blogspot и github pages реализован https для кастомных доменов? Если да, то интересна техническая реализация, ведь наверняка работать оно будет с Let's Encrypt.
Сегодня написали мне на почту с kloudsec.com, с предложением потестить свой сервис, который позволяет использовать HTTPS для кастомных доменов с GitHub Pages, работает он как раз с Let's Encypt.
Пример: https://amet13.name/virtuozzo-tutorial/
Так что вопрос с GitHub для меня решен.
Пример: https://amet13.name/virtuozzo-tutorial/
Так что вопрос с GitHub для меня решен.
Сервис прикрыли, печально.
https://www.reddit.com/r/webdev/comments/4s3kmf/got_an_email_saying_that_kloudsec_will_be/
https://www.reddit.com/r/webdev/comments/4s3kmf/got_an_email_saying_that_kloudsec_will_be/
Не сочтите за рекламу, но не могу пройти мимо — для плеска есть модуль Let's encrypt, который упрощает и без того элементарную процедуру до двух кликов мышью.
Мы используем для доменов 4 уровня в mvd.ru сертификаты от Let's Encrypt. Они были единственным приемлемым решением для этой цели (до завершения работ по созданию государственного удостоверяющего центра).
Из минусов могу отметить, что для автоматизации не обошлось и без собственных костылей и все вышеизложенные минусы мы ощутили в полной мере. А также при обновлении сертификатов пачками, за раз можно отправить запрос только на 100 штук.
Для того чтобы сайт был доступен сразу после создания нам приходится его открывать без какой либо криптографии, а в административный интерфейс разрешать ходить по самоподписному сертификату, когда сертификат будет выпущен мы меняем конфиг веб-сервера и все становится на свои места.
Решение не сильно изящное, но позволяет сразу предоставить доступ к сайту.
Из минусов могу отметить, что для автоматизации не обошлось и без собственных костылей и все вышеизложенные минусы мы ощутили в полной мере. А также при обновлении сертификатов пачками, за раз можно отправить запрос только на 100 штук.
Для того чтобы сайт был доступен сразу после создания нам приходится его открывать без какой либо криптографии, а в административный интерфейс разрешать ходить по самоподписному сертификату, когда сертификат будет выпущен мы меняем конфиг веб-сервера и все становится на свои места.
Решение не сильно изящное, но позволяет сразу предоставить доступ к сайту.
А может кто-нибудь в курсе, есть ли сейчас какие-то акции или выгодные предложения на code signing certificate (обычный, не ev)? Вроде той, по которой в свое время можно было почивший verisign взять за 99 баксов на год. Пока самое дешевое, что нашел, это comodo за 179 что ли. Народ говорил что вроде как сейчас какая-то акция опять за 99 бродит, но что-то найти не могу.
Возьмите comodo code signing certificate у реселлеров, а не у комодо напрямую. У того же gogetssl он стоит от $84/y (если брать на год) до $70/y (если брать на 3 года).
Да была такая идея, уже нашел несколько реселлеров, но что-то подозрительно. У cheapsslusa 80$/год. Вы сталкивались сами, не кидалово?
Спасибо. Простите плюсануть не могу, плохиш)
Спасибо. Простите плюсануть не могу, плохиш)
Брал domain-validated обычные и wildcard для tls у реселлера — проблем нет. Обычно сами CAшки несколько завышают цены (а иногда используют заградительные тарифы) для уменьшения геморроя по работе с мелкими клиентами, давать API для реселлера (при том, что все значимые с точки зрения безопасности действия реально выполнял comodo) гораздо проще и удобнее.
Все стандартные плюшки (типа плашек secured by) предоставляются тем же CA, а не реселлером.
Все стандартные плюшки (типа плашек secured by) предоставляются тем же CA, а не реселлером.
Sign up to leave a comment.
Центр сертификации Let's Encrypt выдал миллион бесплатных сертификатов