Некоммерческий удостоверяющий центр Let’s Encrypt, контролируемый сообществом и предоставляющий сертификаты безвозмездно всем желающим, представил (https://letsencrypt.org//2017/10/17/acme-support-in-apache-h...) выпуск mod_md 1.0 (https://github.com/icing/mod_md), модуля к http-серверу Apache для автоматизации (https://github.com/icing/mod_md/wiki) получения и обслуживания сертификатов с использованием протокола ACME (https://tools.ietf.org/html/draft-ietf-acme-acme-07) (Automatic Certificate Management Environment).
При помощи mod_md можно упростить процесс сопровождения сертификатов на серверах с большим числом сайтов или в системах массового хостинга. При наличии mod_md пользователям не нужно заботиться об обновлении сертификатов, модуль сам получит необходимые сертификаты в сервисе Let’s Encrypt при первом запуске, организует их загрузку в mod_ssl (указание директив SSLCertificate* не требуется) и периодически будет обновлять сертификаты при приближении к истечению срока действия.
Модуль mod_md уже принят (https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/md/) в экспериментальную ветку Apache httpd и запланирован к бэкпортированию в стабильную ветку 2.4.x. Из нововведений экспериментальной ветки httpd также отмечается новая директива
SSLPolicy (https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslpolicy), упрощающая корректную настройку параметров TLS, благодаря выбору готовых типовых настроек вместо перечисления списка допустимых шифров. Предложено три базовых режима: modern - включение только самых передовых шифров, поддерживаемых в современных браузерах; intermediate - возможность отката на не самые современные, но не устаревшие шифры для старых клиентов; old - возможность использования устаревших шифров для таких систем, как Windows XP/Internet Explorer 6.
URL: https://letsencrypt.org//2017/10/17/acme-support-in-apache-h...
Новость: http://www.opennet.me/opennews/art.shtml?num=47403
> mod_mdЧтобы никто не догадался?
> Чтобы никто не догадался?ага, могли бы mod_acme или mod_letsencrypt назвать
https://github.com/icing/mod_md/issues/46
mod_mod будет загадочнее
> > mod_md
> Чтобы никто не догадался?ManagedDomain. Чтобы тоже никто не догадался.
mod_markdown? лил
Может для Nginx такое не просто появится, но и в поставку войдет? Наконец Symantec и компания зачешутся!
Ну для nginx уже давно есть. Правда довольно муторно для настройки.
certbot не сложен в настройке. Там на симлинках все.
Неужели Апачем до сих пор кто-то пользуется на продакшн-серверах?
Ещё как! Покуда это единственный сервер в котором программисты могут сами себе реврайтить и пхп конфиги менять он будет жить.
Неужели ПХП до сих пор кто-то пользуется на продакшн-серверах?
social network
Facebook, vk и куча овна на wordpress'е
И чё, Facebook и vk гоняют PHP через Apache?А WordPress - это не продакшн, 99% это любительские недосайтики по определению.
>А WordPress - это не продакшн, 99% это любительские недосайтики по определению.Да где ты видел чтоб софт юзали для того, для чего он делался? :-)
Зайди на любой он-лайн магазин, с нехилой вероятностью он окажется на WP+woocoоmmertZe :)
Хотя казалось бы что может быть _менее_ подходящим для этого?!
> Зайди на любой он-лайн магазин, с нехилой вероятностью он окажется на WP+woocoоmmertZeэто если открывается. А если вместо магазина какая-то херь про "b_cache_tag" - можешь быть уверены, это "cофт юзают для того, для чего он делается".
Facebook, Wikipedia и WordPress гоняют через HHVM
> Facebook, vk и куча овна на wordpress'еВот я прям как жопой чувствовал, что Facebook и vk на wordpress'е работают.
> Неужели ПХП до сих пор кто-то пользуется на продакшн-серверах?Пых слишком хорош, чтоб о нем так просто забыли.
Альтернативы?
Их нет.
Плагины текут у него безбожно. Хоть бы кто и valgrind'ом прогнал бы...
>Пых слишком хорош, чтоб о нем так просто забыли.Во(и)стену! Весь хайлоад крутится на пыхе+апач. Ещё тарантуул и вообще выходит непобедимо!
На весь хайлоад работает менее 1% всех ЫненеГров. Вот к примеру ты - не работаешь.
Так что тебе, чтоб было что пожрать, приходится те же *сено*сайтики писать, но на жабе ... что есть особенно извращённая пытка :)
>На весь хайлоад работает менее 1% всех ЫненеГровПлох тот инженегр, который не хочет спать с генералом ;)
Вообще, я больше по backend. И ЗП у меня несколько выше, чем у пыхеров. В остальном да, разницы никакой, ггг.
Ну, если говорить о "продакшн" серверах, то нгинкс там не более чем фронтенд. А значит и модуль к нему гоношить бессмысленно, один хрен он другими сервисами как новогодняя ёлка игрушками обвешен, одним больше, одни меньше...
Он ещё и терминирует https(ssl), так-что смысл в модуле в apache более сомнителен.
> Он ещё и терминирует https(ssl)сейчас модно внутренний траффик тоже пускать overssl и непременно http/2, чтоб в случае чего - хрен что просто так можно было посмотреть/поотлаживать.
И да, тут уже засветился минимум один горе-админ,который для такого траффика использует letsencrypt'овые сертификаты вместо самоподписанных с validity 10 лет. Тоже, видимо, чтоб жизнь медом не казалась.
А так-то модуль для летсенкрипта как раз правильно отражает _подходящую_ для него область применения - меганагруженные аж тремя посетителями в сутки сайтики на LAMP, которым ssl "нахрен не нужен, но пусть будет, халява же ж".
>которым ssl "нахрен не нужен, но пусть будет, халява же ж".пох, ты закусывай - середина недели же.
Сайтикам ssl нужен потому что без него гуголь бровсер начинает такие истерики, что хомячкофф разрывает на части.
Да - это единственная причина. Да - серьёзно! :-/
>>которым ssl "нахрен не нужен, но пусть будет, халява же ж".
> Сайтикам ssl нужен потому что без него гуголь бровсер начинает такие истерики,да лана, не читай вместо завтрака опеннетовские комменты,пока ничего не предвещает.
Вот сейчас специально ради тебя обновлю хромого (которым тестирую свою совсем-не-ssl-поделку) - и вряд ли увижу в адре...какойнахещеадрес, в строке поиска что-то кроме серой (i)
(опа - ну да, ну да)
Нет, если в нее потыкать пальчиком, она тебе скажет что все очень insecure, но редкий юзер туда жырным пальцом попадет, нарочно ж сделано крохотной, в отличие от больших-зеленых-блямб, а разбирать эти мелкие буковки и подавно не станет. Чтобы увидеть хотя бы перечеркнутый красным "http://" надо пять стилусов железных износить, тыкая по галкам settings. Ну да, попап-оконцев он у меня не открывает, канешна. (хм, и форма не спросила, точно ли я хочу слить ее всяму интернету - может, у меня хромой сломался? settings вроде сбрасываю регулярно. Нет, там, понятно, нет поля password)А истерика и страница "произошло что-то очень страшное, нажмите сюда для котиков" будет, если я им зайду на сайт со своим startssl'евским сертификатом. Без всякой возможности вообще хоть как-то продолжить работу (для юзера, конечно, впрочем, горе-админы, не знающие даже, как внезапно выяснилось, для чего вообще нужны CA, тоже вряд ли справятся).
Не то что прямо уж сильно нужно, но не помешает.
> mod_mdНазвание конечно..,
Чем их название mod_le не устроило?
А вайлдкарды, по dns оно сможет регистрировать?Вот у меня вопрос, НЕ холивара и хайпа ради, на офф форуме, пока, не решился задать, из-за моего английского.
Допустим мне, да и не только мне, нужна только domain validation (DV), про расширенную (EV) пока не говорю, хотя le только с DV и работает.
почему бы просто, не создавать самоподписанный сертификат, причём на любые домены, к которым есть доступ для добавления DNS-записи, любым алгоритмом который поддерживают браузеры, и на любой срок, после чего "слепок" (modules) ключа поместить в специальную DNS-запись для соответствующих A и AAAA записей.
Браузер обнаруживает самоподписанный сертификат, обращается к этой DNS-записи, сверяет отпечатки, и если они соответствуют, то считает сертификат и соединение надёжными, а если DNS-запись установлена и она или пустая или не соответсвует сертификату, пускай даже валидный и подписанный УЦ, но она не соответствует этому сертификату, то браузер люто ругается и блокирует ресурс.Вроде все счастливы были бы, и безопасность и скорость и надёжность на порядке выше, а УЦ, вроде LE, вообще были бы не нужны! Разве что только для EV и лентяям, которые привыкли просто платить и не думать.
Почему так не происходит, а вместо этого существует LE?
Какую кардинально-важную деталь я упускаю, кроме EV?
я в твоей схеме не понимаю, что помешает злоумышленнику, получившему контроль над твоей DNS записью, изменить и А запись, и слепок? В итоге - угоняем домен и у всех "светится" валидный сертификат.
> я в твоей схеме не понимаю, что помешает злоумышленнику, получившему контроль над
> твоей DNS записью, изменить и А запись, и слепок? В итоге
> - угоняем домен и у всех "светится" валидный сертификат.Если у Вас угнали доступы к DNS, то тут уже ничего Вам не поможет, кроме их восстановления у своего регистратора.
В классической схеме абсолютно аналогично, но это не проблема и даже не задача валидации!
>Если у Вас угнали доступы к DNSУ клиента же. Речь про то, что сертификат это способ проверки того, куда направляет DNS сервер. Если же проверка сертификата будет зависеть от того же DNS сервера, то сертификат нафиг не нужен - ибо MITM DNS в купе с MITM трафика браузера не "невероятная вещь".
Не совсем удачный вы выбрали ник.
> куда направляет DNS серверКуда в A или AAAA записях будет прописано, туда и отправит в любом случае.
Суть сертификата подтвердить что сервер именно тот, за кого себя выдаёт, а не кто-то левый, собственно это и может удостоверить соответствие слепка, хранимого в DNS слепку, полученному из сертификата сервера.
И как тут может вклиниться кто то левый (MITM), если 1 Он не будет обладать закрытым ключом и 2 Даже если он будет обладать валидным, но иным сертификатом, то слепок у него будет другой и он пойдёт лесом, в отличие от классической схемы.
Уже молчу про отсутствие проверок всяких откатов сертификата (SSLUseStapling) и прочего мусора, который тут просто не нужен.
Злоумышленник подсовывает _конкретному клиенту_ свои записи DNS, вместо твоих. И в этих записях будет и нужный IP и нужный слепок для фейкового сертификата по этому IP. От этого как раз и защищает классическая схема.Но про неудачный ник ты правильно сказал, данный вариант далеко не для всех очевиден.
Благодарю! Понял.
>>Если у Вас угнали доступы к DNS
> У клиента же. Речь про то, что сертификат это способ проверки того,
> куда направляет DNS сервер. Если же проверка сертификата будет зависеть от
> того же DNS сервера, то сертификат нафиг не нужен - ибо
> MITM DNS в купе с MITM трафика браузера не "невероятная вещь".Сертификат DV не является средством проверки DNS. Его выдача при любой схеме так или иначе завязана на DNS, кто имеет может рулить записями, тот может и сертификат получить. Без вариантов. Защитить от этого могут только EV-сертификаты.
> Защитить от этого могут только EV-сертификаты.Я никогда не использовал EV-сертификаты, но полагаю, что от этого и они тоже не защитят.
Ведь если вместо EV-сертификата подсунуть валидный DV-сертификат, то браузер также примет соединение, и покажет замочек, хоть и без большой зелёной полоски.
Большинство пользователей и не обратят на это внимание, а если и обратят, то подумают что ничего страшного, ведь замочек-то есть.
Смысл от EV-сертификата будет только тогда, когда браузер будет знать, что к этому ресурсу можно обращаться только через EV-сертификат, посредством чего-то наподобие HSTS-списков.
> Ведь если вместо EV-сертификата подсунуть валидный DV-сертификат, то браузер также примет
> соединение, и покажет замочек, хоть и без большой зелёной полоски.
> Большинство пользователей и не обратят на это внимание, а если и обратят,
> то подумают что ничего страшного, ведь замочек-то есть.Ну это уже другая история. Можно сказать, что никакие сертификаты ни от чего не защитят, потому что пользователь, жаждя поскорее дорваться до прона, добавит левый сертификат в доверенные.
> Смысл от EV-сертификата будет только тогда, когда браузер будет знать, что к
> этому ресурсу можно обращаться только через EV-сертификат, посредством чего-то наподобие
> HSTS-списков.Есть HPKP, и для него не имеет значения, халявный у тебя сертификат или платный.
>Сертификат DV не является средством проверки DNSи
>>куда направляет DNS серверэто не одно и то же.
Хотспот в кафе может вместо 8.8.8.8 (подставьте любой адрес) направлять куда ему вздумается. И там www.вашлюбимыйбанк.com могут отресолвить в то, что им угодно.
Но для получения валидного сертификата этого не достаточно. Надо еще то же провернуть с доверенным центром сертификации.
да тут пичаль полная - клиент безнадежен, даже со второго раза до него не доходит.ну вот такие люди у нас и идут в админы, других сто лет не делают.
> почему бы просто, не создавать самоподписанный сертификат, причём на любые домены, к которым есть доступ для добавления DNS-записиDANE уже давно придумали. Но у него есть два недостатка: во-первых, он имеет смысл только при повсеместном использовании DNSSEC, а во-вторых, он ну очень сильно помешает УЦ торговать воздухом, даже сильнее, чем Let's Encrypt.
> он имеет смысл только при повсеместном использовании DNSSECон даже при повсеместном не имеет никакого смысла, потому что мы просто вернем юзеру not found на попытку запросить подписи. Ну или подпишем, чем мы хуже?
dnssec работает только пока у тебя твой ns - trusted, и ты уверен что корневые подписи не подменены (ибо тоже можно).
У обычного пользователя даже первый пункт отсутствует.А если начать совать подписи ns в операционные системы (к чему все идет) - мы, скорее всего, быстренько вернемся к торговле воздухом.
Правильное же решение - в выкидывании на помойку истории всех "удостоверяющих центров", и замена их индивидуальным доверием пользователя каждому конкретному сертификату для каждого индивидуального сервера. Который может быть (для дополнительной малоэффективной защиты) подписан кем-то, но совершенно точно не должен меняться раз в неделю, как это заставляет всех делать letsdecrypt.
> DANE уже давно придумали.DANE - это совсем другое, это механизм аутентификации, а не валидации.
Зато в нём нет лишних сущностей, коей является УЦ.
> Какую кардинально-важную деталь я упускаю, кроме EV?Провайдера клиента.
Провайдер может и DNS записи подменить и трафик до сайта спроксировать.
И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в DNS.
>> Какую кардинально-важную деталь я упускаю, кроме EV?
> Провайдера клиента.
> Провайдер может и DNS записи подменить и трафик до сайта спроксировать.
> И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в
> DNS.И как же эту "величественную" проблему решает классическая схема с УЦ?
>>> Какую кардинально-важную деталь я упускаю, кроме EV?
>> Провайдера клиента.
>> Провайдер может и DNS записи подменить и трафик до сайта спроксировать.
>> И будет у клиента валиднейший https до прокси провайдера, подтвержденный подписью в
>> DNS.
> И как же эту "величественную" проблему решает классическая схема с УЦ?За счет списка доверенных УЦ на клиенте.
Сертификат УЦ лежит на клиенте, клиент его не запрашивает через интернет каждый раз.
Следовательно, провайдер здесь не может просто так вклиниться и подсунуть свой сертификат.Я согласен, что у доверенных УЦ есть свои минусы.
Но в вашей схеме серификат передается вообще по нешифрованным каналам - DNS.
Это сводит на нет все дальнейшее шифрование.
> За счет списка доверенных УЦ на клиенте.
> Сертификат УЦ лежит на клиенте, клиент его не запрашивает через интернет каждый
> раз.
> Следовательно, провайдер здесь не может просто так вклиниться и подсунуть свой сертификат.А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его?
А также, что бы именно вклинится в трафик, а не просто подменить ресурс своим, провайдер должен обладать закрытым ключом сервера, а так он сможет лишь подменить сервер, как в моей, так и в классической реализации.
> А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его?Ну пойди зарегистрируй(кстати, они подписываются, а не регистрируются) валидный сертификат на google.com. Расскажешь об успехах.
> А также, что бы именно вклинится в трафик, а не просто подменить
> ресурс своим, провайдер должен обладать закрытым ключом сервера, а так он
> сможет лишь подменить сервер, как в моей, так и в классической
> реализации.Используется два соединения. Одно от тебя к провайдеру(злоумышленику), второе от провайдера к серверу. В твоей схеме это работает на ура, в классической не получится сделать первое соединение доверенным, браузер ругаться будет.
>> А что мешает провайдеру, получившему контроль над ДНС, зарегистрировать валидный сертификат и использовать его?
> Ну пойди зарегистрируй(кстати, они подписываются, а не регистрируются) валидный сертификат на google.com. Расскажешь об успехах.Да без проблем, скидывайте доступы на их ДНС, и я через сабж получу подписанный серт, при условии если они не заметят слив и не перекроют мне доступ раньше.
Но из Хрома этим сертом всё равно не получится воспользоваться.> Используется два соединения. Одно от тебя к провайдеру(злоумышленику), второе от провайдера
> к серверу. В твоей схеме это работает на ура, в классической
> не получится сделать первое соединение доверенным, браузер ругаться будет.Стало ещё яснее.
А всё же если объединить обе схемы, то есть используя подписанный УЦ серт, и ДНС запись со слепком, и что бы браузер обнаружив её требовал и валидности серта и соответствие его слепку из ДНС, причём этот слепок не должен кешироваться у клиента, а запрашиваться у ДНС при каждом запросе, то такая схема была бы ещё надёжнее и защищала от левых УЦ.
И конечно же эту ДНС-запись в обязательном порядке должны запрашивать и учитовать все популярные браузеры.
> Стало ещё яснее.
> А всё же если объединить обе схемы, то есть используя подписанный УЦ
> серт, и ДНС запись со слепком, и что бы браузер обнаружив
> её требовал и валидности серта и соответствие его слепку из ДНС,
> причём этот слепок не должен кешироваться у клиента, а запрашиваться у
> ДНС при каждом запросе, то такая схема была бы ещё надёжнее
> и защищала от левых УЦ.
> И конечно же эту ДНС-запись в обязательном порядке должны запрашивать и учитовать
> все популярные браузеры.Есть несколько другой вариант - CAA записи.
https://www.opennet.me/tips/3028_ssl_https_caa_cert_dns.shtml
> Есть несколько другой вариант - CAA записи.
> https://www.opennet.me/tips/3028_ssl_https_caa_cert_dns.shtmlЭтот вариант мне известен и уже применяется мной.
Но, к сожалению, пока нет обязательного требования от всех УЦ, учитывать CAA-записи. :-(
LE её конечно же учитывает, а какой-нибудь Восайн или Комодо могут и проигнорировать, да скорее так и делают.
> Я согласен, что у доверенных УЦ есть свои минусы.
> Но в вашей схеме серификат передается вообще по нешифрованным каналам - DNS.
> Это сводит на нет все дальнейшее шифрование.Ничего подобного!
Сертификат состоит из пары закрытого и открытого ключей.
Открытый ключ передаётся всегда всем и как угодно!
Закрытый ключ лежит только на сервере и он никому никогда не передаётся.
В ДНС прописан отпечаток ключа, а не сам ключ.
s/нешифрованным/ненадёжным/
> В ДНС прописан отпечаток ключа, а не сам ключ.Провайдеру ничего не мешает сгенерить серитифкат, а в DNS отдавать его слепок.
Если все ограничивается только ненадежным DNS, без дополнительных проверок чего-либо ещё, вам придется верить DNS на слово.
А что туда записать - технический момент.
Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки сертификатов.
Т.е. защита от подмены сертификата на другой, даже валидный.
Но там очень легко выстрелить себе в ногу так, что оторвет голову.
Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш текущий сертификат - фигня.
И все, нужен новый сертификат.
> Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки
> сертификатов.мда, у нас сегодня парад анонов, где-то слышавших звон?
pkp не имеет ни малейшего отношения к dns. И да, это защита от подмены сертификата на другой, подписанный настоящим Trusted Authority, но не твой.
> Т.е. защита от подмены сертификата на другой, даже валидный.
_после_ того, как ты каким-то чудом получил правильный хэш и сохранил его в браузере. Без всякого dns, банальным http заголовком. Понятно, что если ты гугль, а браузер хром, чудо осуществляется довольно легко (правда, тебе еще могут подменить сам хромой, но это уже сложнее).
> Но там очень легко выстрелить себе в ногу так, что оторвет голову.
это единственная верная фраза
> Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш
> текущий сертификат - фигня.этого как раз сделать не особо-то получится.
> И все, нужен новый сертификат.
и вот этого, что характерно, тоже - и вот тут действительно выстрел себе в жoпу. Очень легко можно сделать так, что поменять свой валидный но немного запаленный сертификат не получится, потому что он гвоздиком прибит (а его, например, УЦ отозвал, потому что ты просохатил логин - или чем-то этому УЦ не понравился. Или после маски-шоу в датацентре неизвестно, сколько и у кого стало его копий).
Полагается на этот случай прибивать гвоздиком не один, а сразу несколько - при этом второй и третий хранить где-то в надежном не подключенном к интернетам месте, и выводить на сервера только в случае факапа с первым. Опять же, если ты гугль, в этом нет никакой проблемы - сколько надо, столько сам себе заранее и выдал.
Если же ты платишь за них по $90 штучка (или по $800 за EV), то тут у тебя начинаются некоторые проблемы, а startssl'я-то, который мог напечь тебе хоть сотню этих EV бесплатно, больше нет. Возможно, еще и это послужило истиной причиной его ликвидации.
Поэтому, в реальном мире, pkp используется не для чего-то хорошего, а ровно наоборот - те самые, которым ничего не стоит ни добавить свои сертификаты вместе с суммами правильных прямо в исходный код, ни понавыпускать самим себе десяток запасных, если с первым что не так, защищают подобным образом свой траффик от изучения - угадай-ка, кто это у нас?
> pkp не имеет ни малейшего отношения к dns.Да, неправильно написал.
Там заголовки в HTTP ответе.> Если же ты платишь за них по $90 штучка (или по $800
> за EV), то тут у тебя начинаются некоторые проблемыЕсли проект коммерческий и вышел на некоторую прибыль, 90$ - не проблема.
> Если проект коммерческий и вышел на некоторую прибыль, 90$ - не проблема.обычно таким проектам по многим причинам приходится раскошеливаться на EV, а там 90 внезапно превращаются в около-900. И их уже выкидывать стопками ради очень сомнительного улучшизма могут разьве что "коммерческие проекты" размером с мордокнигу.
А для маргинального проектика с копеейчной прибылью, еле-еле покрывающей расходы, _еще_раз_ $90 за воздух - уже совсем лишняя трата.
А вот microsofтогуглегрызку - оно на халяву дается. Поэтому при попытке назойливо поинтересоваться, что это такое они о тебе сливают хозяевам - тебя ждет pkp'шный облом.
> А для маргинального проектика с копеейчной прибылью, еле-еле покрывающей расходы, _еще_раз_
> $90 за воздух - уже совсем лишняя трата.Маргинальному проектику зеленый свет в сторону let's encrypt.
А в крупных компаниях - да, трудновато будет уговорить перевести все на LE.
> Вообще есть технология HTTP Public Key Pinning, там в DNS прописываются отпечатки
> сертификатов.
> Т.е. защита от подмены сертификата на другой, даже валидный.
> Но там очень легко выстрелить себе в ногу так, что оторвет голову.
> Если неправильно настроить, можно закешировать на клиентах запись о том, что ваш
> текущий сертификат - фигня.
> И все, нужен новый сертификат.Я так понимаю Вы имеете ввиду HTTP Public Key Pinning (HPKP).
Это тоже не то, так как она, как Вы ране упомянули, кеширует у клиента отпечаток ключа, не давая возможности, до истечения срока кеша, изменить сертификат самому серверу, что очень не удобно.
Мне кажется это лишнее и ненужное действе. Не нужно кешировать слепок ключа, его нужно при каждом обращении сверять с ДНС, что бы сервер мог, при желании, хоть каждый день их менять, и при этом не у кого их не подписывать в ограниченном количестве. А пользователь будет уверен, что он общается с этим сервером.
А если клиент, то есть администратор ресурса, не доверяет своему собственному регистратору домена, то тут уже ничего не поможет, да и классическая схема от этого не защищает.
> не давая возможности, до истечения срока кеша, изменить сертификат самому серверу, что очень не удобно.Не совсем так. Просто о замене сертификата надо побеспокоиться заранее, и запинить два публичных ключа — текущий и следующий, для которого сертификат ещё не выписан.
> его нужно при каждом обращении сверять с ДНС
Это именно то, что делает DANE. И DNS тут является слабым звеном, потому что для DNSSEC сильная криптография всё ещё встречается редко.
ты все же феноменально тyпой. То есть ладно, еще - быть админом но не понимать и не знать элементарного, тыщи этих недоучек. Но еще и делать глубокомысленные выводы из своего незнания?Да, именно эту проблему - возможность mitm тем, кто контролирует каналы или dns, и только ее - решает УЦ и не решает https сам по себе. Именно для этой цели и придумана вся технология. Как можно этого не понимать, и при этом работать в IT - вообще в голове не укладывается.
Нет, это просто п-ц какой-то...
осталось написать модуль админки под это в виде mod_mdadm (with zfs support)
Ага, и mod_luks.
Почему не сделать выдачу на пол/целый год?
> Почему не сделать выдачу на пол/целый год?В маркетинге сказали, что, мол, чем больше они за нами бегают, тем лучше Товар. Они-то знают!!
> Почему не сделать выдачу на пол/целый год?
>> Почему не сделать выдачу на пол/целый год?
> https://letsencrypt.org/2015/11/09/why-90-days.html%) "Как научиться про[полимеры]вать ключи и перестать беспокоиться. Опера-балет в двух актах, коротенько."
> %) "Как научиться про[полимеры]вать ключи и перестать беспокоиться.
> Опера-балет в двух актах, коротенько."обрати только внимание - правдивый ответ - во втором акте.
"мы таким образом *заставим* вас использовать [нашу] автоматику" (запудрив вам мозги про беспокойство о просере ключей)
Соответственно - лишим вас возможности не хранить нешифрованные ключи на сервере, а ваших пользователей - доверять вашему _сертификату_, а не только нашей подписи под ним - для чего, полагаю, все и затеяно на самом деле.Ну и попутно заставим либо исполнять свои кривые скрипты, либо вообще втыкать в веб-сервер наши модули - а что они там делают (и что будет делать версия x.y.z+1 ) - тебе знать необязательно. Но это так, побочная фишка, скорее всего.