Пользователь
0,0
рейтинг
3 декабря 2015 в 22:12

Разработка → Let's Encrypt выходит в публичную бету: HTTPS всюду, каждому, отныне и навсегда бесплатно

Let's Encrypt

Let's Encrypt — это некоммерческая инициатива, предоставляющая бесплатный, автоматизированный и открытый CA (certificate authority — центр сертификации), созданный ISRG на благо общества:

  • бесплатно: владелец всякого доменного имени может воспользоваться Let's Encrypt и получить доверенный (читать как «признаётся любым современным браузером») TLS-сертификат (TLS — наследник SSL) совершенно бесплатно;
  • автоматизированно: Let's Encrypt предоставляет бесплатное и свободное программное обеспечение (клиент), которое, будучи настроенным на веб-сервере, может полностью автоматически запрашивать безвозмездно предоставляемые сертификаты Let’s Encrypt, автоматически конфигурировать и обновлять их;
  • безопасно: Let’s Encrypt строится как платформа для продвижения наилучших практик безопасности TLS как на стороне центра сертификации (CA), так и на стороне веб-сайтов, помогая администраторам должным образом настраивать веб-серверы;
  • прозрачно: информация о выпуске и отзыве каждого сертификата Let's Encrypt доступна вполне и публично так, что любой желающий изучить её сможет это сделать;
  • свободно: протоколы взаимодействия со CA, позволяющие автоматизировать процессы выпуска и обновления сертификатов, будут опубликованы как открытый стандарт для максимального внедрения;
  • кооперативно: как и любой протокол, лежащий в основе Интернета и Всемирной паутины, Let’s Encrypt является совместным, неподконтрольным какой-либо конкретной организации некоммерческим проектом созданным исключительно для того, чтобы принести пользу обществу.

Let’s Encrypt выходит в открытое бета-тестирование сегодня, 3 декабря 2015 года. Публичная бета означает, что все системы Let's Encrypt становятся доступными для каждого, кто хотел бы получить сертификат. Регистрироваться для ожидания инвайта больше не нужно.

Закрытое бета-тестирование Let's Encrypt началось 12 сентября 2015 года, и с тех пор было выпущено более 11 тысяч сертификатов, и этот опыт дал Let's Encrypt уверенность в том, что все системы вполне готовы для публичной беты.

Для Всемирной паутины наконец настало время сделать большой шаг вперёд по направлению к безопаности, конфиденциальности и шифрованию. Let's Encrypt был создан для того, чтобы сделать HTTPS стандартом по умолчанию, и для осуществления этой цели работа нового CA предусматривает максимальное упрощение процессов получения, обновления, отзыва и управления сертификатами.

У Let's Encrypt ещё есть много работы прежде чем пометка «бета» может быть сброшена окончательно, в частности — в области процесса работы пользователей: ставка сделана на автоматизацию, и посему будет потрачено много усилий на обеспечение безукоризненной работы клиента на широком спектре платформ, для чего Let's Encrypt будет пристально следить за отзывами пользователей, изучать их и совершать необходимые улучшения в работе как можно скорее.

Let’s Encrypt зависит от поддержки широкого разнообразия организаций и конкретных людей. Пожалуйста, рассмотрите возможность участия, и если ваша компания или организация желает помочь, то вы можете написать сюда.


Почему время жизни сертификатов составляет всего 90 дней?


Этот вопрос поднимался неоднократно: да, Let's Encrypt выдаёт сертификаты, время жизни которых составляет 90 дней; люди, задающие этот вопрос, обычно убеждены, что 90 дней — это слишком мало, и что было бы неплохо, если бы Let's Encrypt выдавались сертификаты, живущие год или даже больше, как это делают некоторые другие CA.

90-дневные сертификаты — вовсе не новость для Всемирной паутины. Согласно телеметрии Firefox, 29% всех TLS-транзакций используют 90-дневные сертификаты, и ни одно иное время жизни не составляет большую долю транзакций. Точка зрения Let's Encrypt состоит в том, что короткие времена жизни сертификатов имеют два главных, основных преимущества:

  1. ограничение ущерба от компрометированных ключей и неверно выпущенных сертификатов, так как таковые используются на меньшем промежутке времени;
  2. короткоживущие сертификаты поддерживают и поощряют автоматизацию, которая абсолютно необходима для простоты использования HTTPS. Если мы собираемся мигрировать всю Всемирную паутину на HTTPS, то вовсе нельзя ожидать ручного обновления сертификатов от администратора каждого существующего сайта. Как только выпуск и обновления сертификатов станет полностью автоматизированным, более короткие времена жизни сертификатов наоборот станут более удобными и практичными.

Именно по этим причинам Let's Encrypt не предлагает сертификаты с большими временами жизни, но поскольку также вполне ясно, что сервис Let's Encrypt ещё молод, и что автоматическое управление сертификатами в новинку подавляющей части подписчиков, именно 90-дневное время жизни было выбрано как всё ещё доставляющее достаточный для комфортного ручного обновления временной промежуток (Let's Encrypt рекомендует своим подписчикам обновлять свои сертификаты каждые 60 дней), если это по какой-либо причине необходимо. Тем не менее, однако, как только программное обеспечение автоматического обновления сертификатов будет массово внедрено и покажет свою надёжность и стабильность, Let's Encrypt планирует понизить максимальное время жизни ещё более.
@dbanet
карма
10,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (138)

  • +1
    Кто будет щупать, напишите, плиз: как там с поддержкой nginx? Допилили?
    • 0
      Пощупал с Debian и Apache… speechless.

      nginx не использую, поэтому пока не могу ничего сказать; видел соответствующую директорию letsencrypt-nginx.

      Кстати, есть канал #letsencrypt@freenode.
      • +1
        Прошу не счесть за невежество, может подскажете, я вот не очень понял, вот какого момента:

        Правильно-ли я понимаю, что letsencrypt, будет каждый раз продлевая сертификат для домена, генерировать новый приватный ключ?

        Если я прав, то подскажите, после того, как я в apache, скопирую новый приватный ключ, новый сертификат, мне потребуется выполнить apache2 restart? Или apache2 reload, будет достаточно? Если надо рестартовать apache, после прикорма новых сертификата, и ключа, то получается, что как минимум раз в 90 суток, мне надо будет перезапускать инстанс apache? На проекте без кластеризации, выглядит — не вкусно.

        Спасибо!
        • 0
          Собственно, на канале letsencrypt@freenode, мне ничего не смогли посоветовать. Только патчить исходные тексты apache…
        • 0
          Apache на фронте вообще сам по себе выглядит невкусно. Use Nginx, Luke!
          • 0
            nginx, мне не подходит по техническим причинам. Там всё не очень хорошо с kerberos и т.д.
            • +2
              Так поставьте nginx перед apache как reverse proxy. Nginx-у достаточно reload для подхвата новых сертификатов в отличие от apache.
        • +1
          А чем так плох даунтайм в пару секунд раз в 3 месяца? Один фиг за это время и сам апач или либы, от которых он зависит, успеет пару раз пропатчиться и всё равно придётся рестартить.
          • 0
            В свете вот этого:

            Let's Encrypt планирует понизить максимальное время жизни ещё более.


            Имеется, реальное опасение, что надо будет делать перезапуск, чаще, чем раз в три месяца. А apache, зараза, медленный… 2-4 секунды — вполне достаточно, чтобы в браузере получить кукиш. :(
            • 0
              У них где-то читал, что рекомендуется перевыпускать сертификаты каждый месяц
              • 0
                Можно и в настоящем посте прочитать. Последний параграф. 60 дней.
              • 0
                Насколько я понял, они будут в дальнейшем, только снижать сроки жизни сертификатов. Что, вообще говоря — опасно. Ведь, легко, может получиться так, что они лягут от DDOS, на недельку…
                • 0
                  В приватной бете у них лимиты были, сейчас про это нигде не написано
                  Rate limit on registrations per IP is now 10 per 3 hours up from 10 per day.
                  Rate limit on certificates per Name is now 10 per 59 days up from 6 per 59 days.
            • 0
              ставить лоадбалансер и 2 апача — тогда можно переключаться вполне безопасно и не отвлекая юзеров хоть раз в неделю
              • 0
                Получается, что в одном месте — упрощение, в другом — усложнение… Сертификаты — получаем легко. Но зато теперь надо load balancer делать. Хотя, вполне возможно, что это только проблемы, устаревшего apache.
                • 0
                  ну тут не то чтоб усложнение, просто если требуется надежность от сервиса то проще пусть даже софтверный балансер тогоже томката заюзать и при отсутсвии ресурсов (или не желания использовать два сервера) запустить два томката, просто тут вопрос в безопасности а балансер это к стабильности и доступности
    • 0
      А что особенного в поддержке nginx?
      • 0
        Когда последний раз смотрел, она была в статусе очень альфы.
        • +1
          Это относится только к автоматической настройке. Если вы готовы в ручную добавить несколько строк в конфиг nginx, то все отлично работает.
          • +1
            Да, я именно что хочу, чтобы всё делалось автоматически.
            • 0
              так можно руками в конфиги прописать, а обновление в крон поставить. В любом случае это есть в офф документации.
    • +2
      Я использую Let's Encrypt с Nginx с закрытой Beta ещё — в целом, работает (A+ оценка ssllabs.com), но иногда нужно подготовить конфиги чтобы плагин мог их нормально модифицировать. Например, у меня были другие HTTPS хосты настроены и Let's Encrypt не мог проверить причастность моего домена из-за того, что запросы уходили в другой HTTPS хост (listen domain:443 default;), нужно было всего лишь использовать listen без указания домена/IP-адреса (listen 443 default;). Для переезда с другого SSL сертификата мне проще было закомментировать настройки связанные с HTTPS чтобы Let's Encrypt смог его «обновить с HTTP до HTTPS». Если домен совсем не слушал 80 порт, то конфиг добавится в /etc/nginx/nginx.conf, что тоже заняло некоторое время на выяснение причин происходящих чудес.

      Ещё из неприятных особенностей — когда Let's Encrypt патчит конфиги — он их полностью переформатирует — убираются «лишние» пустые строки, отступы становятся строго 4 пробела (для меня это ок), комментарии на одной строке с настройкой разносятся на две строки (получается комментарий к чему-то становится после того, что нужно было прокомментировать).
      • 0
        А не могли бы вы поделиться своим конфигом nginx? Интересует только то, что касается SSL.
        • +7
          Let's Encrypt всё, в принципе, делает автоматически. Вот такое:

              listen 80;
          

          заменится на:
              if ($scheme != "https") {
                  return 301 https://$host$request_uri;
              }
              ssl_stapling_verify on;
              ssl_stapling on;
              ssl_trusted_certificate /etc/letsencrypt/live/escalibro.com/chain.pem;
              include /etc/letsencrypt/options-ssl-nginx.conf;
              ssl_certificate_key /etc/letsencrypt/live/escalibro.com/privkey.pem;
              ssl_certificate /etc/letsencrypt/live/escalibro.com/fullchain.pem;
              error_log /var/lib/letsencrypt/error.log;
              access_log /var/lib/letsencrypt/access.log;
              listen 443 ssl;
              listen 0.0.0.0;
          


          А вот в /etc/letsencrypt/options-ssl-nginx.conf совсем базовый конфиг, который даёт оценку B на ssllabs.com, так что его я изменил до:
          /etc/letsencrypt/options-ssl-nginx.conf
          # ciphers chosen for forward secrecy and compatibility
          # http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
          ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
          
          # disable SSLv3(enabled by default since nginx 0.8.19) since it's less secure then TLS http://en.wikipedia.org/wiki/Secure_Sockets_Layer#SSL_3.0
          ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
          
          ssl_session_cache shared:SSL:50m;
          ssl_session_timeout 1440m;
          
          # enables server-side protection from BEAST attacks
          # http://blog.ivanristic.com/2013/09/is-beast-still-a-threat.html
          ssl_prefer_server_ciphers on;
          
          # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
          ssl_dhparam /etc/nginx/ssl/dhparam.pem;
          
          # config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
          # to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
          # WARNING: Don't forget to add the following lines to /etc/nginx/conf.d/mapping.conf:
          #     map $upstream_http_strict_transport_security $strict_transport_security {
          #         '' max-age=31536000;
          #     }
          add_header Strict-Transport-Security $strict_transport_security;
          
          add_header X-Frame-Options DENY;
          add_header X-Content-Type-Options nosniff;
          ssl_session_tickets off;
          
          # Requires nginx >= 1.5.9
          # enable ocsp stapling (mechanism by which a site can convey certificate revocation information to visitors in a privacy-preserving, scalable manner)
          # http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
          resolver 8.8.8.8 valid=300s;
          resolver_timeout 300s;
          
          # These are included by letsencrypt to each individual host config
          #ssl_stapling on; # Requires nginx >= 1.3.7
          #ssl_stapling_verify on; # Requires nginx => 1.3.7
          

          Обращение к читателям: ПОЖАЛУЙСТА, НЕ КОПИРУЙТЕ НАСТРОЙКИ БЕЗДУМНО! Я стараюсь всё комментировать (для себя в первую очередь), поэтому не поленитесь и ознакомьтесь с каждой применяемой опцией.
          • 0
            а HPKP LE-клиент тоже обновляет сам?
            • +1
              Нет, так же как и не ставят автоматически HSTS, так как это может привести к тому, что сайт будет «заблокирован» для посетителей. Например, в случае с HSTS, ввиду их использования HTTP, а для случая с HPKP — если сервер вдруг выйдет из строя, а бекапов не будет.

              Обсуждение: community.letsencrypt.org/t/support-for-hpkp-http-public-key-pinning/504
      • 0
        никак не соображу, как установить плагин nginx? Везде пишут, что в комплекте, но при запуске letsencrypt-auto --nginx выдает The requested nginx plugin does not appear to be installed
        • +1
          Я не знаю как они ожидают это проворачивать, я тоже в документации не нашёл, поэтому через исходники нашёл где они хранят virtualenv и поставил туда пакет letsencrypt-nginx:
          $ ~/.local/share/letsencrypt/bin/pip install letsencrypt-nginx
          
  • +3
    Какое-то оно слишком шаловливое: и рута дай, и ssh дай, и конфиги веб-сервера мы тут ща тебе поправим, дорогой пользователь…
    • +12
      Это всё опционально. Сертификаты можно получать и без рута, конфиги правят конкретные плагины для конкретных веб-серверов. Если написать certonly --standalone, то, предсказуемо, ничьи конфиги правлены не будут.

      Кроме того, исходный код клиента доступен. Вы также можете написать свой: документация API.
    • 0
      Вот кстати да, т.е. насчет конфигов я не заморачиваюсь (все под управлением гита, т.е. увижу чего он там направит), да и опционально оно.
      А вот рут, хмм… Может кто-то пробовал, пашет ли оно в виртуалке (без домена), всмысле запуска не на боевых серверах, чтобы потом просто серты туда перекинуть?
      Опять же так было бы удобнее и обновляться по истечению 90 дней (если не один сервер / домен).
      • +1
        во время закрытого тестирования все свои сертификаты я выпускал на домашней машине и без рута. подтверждение естестно нужно с серверов. плагины не пользовал
  • +1
    Интересно, а Cisco планирует добавить клиент в ASA (вместо платного Entrust)?
  • +9
    Исторический момент в развитии интернета!
    И наши дети будут говорить: «Прикинь, а раньше сертификаты продавали! И электронная почта сначала была платная, а смс-ки стоили на порядок дороже, поэтому все перешли на мессенжеры и цены опустили...»
    • +1
      На счет СМС — у вас наверное какой-то особенный тарифный план. У меня одна СМС стоит как полчаса телефонного разговора (так было и во времена Jeans, и сейчас с Билайн). Но если это про будущее, то надеюсь, что все же перестанут торговать воздухом как продавцы сертификатов.

      И подскажите про платную электронную почту. Я активно почтой стал пользоваться с 1999/2000 годов и тогда уже было достаточно много бесплатных почтовых сервисов с красивыми доменами. Ранее c 1996/1997 большинство пользовалось бесплатной почтой hotmail.com. А еще ранее… просто не было такого количества доступных ПК, а те кто ими владел (корпорации и учебные заведения) обычно находились в сетях с Unix-сервером, на котором был запущен собственный почтовый демон.
      • +1
        У нас местные провайдеры продавали почтовые ящики на своём сервере, с определённым размером.
        Дело, кстати, потом стало очень выгодное: после того, как появился бесплатный доступ во внутреннюю сеть провайдера, на своём сервере можно было скачать файл и послать себе на почту.
      • +2
        > И подскажите про платную электронную почту.

        Namecheap / Rackspace / Google Apps / Office365 / etc.
        • +1
          Комплексные корпоративные пакеты — это и так понятно, но это не совсем про платную почту. В изначальном комментарии акцент был на том, что почта в прошлом была в принципе платной. Это меня и зацепило, так как не соответствовало действительности.

          А если говорить про Google Apps, то у меня там были две компании. Одной стало тесно в бесплатных ограничениях и мы перевели её на Яндекс, а вторая все еще на Гугле. При этом мы за корпоративные почтовые ящики не копейки не платим ни одним, ни другим.

          BaRoN уже пояснил, что имел в виду платную почту местных провайдеров, которые давали в свою локальную сеть нелимитированный бесплатный доступ, что было великой роскошью во времена помегабитной тарификации.
          • 0
            Ну это не совсем корпоративные, у тех же Namecheap / Office эта фишка есть и для частных лиц, и они ею пользуются. Например, чтобы иметь почту на своем домене и не заморачиваться с настройкой и поддержкой своего почтовика.
            • 0
              Чтобы было (мало ли кому): Яндекс предоставляет это бесплатно; Google, кстати, тоже, только с Apps надо слегка больше повозиться, но в итоге будет почта от гугла. Если также лень платить за DNS, то в той же почте для домена от Яндекса можно бесплатно домен на их DNS делегировать, при этом, собственно, почтой от Яндекса пользоваться не обязательно (но можно): вполне прописываются записи почты Google Apps.
              • +1
                Google вроде отменил бесплатный план, есть способ как получшить Apps для своего домена бесплатно?
                • 0
                  Не слышал такого. Ничего не плачу гуглу, Apps имеется. o_O
                  Недавно брал.

                  Впрочем, всё равно скоро сбегу наверное на всё своё.
                  • +1
                    Они убрали для новых пользователей. У кого уже был бесплатный apps — у тех он остался.
                    В текущий момент вариантов кроме gapps for work, for education, for government и for nonprofits не видно.

                    Недавно — это когда? Сейчас они обычно хотят $50/user/year.
                    • 0
                      Ну так вот если for nonprofits выбрать, то не бесплатно будет что ли?

                      Года три назад, судя по хуизу.
                      • 0
                        Бесплатно. Но для того, чтобы подходить под эту программу, нужно являться 501c3, т. е. non-profit организацией в юрисдикции США.
                        To be eligible for the Google for Nonprofits program, organizations must:
                        — Hold current 501(3) status, as determined by the U.S. Internal Revenue Service
                        www.google.com/intl/ru_ALL/nonprofits/join
            • 0
              Тогда остановимся на том, что есть некоторая услуга для ленивых сисадминов (и просто далеких от ИТ людей) по обслуживанию почты личного домена с веб-доступом из любой точки планеты, у которой есть некоторые преимущества перед аналогичными бесплатными предложениями обслуживания личных доменов от того же Яндекса. Тут все ясно — дополнительный платный сервис поверх в принципе бесплатной концепции электронной почты — как минимум экономия времени. Что контрастирует с платными сертификатами, на выпуск/перевыпуск которых уходит больше времени, чем на создание самоподписанного, но все с этим продолжали морочиться исключительно ради зеленой плашечки вместо стремного красного крестика в строке браузера.
  • +1
    Докерный dmp1ce/nginx-proxy-letsencrypt работает очень даже мило для тестовых деплоев — SSL просто магически изкоробки теперь.
  • 0
    Как раз собирался завтра на один сайт поставить SSL. Думал у Wosign достать сертификат, но раз такое дело, буду в let's encrypt разбираться
  • 0
    Я так и не понял, как обновить сертификат, не останавливая веб-сервер.

    К примеру, у меня есть некоторый веб-сервис на отдельном порту, а также есть nginx, который все запросы с 80 порта проксирует на этот сервис. Теперь, чтобы обновить сертификат, нужно провалидировать домен. Для этого letsencrypt должен создать какие-то файлы в публичной веб-директории и натравить nginx на них (это одна из проверок валидности домена). В это время мой сервис простаивает.

    Может есть более правильное решение?
    • 0
      Создать виртуальный каталог?
      Чтобы www.вашсайт.ru проксировалось на ваш сервис, а www.вашсайт.ru/validation_data не проксировалось на ваш сервис, а лежало в локальной папке на фронтенде
    • 0
      --webroot-path /path/to/exists/webroot — в таком случае letsencrypt будет валидировать через существующий web-сервер, а не поднимать свой.
      • 0
        тут вопрос про проксирующий nginx, проксировать он может куда угодно, хоть на другой сервер. Как проксирующий nginx подружить с letsencrypt?
        • +1
          А. Ой. Всё ещё просто: судя по логам моего сервера, проверка идёт по пути GET /.well-known/acme-challenge/some-long-hash. Судя по репозиторию в github, этот путь более или менее захардкожен и есть надежда, что не поменяется. Видимо, добавление в конфиг проксирующего nginx-а location /.well-known/acme-challenge/ { }, чтобы он всё, что начинается с этого пути не проксировал, а обрабатывал локально, будет достаточно. Ну ещё если не хочется позволять сторонней штуке копаться в «боевой» директории, можно path какой-нибудь отдельный указать, хоть тот же /tmp (и в этом location и в опциях вызова letsencrypt-а. Хотя именно /tmp вряд ли стоит. :)
          • +2
            получилось
            #/etc/nginx/letsencrypt.conf
            location /.well-known/acme-challenge {
                root /somedir;
            }
            

            #/etc/nginx/sites-enabled/domain.conf
            server {
                    server_name domain.com;
                    location / {
                            proxy_pass http://ip
                    }
                    include letsencrypt.conf;
            }
            

            ./letsencrypt-auto certonly --webroot -w /somedir -d domain.com
            
            • 0
              Примерно о такой штуке я и думал. Но что если этот путь поменяется? Хотелось бы видеть такой способ в официальной документации.
              • 0
                Поменяется и я поменяю, в одном месте же. Бета пока, можно в github issues написать свои желания по этому поводу
                • 0
                  Так ведь соль в том, чтобы один раз настроить автоматическую генерацию и забыть.
                  • +2
                    Бета намекает, что настроить и забыть, точно не сейчас. Даже ключи вызова могут измениться
  • 0
    Первый раз слышу про этот замечательный проект. Выглядит многообещающе, но как у них дела обстоят с защищённостью CA? И при такой схеме, как я понимаю, EV невозможно в принципе?
    • 0
      И при такой схеме, как я понимаю, EV невозможно в принципе?
      Нет. Это ж чисто DV-сертификаты. OV и EV они предоставлять и не собирались. OV и EV — это всегда human task.
  • 0
    Хмм… Бесплатно? А как у этой инициативы с защитой от CIA-in-the-middle атак? Рутовый сертификат — https://www.identrustssl.com/ Этой конторе можно доверять?
    • +6
      Вы всерьез считаете что «платно» спасает от CIA-itM? :)
      • +1
        Нет конечно! Но бесплатно-из-коробки сразу даёт намёк на «заработай 10000000 в неделю бесплатно и без регистраций». Нечисто тут что-то. Моя фольга меня защищает ))
        • +2
          Торговля сертификатами — это, по сути, торговля воздухом — затраты на выпуск сертификата практически равны нулю. 15 лет назад, самый дешевый сертификат стоил 400 долларов в год. Это похлеще торговли кокаином.
          • –2
            Да не совсем. При покупке есть хотя бы транзакция с карточки, которая хоть как-то, но косвенно может подтвердить, что ты — это действительно ты. В случае халявной раздачи это теряет смысл. Также вполне может быть, что поисковики будут топить https-сайты с халявными сертификатами.
            • +1
              StartSSL существует много лет, поисковики его не топят (да и им вообще какая разница).
            • 0
              А смысл им его топить? Гуглу выгодно когда пользователи смотрят его рекламу, а не вставленную на прокси.
          • +2
            По сути это юридические услуги с огромными начальными вложениями на инфраструктуру и договоры с вендорами.
          • +1
            Торговля сертификатами — услуги нотариуса, только в электронном виде.
            Зачем вы идете к нотариусу поставить подпись под бумажкой? Выстоять очередь на полдня, отдать 1000 рублей за 5 минут работы? Разве сами не можете подписаться на своем документе?

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

            Так же и сертификаты — есть EV с гарантиями со стороны УЦ, что если транзакцию компрометируют по их вине и будет ущерб, то они выплатят компенсацию. Есть минимальные сертификаты, которые подтверждают, только что «да, я видел, что какой-то чувак может что-то разместить на этом домене — значит его его домен».
  • +2
    Аукцион не слыханной щедрости, как бы не оказалось оно щедростью от АНБ и схожих с ней организаций…
    • +3
      Ребята усердно работали над этим проектом больше года, я следил и принимал участие в закрытом тестировании. У них несколько компаний в спонсорах, в том числе Facebook. Без HTTPS, или с использованием платных сертификатов (ЦА которых должны соблюдать «требования безопасности» выдвигаемые нормами, вероятно, АНБ) вас АНБ не беспокоило, видимо. Чтобы не беспокоиться за безопасность чего-либо — нужно обесточить и зарыть все данные под землю поближе к мантии.
    • +1
      Возможно.
      Если не смотрели лекцию "Offensive Security 2013 — FSU — Lecture 14: Web Application Hacking 103: SSL attacks, advanced techniques", то не пожалейте времени.

      This lecture's topics cover SSL/TLS, Certificate Authorities, and the serious problems with the Certificate Authority infrastructure, and a history of CA hacks / breaches, and SSL hacking tools like sslstrip ....
  • +1
    90-дневные DV-сертификаты и раньше были. Они были всегда. Это не новость. Единственное, что улучшилось — это проста установки.

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

    Приходит время EV (с зеленой адресной строкой и названием компании). Они и раньше были эффективнее DV&OV с точки зрения маркетинга, а теперь у каждого сайта будет стоять DV. У фишингового или у реального — все одинаковые) От фишинга спасет только EV.
    • +1
      «Благодаря» Cloudflare все фишинговые сайты уже год как с DV. С появлением Let's Encrypt ничего не поменялось в этом смысле.
    • 0
      Не поделитесь ссылками?
      Я перебиваюсь триальными от Comodo и SSL.com, но их не всегда хватает, а проводить по бухгалтерии GoGetSSL — тот ещё квест.
      • 0
        ссылками на что?
        ssl.com кстати перестал выдавать триалы, а у комода ограничение введено на один поддомен
        • 0
          На другие 90-дневные сертификаты.
          А SSL.com убрал ссылки с главной страницы, но прямая пока работает и сами сертификаты выпускает.
          • 0
            поделитесь прямой ссылкой на ssl.com? малоли, пригодится))я раньше ее через гугл находил, но месяц назад перестала искаться
            • 0
              В предыдущем сообщении.
    • 0
      DV-сертификаты (с проверкой по организации)
      Сломало мой мозг.
      DV — только проверка возможности управления доменом, в сертификате фигурируют только cn и san, никаких o/l/c/ou там нет.
      В OV — есть, т. к. выполняется human task по проверке существования организации, и наличие прав на действия от лица организации у того, кто заказывает сертификат.
      • 0
        Если пишете «human task по проверке» ради экономии букв, то знайте — «ручная проверка» намного короче и раскладку менять не требует.
        • +1
          Я пишу human task, т. к. это прерывание flow, с превращением автоматического бизнес-процесса в автоматизированный.
          • +2
            Ясно, вы просто забыли русский.
  • 0
    не забывайте основной плюс — для HTTP/2 нужен HTTPS а это позволяет всему интернету раздать сертификаты и потом включить http2
    • +1
      Бррр. Основной плюс простого и бесплатного HTTPS — это переход на HTTP/2? Вы, мне кажется, сейчас всё просто с ног на голову поставили.
      • 0
        тут скорее речь о том, что letsencrypt упростит переход на http/2. что, согласитесь, немаловажно ;)
  • +1
    Простейшая проверка домена для выдачи сертификата в настоящее время производится путем отсылки письма на имейл связанный с доменом. Зачем вообще нужна установка их ПО на сервер? Зачем нужно разрабатывать некое программное обеспечение, которое официально «бета», если есть более простое и очевидное решение?
    Как я понимаю просто получить сертификат используя свой приватный ключ, и потом поставить его на свой сервер не устанавливая туда их ПО нельзя. Что-то тут не так.
    • +4
      Как я понимаю просто получить сертификат используя свой приватный ключ, и потом поставить его на свой сервер не устанавливая туда их ПО нельзя. Что-то тут не так.
      протокол открыт, есть десяток либ для любых языков (lego для Go например), что вам запрещает написать свой клиент и не устанавливать вообще ничего?

      Читаю комментарии о LE что тут, что в официальном форуме и удивляюсь. Дают людям готовую реализацию протокола — а они нос воротят. Ну так не используйте, протокол же полностью открыт и задокументирован!
    • +1
      > Простейшая проверка домена для выдачи сертификата
      > в настоящее время производится путем отсылки
      > письма на имейл связанный с доменом

      Вы очень лаконично и хорошо описали ту проблему, из-за которой Let's Encrypt и создавали. Да, даже в самом простейшем случае, чтобы получить сертификат, нужно пройти семь кругов ада с регистрацией, подтверждением регистрации, заполнением данных о домене, подтверждением через почту и прочая, после чего ещё потребуется разобраться с настройкой HTTPS-сервера. Если вам эта процедура кажется простой и понятной — ну, мы рады за вас, можете и дальше ею пользоваться. Но для большинства людей сложность этих действий является основным препятствием к внедрению HTTPS. Для решения этой проблемы и был создан Let's Encrypt.
      • +1
        Что-то мне подсказывает, что установить LE-клиент не легче будет. ;) Не, ну, на дефолтовый конфиг из коробки возможно и легко, а вот под конкретные проекты, думается, не так тривиально это все.
        Во всяком случае, внятного хау-ту «с картинками тыкните сюда» я пока не видел
        • 0
          sudo apt-get install letsencrypt. Вот так это будет выглядеть в самой ближайшей перспективе.

          … ну, на Windows не получится, что поделать.

          Конечно, в случае очень сложного setup'а всё будет непросто, но для более-менее типовых случаев должно работать из коробки.
        • 0
          Получение вручную у них сделано нетривиалено:
          habrahabr.ru/post/270273
          • 0
            У меня не получилось по этому ману. Папки live не появляется, а в archive нет нужных файлов. Решил не заморачиваться: поднял виртуалку, настроил apache и провел все в ней. Позже скопировал сертификаты и все.
          • 0
            да, изза этого косяка с content-type процесс усложнился сильно.
            но на гитхабе уже есть тиккет, ждем фикса (возможно уже сделали, у меня клиент с закрытого теста еще).
            а без этого бага ручное получение очень простое
  • 0
    Ну теперь осталось браузерам подтягиваться. Например, первый год подсвечивать желтым цветом HTTP-сайты, потом красным. Чтобы юзеры сразу понимали, что с сайтом что-то не так. С бесплатным LE-сертом пусть будет обычный серый замочек, а там, где EV, то, естественно, зеленый.
    • 0
      ну вроде это уже есть — тот же гугл стимулирует использование https выдавая в результатах поиска сайты доступные по https выше чем обычные
      • 0
        А моё предложение простимулировало бы переход на HTTPS всякие форумные площадки, бесплатные хостинги и так далее.
  • –5
    Сертификаты раздают, оке. А где брать под эти сертификаты IP-адреса? Как всем перейти на https, если адресов на всех не хватает?
    • +1
      Чем отличается домен на http или https, с точки зрения количества ip адресов?
      • –6
        https'ному сайту нужен-отдельный адрес.
        • +1
          Кто вам такое сказал? Никто вам не мешает держать несколько доменов с разными сертификатами на одном ip
        • +4
          Давно уже не нужен, правда, некродевайсы на старых версиях ведроида, куда современные браузеры уже не встают, ругаются, ну да и хер с ними.
          • 0
            Пользователи IE в windows XP в пролёте, а их, сюрприз, может быть много в целевой аудитории. Но можно такой целевой сайт держать первым конфигом.
            • 0
              Если им настолько пофиг на безопасность, что юзают дырявого осла в дырявой винхр, то пусть руками и добавляют в исключения.
              • 0
                Это пока вы им платный сервис не предоставляете. Тетечки за 40 так и побежали исключения добавлять, ага.
                • 0
                  Если у тётечки в 40 лет настолько атрофировался мозг, что она не способна нажать 2 кнопки, то искать другой сервис она точно не побежит, а позовёт племянника/соседа/эникейщика и он нажмёт эти 2 кнопки за неё.
            • 0
              Не только IE, а любых приложений использующих CryptoAPI:
              community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394/10
              • 0
                Я же про SNI писал, его chrome в XP поддерживает, ЕМНИП.
                • 0
                  Там ещё проблема с Name Constraints.
                  • 0
                    В общем хром мог бы и справится, но вряд ли будет этим заниматься. Проверил, тематический сертификат в нём ожидаемо красный.
    • +1
      SNI уже очень давно работает же, да и основные хостинги IPv6 начали давать.
      • +1
        IPv6 пока не сильно увеличивает количество всеобщего счастья: пользователей, имеющих ipv6 пока не очень много.

        А SNI — конечно. Большинство уже поддерживает. Хотя, в случае java 1.6 боль есть.
  • 0
    Блин, все круто, но я так понимаю с продлением не совсем все автоматом пока еще? Или я не разобрался?..
    Попробовал сделать сертификат с максимальным указанием параметров, а все равно окошко вылезло «похоже вы обновить хотите?». Ну дружелюбно, да, но опции --yes-i-wanna-renew нету…
    • +2
      Есть --renew-by-default.
      ./letsencrypt-auto certonly --webroot -w /var/www/example -d example.com --renew-by-default
      Ничего не спрашивает, спокойно меняет сертификат по крону.
      • 0
        --renew-by-default

        Это то что нужно, спасибо. Видимо проглядел…
  • –5
    Я не совсем понял где мне прочитать про механизм защиты. В смысле как Let's Encrypt определяет, что я правда для своего сайта получаю сертификат, и не смогу получить сертификат для google.com например (развернув его на виртуалке и если я например Ростелеком могущий подменить траффик к московскому выносу гугла на M-9)
    • +5
      Вот почему раньше ни к одному CA, выдающему DV-сертификаты по точно такой же схеме, таких вопросов не было? :-) Даже к CNNIC.

      letsencrypt.org/certificates/#certificate-transparency
  • 0
    Читая их форума наткнулся на пару пару интересных топиков:

    О хорошем: в 2016 появится возможность создать ECC сертификат.
    О плохом: сертификаты Let's Encrypt предназначены только для публичных веб-сайтов, поэтому они не публикуют IP-адреса робота и хотят усложнить их определение.
  • 0
    Попробовал установить сертификаты от Let's Encrypt, и мне начали приходить жалобы от пользователей. Оказалось, что некоторые антивирусы блокируют эти сертификаты. В браузере это выглядит как недостоверный сертификат.

    Кто-то сталкивался с подобной проблемой? Как обойти?
    • 0
      Случайно не Dr.Web? :D
      Сайты с Wosign сертификатами тоже блочит.

      Лечится внесением сайта в белый список. Пока что только такой способ нашел.
      • 0
        Может быть teecat что-то про это знает?
      • 0
        Я спросил в техподдержке. Говорят — запросов не было.
        • 0
          Странно. У меня есть сайтик с wosign-сертом. Юзер пожаловался, что сайт не открывается.
          Firefox пишет ошибку:
          Аутентификация на основе сертификата завершилась со сбоем
          ERR_BAD_SSL_CLIENT_AUTH_CERT

          IE:
          Не удается отобразить эту страницу

          Внес сайт в белый список Dr.Web. Стал открываться.

          Причем на двух машинах у него такое.
          • 0
            Я не сказал, что проблема отсутствует. Я сказал, что запросов не было — вы писали в техподдержку? Если да и если не сложно, то номер тикета — чтобы побыстрей все прошло
            • 0
              Нет, не писал. :D
              Я же не могу поручиться за юзера на др. конце страны, что он ничего не делал у себя на компе с антивирусом. Мб он сам нечаянно внес сайт в черный список или кто-то другой в общую базу. Хотя сайт-то безобидный, ламповый.

              Да и сам никогда не пользовался Dr.Web-ом. ^^
              • 0
                Давайте сайт. Закину в саппорт, может чего скажут. Но вообще им конечно желательно юзера для выяснения проблем
                • 0
                  Проверю сам — поставлю на виртуалку. Если баг воспроизведу, напишу в саппорт и дам тикет в личку.
                  Спасибо вам за участие. ;)
                  • 0
                    Не за что. Удачи!
      • 0
        Нет, KIS
    • +1
      Откатился в итоге от Let's Encrypt, использовал бесплатный ssl.com на 90 дней. У всех пользователей, кто получал ошибку сертификата, всё сразу заработало (невзирая на антивирусы).

      Похоже, Let's Encrypt еще не готов.
  • 0
    Не слышал, но завтра спрошу
  • 0
    Поддерживать несколько серверов вручную разворачивая на каждом виртуальное окружение оказалось не совсем удобно. Пришлось собрать .deb-пакеты (Debian wheezy / jessie, Ubuntu precise / trusty). Может кому-то еще пригодится — в пакете сам letsencrypt и плагины для nginx / apache.
  • 0
    Если кто-то, как и я, не понял, как это все просто сделать для nginx, то вот вам статья – в ней все понятно, доступно и, главное, быстро.
    • 0
      The current certificate is valid only for three months. I am sure Let's Encrypt will provide more direction on auto-updating the certificates for NGINX by then! :-)
      А я уж было понадеялся :)
      • 0
        А чем особо отличается обновление сертификата для Nginx от обновления сертификата для чего-либо другого?
        У меня вот вообще lighttpd и ничего, никаких проблем с получением\обновлением сертификатов Let's Encrypt.
        • 0
          Именно эта часть для меня ― тёмный лес. Как и что нужно настроить, чтобы всё обновлялось автоматически? Не руками или там собственными скриптами по крону, а средствами ПО Let's Encrypt?
          Или я всё неправильно понял и let's сам всё верифицирует, обновит, а затем и nginx перегрузит? Или не перегрузит?
          • 0
            По кронувыполнять из скриптик раз в N дней (например раз в 2 месяца). Насчет того, умеет ли он перегружать вебсервер я не знаю, я lighttpd сам перезагружаю (так как их скриптик о его существовании ничего не знает).

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