В реальном использовании - ничем, кроме способа продления.
О его особенностях читайте с 3й страницы этого топика.
Имеет значение, только если планируете настраивать самостоятельно на своём сервере.
А концептуальные отличия только у EV и Wildcard разновидностей сертификатов, которые мало кому необходимы.
Вполне вероятно, что, то, чем тестируете, либо кеширует и не учитывает этот фактор при повторных тестах, либо находится прямо в ~1мс от одной из точек доступа CDN'а, который использует LE.
Это фактор, который точно полезен, но с основными времязатратами не связан.
Так у вас хостинг в Москве, и тесты вы сделали тоже из Москвы. Тут HTTPS и должен быть незаметным.
В дополнение к этому, ваш сайт сам по себе и лёгкий по контенту, и технически близок к возможному идеалу да работает быстрее абсолютного большинства существующих.
Поэтому ему, в целом, сложно помешать. Но всё же ваш проект предназначен для всего русскоязычного населения планеты )
Основной вопрос всегда просто в физическом расстоянии.
Протестировав ситуацию по РФ, увидите цифры и намного больше из многих регионов (например, попробуйте ping-admin.ru - он удобно показывает отдельно SSL-этап; host-tracker.com тоже хорошо подойдёт, но только для суммарного сравнения HTTP vs HTTPS)
Как ни оптимизируй, в любом случае из-за HTTPS появляются дополнительные пакеты, которые должны не раз пролететь весь путь от сервера до посетителя.
Это неустранимая и основная задержка.
Поэтому, если вся аудитория сайта сосредоточена в 1 городе, то можно разместить хостинг там. И, помимо улучшения общих скоростей, HTTPS тоже станет почти не заметен.
А во всех других случаях, т.е. при широкой географии аудитории, чисто технически нет решений, кроме CDN или создания собственной мультисерверной системы.
Возможные вторичные оптимизации вам уже очень хорошо рассказал Оптимизайка.
1. Действительно существенен OCSP stapling. Его несложно активировать в любом веб-сервере.
Он экономит лишнее обращение к центру сертификации на первом запросе.
Во многих крупных городах реальная выгода невелика и находится на уровне 20мс (поскольку у самого LE, как и у большинства других центров, это работает через Akamai).
По РФ\СНГ полноценно охвачены Москва, Санкт-Петербур и Киев, поэтому в других регионах выгода может быть намного значимее.
Также это даже потенциально повышает аптайм, поскольку убирает дополнительную "точку отказа" в лице OCSP серверов центра сертификации.
Но, в то же время, и добавляет другую "точку отказа" на уровне вашего сервера, если реализуете самостоятельно.
Поскольку, вы сами должны будете постоянно обновлять OCSP данные (они валидны на ~неделю).
И, как и с самим LE, нужно мониторить и обрабатывать сопутствующие проблемы. Иначе есть шансы начать отправлять истёкшие или некорректные данные, и в браузерах будут ошибки.
2. Производительность, связанная с ключами, имеет место, но на практике редко заметна.
Она касается CPU-затрат, поэтому значима, например, для маломощных телефонов.
3. При глубокой настройке SSL на уровне своего сервера поможет такой чекер
Безопасность тоже не на А-уровне без дополнительных настроек.
Если детализировать, 99.99+% пользователей это не заметили. Потому что проблема в некоторых версиях резолверов, которые сами работали некорректно и вместо ответа ошибкой просто не подавали признаков жизни.
А так, конечно, LE мог бы получше проработать эту ситуацию и можете смело считать такое его недостатком.
Там вообще много недостатков.
Которые всё также не являются препятствием для 100% надёжности конечного результата.
А просто контролируя такой жизненно важный показатель, как сертификат, вероятность снижается не в 12 раз, а насколько это в принципе возможно.
Разумеется, самостоятельная реализация это - затраты.
Потому только что с вами полностью соглашались в том, что 15$-вариант может быть рациональным в некоторых случаях.
Но самое основное в виде контроля с уведомлениями - вполне тривиально, чтобы быть доступным любому коммерческому проекту или владельцу нескольких доменов.
В то же время, низковероятно, но всё же разрешение каких-то частных случаев изредка может продолжать увеличивать издержки.
Бесплатно. Правда, не на вашем сервере, что редко является объективной необходимостью.
Во множестве сервисов, включая и наш, и другие CDN, и множество хостингов - надёжно работающий Let's Encrypt является бонусом к основным возможностям.
В какой-то степени аналогичную позицию можно признать справедливой по отношению ко всему, что не устраивает в этом мире =)
Но в данном случае вот просто есть искреннее мнение "LE - ненадёжный" и уже подробно обсуждённые, но всё таки конкретные проблемы и аргументы.
Почему бы их не высказать в свободном интернете )
И очень многие могут ошибочно опасаться того же или не знать возможных вариантов решения.
Поэтому, если уж диалог возник, в любом случае хорошо, когда названы и получили комментарии все-возможные-претензии-которые-только-можно-придумать.---------- Добавлено 08.07.2017 в 15:51 ----------
Как, очень надеюсь, всё таки успешно стало очевидным, - недостатки только в расширениях, и их несложно компенсировать небольшой админской работой.
Если
1) и нет возможности полноценно настроить получение сертификатов
2) и нет желания использовать сервисы, где это уже так работает
То, действительно, просто взять платный - пока рационально, и такое решение имеет полное право на существование.
Хотя немного сложно представить проект, где сочетаются одновременно оба таких условия.
Действительно критичного с такими сроками просто нет.
Но, чтобы не обсуждать это, давайте сразу представим, что вообще в этом Google-Facebook-Firefox-OVH-и-ещё-много-чьем проекте есть только 1 администратор, который ещё и периодически забывает заплатить за сервера.
И LE каждый месяц полностью лежит по неделе-другой к ряду.
- Как это повлияет на возможность продления ваших сертификатов и аптайм ваших сайтов?
-- Всё также. Никак.
---
LE - это редкая ситуация, когда люди сделали хорошее для людей действительно бесплатно.
Этот проект делает интернет безопаснее и останавливает десятилетнее выкачивание денег из всех вебмастеров "платежами за воздух" в виде платных сертификатов.
И, честно, совсем непонятно желание их дискредитировать, особенно когда для этого нет реально существующих поводов.
Ваш Plesk-модуль мог бы быть лучше. Мог бы сам продлевать заранее, сам использовать одновременно разные методы валидации для обхода ряда ошибок, сам активно информировать вас о проблемах и спасти от падения сайта.
Нет желания\возможности реализовать такое самостоятельно или воспользоваться другими альтернативами, можете сделать конструктивное предложение его разработчикам.
Или можете обругать их, если считаете это уместным в адрес разработчиков бесплатного софта.
А информация о том, что по какой-то причине с LE принципиально нельзя обеспечить 100% исключение даунтайма сайтов - просто не соответствует объективной реальности.
Текущие лимиты допускают до 5 дублирующих выпусков за ОДНУ неделю
Пункт №1 из предыдущего ответа
Как могут влиять проблемы, исчисляемые в минутах и часах, на продление, для которого в запасе есть недели?
Никак.
Выпускается порядка 450.000 сертификатов в сутки. Любая настоящая проблема вызвала бы невообразимый шквал обсуждений и их просмотров.
А не те несколько штук с десятками\сотнями просмотров, которые появляются, в основном, от нежелания изучать инструкции по стандартным случаям.
Есть ряд вариантов сломать продление изменением настроек веб-сервера, ДНС и самих расширений.
В том числе, и иногда банальными редиректами, которые большинство устанавливает после получения сертификата в первый раз.
Поэтому, - всё же не так. И виновато расширение или его применение.
Здесь есть 2 отдельных вопроса.
1. Можно ли просто поставить любое LE-расширение и получить 100% надёжность?
- Нельзя.
В этом вы полностью правы. Ваш пример и все упомянутые обсуждения это подтверждают.
2. Можно ли в принципе настроить так, чтобы получить 100% надёжность?
- Можно.
Это подтверждает не только пример множества крупных хостингов и CDN.
Но и очевидная логика.
Ничто не мешает:
- продлевать сертификаты хоть каждую неделю;
- посылать себе уведомления об ошибках.
Проблему встретить сложно. Сложную проблему встретить почти нереально.
Но какой бы она ни была вообще, - всегда есть до 2.5 месяцев в запасе, чтобы разобраться.
Простые уведомления об ошибках с минимальным вниманием к ним, - действительно дают 100% гарантию того, что ни один сайт никогда не получит ущерба.
Предложили вам посмотреть в сторону Certbot, потому что с ним точно можно это сделать. Пусть и не совсем быстро и тривиально, но вполне посильно для среднего админа.
Если же нет желания\возможности так сделать или реагировать на уведомления:
1) Либо смириться с тем, что у "частников" сейчас нет вариантов, чтобы и совсем не вникать, и получить гарантированные 100% надёжности от бесплатного сервиса с бесплатными модулями.
* Почаще обновляйте "расширение". Оно всё же и так очень хорошее, и будет становится лучше.
2) Либо перестать заниматься сертификатами самостоятельно и воспользоваться тем, что полноценная обработка и контроль проблем уже есть у многих.
C тем, что HTTP/2 не решает вопрос с первым хендшейком и является просто самостоятельным способом небольшого ускорения, упоминания aleksandrbol про другие аспекты скорости мне кажутся в равной степени уместными.
А на практике скорость лишней не бывает, поэтому лучше иметь и HTTP/2 (когда станет актуальнее), и кеши, и отсутствие потерь от хендшейков - одновременно.
Суть в том, что LE действительно абсолютно надёжен. Проблемы редки, связаны в основном с пользовательской спецификой. И от абсолютно любых легко защитится с клиентской стороны.
Иное было бы странно для сервиса, от которого зависят уже миллионы сайтов.
Всё описанное касается исключительно того, как можно это сделать, если стандартное расширение всё ещё не даёт вам достаточных технических возможностей для появления полного доверия.
В частности, даже если бы данный случай был бы совсем неисправимой ошибкой самого LE то, как минимум, об этом можно было бы узнать задолго до истечения сертификата и успеть что угодно.
Но он известен года полтора в различных вариациях и связан с некорректной работой старых версий ДНС или некорректными записями в зоне. Поэтому легко решаем и затронул немногих. Преимущественно, тех, кто держит собственные ДНС.
В любом случае это проблема расширения, а не LE. Да, похоже, уже исправленная. Если и продолжите управлять сертификатами с собственного сервера, и будут повторяться проблемы - подключите Certbot, это старейшее решение для LE. Инструкция для CentOS
