Компания
28,78
рейтинг
30 августа 2012 в 13:01

Разное → Цифровые SSL сертификаты. Разновидности, как выбрать?

Существует достаточно много цифровых сертификатов, каждый из которых служит для своих целей. Самые распространенный тип сертификатов это естественно SSL сертификаты, которые также имеют несколько подвидов. Также существуют Code Signing сертификаты, Website Anti Malware Scanner сертификаты и Unified Communications сертификаты.

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

Так что если у вас стоит задача поднять защищенное https соединение для вашего сайта, то в этом посте я постараюсь раскрыть все тонкости и особенности SSL сертификатов, чтобы сделать правильный выбор было проще.

Начнем с самых распространенных SSL сертификатов.

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

Для того, чтобы активировать возможность работы протокола HTTPS как раз и нужны цифровые SSL сертификаты (также потребуется выделенный IP для конкретного сайта).

Что такое SSL сертификат?


SSL — это сокращение от Secure Socket Layer — это стандартная интернет технология безопасности, которая используется, чтобы обеспечить зашифрованное соединение между веб-сервером (сайтом) и браузером. SSL сертификат позволяет нам использовать https протокол. Это безопасное соединение, которое гарантирует, что информация которая передается от вашего браузера на сервер остается приватной; то есть защищенной от хакеров или любого, кто хочет украсть информацию. Один из самых распространенных примеров использования SSL — это защита клиента во время онлайн транзакции (покупки товара, оплаты).

Как получить SSL сертификат?


Самый простой и бесплатный способ — это использовать, так называемый, самоподписной сертификат (self-signed), который можно сгенерировать прямо на веб-сервере. К слову во всех самых популярных панелях управления хостингом (Cpanel, ISPmanager, Directadmin) эта возможность доступна по умолчанию, поэтому техническую сторону процесса создания сертификата мы сейчас опустим.

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


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

Почему же браузеры выдают такое предупреждение для самоподписных сертификатов и как этого избежать? Чтобы ответить на этот вопрос потребуется немного рассказать про сами принципы работы SSL сертификатов.

По какому принципу работает SSL сертификат?


Итак для того, чтобы получить SSL сертификат самое первое, что нужно сделать, это сформировать специальный запрос на выпуск сертификата, так называемый (Certificate Signing Request). При формировании этого запроса вам будет задан ряд вопросов, для уточнения деталей о вашем домене и вашей компании. После завершения ваш веб сервер создаст 2 типа криптографических ключей — приватный ключ и публичный ключ.

Публичный ключ не является секретным и он помещается в запрос CSR.
Вот пример такого запроса:
-----BEGIN CERTIFICATE REQUEST-----
MIIC3zCCAccCAQAwgZkxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIEwRLaWV2MQ0wCwYD
VQQHEwRLaWV2MRQwEgYDVQQKEwtIb3N0QXV0b21hdDEQMA4GA1UECxMHaG9zdGlu
ZzEmMCQGCSqGSIb3DQEJARYXc3VwcG9ydEBob3N0YXV0b21hdC5jb20xHDAaBgNV
BAMTE3d3dy5ob3N0YXV0b21hdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDTg7iUv/iX+SyZl74GcUVFHjFC5IqlTNEzWgLWrsSmxGxlGzXkUKid
NyXWa0O3ayJHOiv1BSX1l672tTqeHxhGuM6F7l5FTRWUyFHUxSU2Kmci6vR6fw5c
cgWOMMNdMg7V5bMOD8tfI74oBkVE7hV95Ds3c594u7kMLvHR+xui2S3z2JJQEwCh
mflIojGnSCO/iv64RL9vjZ5B4jAWJwrruIXO5ILTdis41Z1nNIx3bBqkif0H/G4e
O5WF6fFb7etm8M+d8ebkqEztRAVdhXvTGBZ4Mt2DOV/bV4e/ffmQJxffTYEqWg8w
b465GdAJcLhhiSaHgqRzrprKns7QSGjdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOC
AQEAuCfJKehyjt7N1IDv44dd+V61MIqlDhna0LCXH1uT7R9H8mdlnuk8yevEcCRI
krnWAlA9GT3VkOY3Il4WTGg3wmtq6WAgLkVXQnhIpGDdYAflpAVeMKil8Z46BGIh
KQGngL2PjWdhMVLlRTB/01nVSKSEk2jhO8+7yLOY1MoGIvwAEF4CL1lAjov8U4XG
NfQldSWT1o8z9sDeGsGSf5DAXpcccx0gCyk90HFJxhbm/vTxjJgchUFro/0goVpB
credpKxtkwBMuCzeSyDnkQft0eLtZ9b9Q4+ZNDWsPPKxo/zWHm6Pa/4F4o2QKvPC
Px9x4fm+/xHqkhkR79LxJ+EHzQ==
-----END CERTIFICATE REQUEST-----

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

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

CSR Information:
Common Name: tuthost.ua — доменное имя, которое мы защищаем таким сертификатом
Organization: TutHost — название организации, которой принадлежит домен
Organization Unit: Hosting department — подразделение организации
Locality: Kiev — город, где находится офис организации
State: Kiev — область или штат
Country: UA — двухбуквенный код, страны офиса.
Email: support@tuthost.com — контактный email технического администратора или службы поддержки

Важный момент — обратите внимание на поле Country — формат этого поля подразумевает только двухбуквенный код по стандарту ISO 3166-1, если вы не уверены в коде вашей страны, то проверить его можно например тут: Таблица ISO-3166-1. Я обращаю внимание на это поле, потому, что самая частая ошибка у наших клиентов при генерации запроса CSR — это неправильный код страны. И как следствие с такой CSR произвести выпуск сертификата невозможно.

После того как CSR сгенерирован вы можете приступать к оформлению заявки на выпуск сертификата. Во время этого процесса центр сертификации (CA — Certification Authority) произведет проверку введенных вами данных, и после успешной проверки выпустит SSL сертификат с вашими данными и даст возможность вам использовать HTTPS. Ваш сервер автоматически сопоставит выпущенный сертификат, со сгенерированным приватным ключем. Это означает, что вы готовы предоставлять зашифрованное и безопасное соединение между вашим сайтом и браузером клиентов.

Какие данные содержит в себе SSL сертификат?

В сертификате хранится следующая информация:
  • полное (уникальное) имя владельца сертификата
  • открытый ключ владельца
  • дата выдачи ssl сертификата
  • дата окончания сертификата
  • полное (уникальное) имя центра сертификации
  • цифровая подпись издателя


Что такое центры сертификации (CA)?

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

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

Говоря в общем, SSL сертификаты содержат и отображают (как минимум одно из) ваше доменное имя, ваше название организации, ваш адрес, город и страницу. Также сертификат всегда имеет дату окончания и данные о центре сертификации, ответственного за выпуск сертификата. Браузер подключается к защищенному сайту, получает от него SSL сертификат и делает ряд проверок: он не просрочен ли сертификат, потом он проверяет, выпущен ли сертификат известным ему центром сертификации (CA) используется ли сертификат на сайте, для которого он был выпущен.

Если один из этих параметров не проходит проверку, браузер отображает предупреждение посетителю, чтобы уведомить, что этот сайт не использует безопастное соединение SSL. Он предлагает покинуть сайт или продолжить просмотр, но с большой осторожностью. Это последнее, что вы должны увидеть ваши потенциальные клиенты.

Центров сертификации существует достаточно много, вот перечень самых популярных:
Comodo — работает с 1998 штабквартира в Jersey City, New Jersey, США.
Geotrust — основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, США
Symantec — бывший Verisign в состав которого входит и Geotrust. Купил всех в 2010 году.
Thawte — основан в 1995, продан Verisign в 1999.
Trustwave — работает с 1995, штабквартира Chicago, Illinois, США.

Как видим самый крупный игрок на рынке SSL сертификатов это Symantec, который владеет тремя крупнейшими центрами сертификации — Thawte, Verisgin и Geotrust.

Есть ли разница в каком центре сертификации заказывать сертификат?

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

Чтобы проверить, корневые сертификаты каких центров сертификации установлены в вашем браузере, достаточно в настройках вашего браузера найти такую опцию. (В Chrome Настройки -> показать дополнительные настройки -> управление сертификатами -> Доверенные корневые центры сертификации). В Chrome установлено более 50 таких корневых сертификатов.

Важный момент — частенько у клиентов возникала ситуация, когда SSL сертификат на серверe установлен, но при заходе на сайт браузер все равно выдает ошибку. Такая ситуация может возникнуть или из-за отсутствия в файле ca-bundle.crt корневого сертификата центра выдавшего сертификат или из-за того, что корневой сертификат устарел. Корневые сертификаты также имеют свой срок действия (в браузерах они обновляются при обновлении браузера).

С июля 2010 года сертификационные центры перешли на использование ключей 2048bit RSA Keys, поэтому для корректной работы всех новых сертификатов необходимо устанавливать новые корневые сертификаты.
Если новые корневые сертификаты не установлены — это может вызвать проблемы с корректной установкой сертификата и распознаванием его некоторыми из браузеров.
Ссылки на странички центров сертификации, где можно скачать новые корневые сертификаты даны ниже.

RapidSSL Certificate

GeoTrust SSL Certificates

Thawte SSL Certificates

VeriSign SSL Certificates

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

Итак мы вплотную подошли к видам SSL сертификатов.

Какие виды SSL сертификатов существуют?



Между собой сертификаты отличаются свойствами и уровнем валидации.

Типы сертификатов по типу валидации


  • Сертификаты, которые подтверждают только доменное имя (Domain Validation — DV).
  • Сертификаты, которые подтверждают домен и организацию (Organization Validation — OV).
  • Сертификаты, с расширенной проверкой (Extendet Validation — EV).

Разберемся с ними по порядку:

Сертификаты, подтверждающие только домен

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

Важный момент, что это письмо может быть отправлено только на так называемый approver email, который вы указываете при заказе сертификата. И к адресу approver email есть определенные требования, он должен быть либо в том же домене для которого вы заказываете сертификат, либо он должен быть указан в whois домена.
Если вы указываете email в том же домене, что и сертификат, то указывать любой emal тоже нельзя, он должен соответствовать одному из шаблонов:
admin@
administrator@
hostmaster@
postmaster@
webmaster@

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

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

Сертификаты с валидацией организации.

В таком сертификате уже будет указано название организации. Такой сертификат частное лицо получить не может. Срок выдачи таких сертификатов как правило от 3 до 10 рабочих дней, зависит от центра сертификации.

Процесс выдачи сертификатов OV

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

Что проверяется в таких случаях?

У разных центров сертификации проверка несколько отличается, поэтому приведу общий список пунктов, которые могут быть проверены или запрошены:

  1. Наличие организации в международных желтых страницах — проверяется не всеми центрами сертифации
  2. Наличие в whois домена названия вашей организации — а вот это уже проверят обязательно, и если такое название там не указано от вас скорей всего затребуют гарантийное письмо, в котором нужно указать, что домен действительно принадлежит организации, иногда могут затребовать подтверждение от регистратора
  3. Свидетельство о государственной регистрации — требуют все реже, чаще сейчас производится проверка через специальные компании, которые производят проверку существования организации по своим каналам. Например для Украины вас могут проверить по базе ЕДРПОУ
  4. Счет от телефонной компании, в которой содержится название вашей организации и ваш номер телефона, указанный в заказе — таким образом проверяется валидность вашего телефона. Требуют все реже.
  5. Проверочный звонок — все чаще правильность телефона проверяют осуществляя звонок, на номер телефона, указанный вами в заказе. При звонке спросят сотрудника, указанного в административном контакте. Не у всех центров сертификации есть русскоговорящие сотрудники, поэтому предупредите человека, который отвечает на телефон, что возможен звонок от англоязычной компании.

Сертификаты с расширенной проверкой.

Это самые дорогие сертификаты и получить их сложнее всего. В таких сертификатах есть так называемый «green bar» — то есть при входе не сайт, где установлен такой сертификат в адресной строке браузера посетителя появится зеленая строка, в которой будет указано название организации, получившей сертификат.

Вот как это выглядит на сайте у Thawte.


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

SSL cертификаты с расширенной проверкой (EV) выпускаются только когда центр сертификации (CA) выполняет две проверки, чтобы убедиться, что организация имеет право использовать определенный домен плюс центр сертификации выполняет тщательную проверку самой организации. Процесс выпуска сертификатов EV стандартизирован и должен строго соотвествовать правилам EV, которые были созданы на специализированном форуме CA/Browser Forum в 2007 году. Там указаны необходимые шаги, которые центр сертификации должен выполнить перед выпуском EV сертификата:
  1. Должен проверить правовую, физическую и операционную деятельности субъекта.
  2. Должен убедиться, что организация соответствует официальным документам.
  3. Необходимо убедиться, что организация имеет исключительное право на использование домена, указанного в сертификате EV.
  4. Необходимо убедиться, что организация полностью авторизована для выпуска EV сертификата.


Список того, что конкретно будут проверять такой же как и для сертификатов с проверкой организации.

EV сертификаты используются для всех типов бизнеса, в том числе для государственных и некоммерческих организаций. Для выпуска необходимо 10-14 дней.

Вторая часть правил актуальная для центра сертификации и описывает критерии, которым центр сертификации должен соответствовать перед тем, как получить разрешение на выпуск EV сертификата. Она называется, EV правила аудита, и каждый год происходит проверка на соответствие этим правилам.

Типы SSL сертификатов по своим свойствам.


Обычные SSL сертификаты

Тут все понятно, это сертификаты, которые выпускаются автоматически и подтверждают только домен. Подходят для всех сайтов.
Цена: от 20$ в год

SGC сертификаты

Сертификаты с поддержкой повышения уровня шифрования. Актуально для очень старых браузеров, которые поддерживали только 40 или 56 бит шифрование. При использовании этого сертификата уровень шифрования принудительно повышается до 128 бит.
За все время у нас не купили не одного такого сертификата. Мое мнение, что они уже не нужны, разве что для внутреннего использования в больших корпорациях, где сохранилось очень старое железо.
Цена: от 300 $ в год.

Wildcard сертификаты

Нужны в том случае, когда вам кроме основного домена нужно обеспечить шифрование также на всех поддоменах одного домена. Например: есть домен domain.com и вам нужно установить такой же сертификат на support.domain.com, forum.domain.com и billing.domain.com

Совет: посчитайте количество поддоменов, на которые нужен сертификат, иногда бывает выгодней купить отдельно несколько обычных сертификатов.
Цена: от 180$ в год. Как видите, если у вас меньше 9 поддоменов, то дешевле купить обычный сертификат, хотя в использовании будет удобней один wildcard.

SAN сертификаты

Пригодится, если вы хотите использовать один сертификат для нескольких разных доменов, размещенных на одном сервере. Обычно в такой сертификат входит 5 доменов и их количество можно увеличивать с шагом в 5.
Цена: от 395 $ в год

EV сертификаты

Это те самые сертификаты с расширенной проверки и зеленой строкой в браузере, о которых мы говорили выше. Получить их может только юридическое лицо, коммерческая, некоммерческая или государственная организация.
Цена: от 250 $ в год.

Сертификаты c поддержкой IDN

Как правило, не у всех центров сертификации указана эта опция в описании сертификата, но не все сертификаты поддерживаются работу с IDN доменами. Поэтому я просто приведу здесь список сертификатов, у которых есть такая поддержка:
  • Thawte SSL123 Certificate
  • Thawte SSL Web Server
  • Symantec Secure Site
  • Thawte SGC SuperCerts
  • Thawte SSL Web Server Wildcard
  • Thawte SSL Web Server with EV
  • Symantec Secure Site Pro
  • Symantec Secure Site with EV
  • Symantec Secure Site Pro with EV

Как выбрать самый дешевый сертификат?

У Geotrust самые дешевые SAN сертификаты. Сертификаты с валидацией только сайта, а также wildcard выгоднее всего у RapidSSL. EV сертификаты самые дешевые также у Geotrust. SGC сертификаты есть только у Thawte и Verisign, но у Thawte дешевле.

Чем еще отличаются сертификаты между собой

  • Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего с EV валидацией, от 7 рабочих дней.
  • Количество перевыпусков сертификата — у большинства центров сертификации неограниченно. Требуется, если допустили ошибку в данных об организации.
  • Гарантия — для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрауда и потеряет деньги, то центр сертификации обязуется их ему компенсировать до суммы указанной в гарантии. То есть центр сертификации как бы дает гарантию на свои сертификаты и что их невозможно установить на «левый» домен. На практике такие случае мне не известны поэтому на этот параметр можно не обращать внимание.
  • Бесплатный тестовый период — из платных сертификатов есть у symantec secure site, geotrust rapidssl, comodo positive ssl, thawte ssl web server. Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free
  • Возврат средств — есть почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода moneyback


Полезные утилиты:


  1. OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
    http://www.openssl.org/
  2. CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
    CSR Decoder 1 или CSR Decoder 2
  3. DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
    http://www.digicert.com/help/?rid=011592
    http://www.sslshopper.com/ssl-checker.html


В следующих частях постараюсь рассказать про остальные виды сертификатов.

P.S. с удовольствием отвечу на любые вопросы связанные с выбором SSL сертификата в комментариях.
P.P.S. Желающие получить 30% скидку на ssl сертификаты — пишите в личку.

Update: Важный момент — некоторые сертификаты умеют работать на доменах с www и без www, то есть для защиты www.domain.com и domain.com достаточно одного сертификата, но заказывать его нужно на www.domain.com
Актуально для сертификатов:
• RapidSSL
• QuickSSL Premium
• True BusinessID
• True BusinessID with EV
Автор: @s0laris
TutHost
рейтинг 28,78
Реклама помогает поддерживать и развивать наши сервисы

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

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

  • +4
    Вот где Ваша статья была 3 дня назад? Как раз не мог выбрать сертификат.
    За статью спасибо =)
    • +4
      Как раз была в процессе написания. Если нужны будут советы по выбору или установке сертификата в будущем — пишите в личку.
    • 0
      Самый простой и бесплатный способ на самом деле сертификат StartCom.
  • 0
    Есть ли возможность подключить сертификат к Active Directory CA?
    Чтобы корневой CA домена выпускал сертификаты для своего домена, которым бы сразу доверяли все?
    • 0
      Не совсем понял ваш вопрос.
      Если я правильно понял вы хотите самостоятельно выпустить корневой сертификат и использовать его?
      Если так, то использовать его вы сможете разве что у себя внутри организации, у тех пользователей, кто самостоятельно подгрузит его в браузер.
      А вообще корневые сертификаты выпускают только существующие центры сертификации. И эти сертификаты, как правило уже есть в большинстве самых популярных браузеров.

      Список центров сертификации можно посмотреть, например здесь: www.dmoz.org/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/
      • 0
        я так понимаю, человек, для себя хочет свой центр сертификации…
        • 0
          При наличии денежки и отлаженной структуры это вполне реально, я знаю компанию из Польши, которая с нуля также получила права выдавать сертификаты.
          • 0
            Было бы хорошо узнать поподробнее, что где и когда
            • 0
              Если стоит задача продавать сертификаты, то есть несколько вариантов:
              — самый простой стать реселлеров одного из уже существующих центров сертификации или их реселлеров. Благо у большинства есть и отличный API и White Label. При чем зачастую работать с партнерами центров сертификации дешевле, чем напрямую.
              — стать самому центров сертификации. Тут нужна инфрастуктура, большие финансовые вложения. Нужно договориться, чтобы ваши корневые сертификаты были на разных браузерах, ОС и устройствах, на это уйдет не один год и только после этого вы сможете продавать свои сертификаты. К примеру та же Microsoft не допустит ваши сертификаты на свои платформы пока вы не пройдете WebTrust audit, что тоже стоит немалых денег.
              Про аудит можете почитать тут: www.webtrust.org/item64428.aspx
              В общем думаю без средств в несколько миллинов $ можно даже не пытаться.
              • 0
                Плюс сертификация СЦ соответствующими органами внутри страны, где будет стоять инфраструктура СА.
                и очень хорошие администраторы, которые будут этим заниматься, обслуживать инфраструктуру
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        В документации OpenVPN, кстати, про это прямо так и сказано: вы можете использовать ЦС, подписанный публичными ЦС, работать будет. Но лучше используйте свой собственный корневой, а то OpenVPN будет доверять и всем другим сертификатам, которые подписал этот публичный ЦС.
    • 0
      Корневой СА домена это как раз и центр авторизованнй в домене Центр выдачи сертификатов.
      почитайте технет на эту тему.
      Внутри домена Вам больше ничего не надо, т.к корневые сертификаты и почтовые сертификаты пользователя можно публиковать в СА, после чего любой пользоатель домена может подписывать и шифровать переписку между собой.
      Причем есть вариант даже работы с шифрованием и подписью сообщений через owa с недоменных ПК при авторизации на OWA
      • 0
        мне как раз и нужно, чтобы клиенты вне домена доверяли сертификатам, выпущенным для OWA (и Exchange ActiveSync)
        • +1
          В теории — можно свой CA заверить внешним доверенным CA. Только на практике это будет 1) ОЧЕНЬ дорого 2) ОЧЕНЬ сложно, так как все сертификаты, выпущенные Вашим CA будут косвенно заверены вышестоящим, следовательно Вам будет необходимо соблюдать все правила корневого CA, и доказывать ему их соблюдение.

          На практике проще и правильнее получить сертификат на сервер OWA/ActiveSync у внешнего CA, или прописать собственный сертификат всем клиентам.
  • +4
    а можно и вообще бесплатно получить

    www.startssl.com/
    • +6
      Если бы вы прочитали статью, то увидели бы в ней следующее предложение:
      «Также можете для тестов использовать бесплатные сертификаты: StartSSL™ Free»
    • 0
      Есть и такая возможность, я про нее упомянул в статье. Но в случае использования таких сертификатов речь о 99,99% распознаваемости браузерами уже не идет, поэтому такие сертификаты имеет смысл использовать скорее для тестов или для внутреннего использования.
      Кстати на том же сайте можно посмотреть отличие такого бесплатного сертификата от остальных: www.startssl.com/?app=40
      • +1
        да, но вроде бы startssl распазнается браузерами нормально, да же free.
        Ну и цена вроде бы то же не кусается.
      • +1
        А можно уточнить, какие браузеры из современных «не распознают»?

        Абсолютно нормальные сертификаты. Засада там в другом совсем — для коммерческого использования сертификаты уже платные, но для своих доменов — бесплатно и вполне себе работает (все современные браузеры на всех платформах давно их знают)

        Никаких «для тестов», если генерить их на коммерческий домен (не принадлежащий частному лицу и / или используемый для бизнеса) — его или вообще не сгенерят или просто запретят потом.
        • 0
          Из современных пожалуй все распознают.
          Для некоммерческого использования и правда хороший вариант, но в большинстве случаев защищать передаваемую информацию требуется именно на сайтах так или иначе связанных с коммерцией.
          • 0
            мне, например будет очень неприятно, если перехватят пароль в мою админку сайта, так что не только коммерция, а и cms… а еще ssh, sftp, ftps jabber и так далее, не говоря уже про почту
            • 0
              для это передают на сервер не сам пароль, а его хеш
  • 0
    rapidsslonline.com
    promo code — SUPER10OFF
    простой сертификат на 1 год — $16.16
    Если мне не изменяет память, то он даже single root
    • 0
      Сертификат rapidssl действительно сейчас самый выгодный, если не нужна валидация организации и распознаваемость браузерами у него хорошая.
      Если нужен такой сертификат — напишите в личку — сделаем для вас индивидуальную скидку на этот сертификат.
    • +3
      Простите, обманул, есть дешевле =)
      Промо коды
      CHEAP@Rapid1yr95 — $9.5
      CHEAP@Rapid2yr9 — $18
      CHEAP@Rapid3yr85 — $25.5
      CHEAP@Rapid4yr8 — $32
      • –1
        Эти цены, очень близки к себестоимости, поэтому могут быть разве, что временно, как акция.
        • 0
          Реселлер с полностью автоматизированным процессом заказа вполне может жить на маржу в 5%, если за счет этого у него большие обороты. Да и скидочные купоны надо поискать, не все ищут скидку на сертификат, если его и так отдают за 20 баксов
        • +3
          Который год покупаю у namecheap по $9 без всяких акций
          • 0
            Действительно, дают аж за $8. А сертификат single root (то есть подписан напрямую тем CA, что есть в браузерах, или требуется устанавливать цепочку сертификатов)?
            • 0
              В этом месяце добавим у себя сертификаты Comodo. Сертификат PositiveSSL готовы продавать для посетителей хабра по 7 уе за год. Заказ и выпуск полностью автоматические, кому нужно — обращайтесь в личку, или по контактам в профиле.
            • 0
              Я если честно не знаю, что такое single root, но работает вроде нормально, браузеры не ругаются.
              • 0
                Вся схема основана на цепочках доверия: root->intermediate->intermediate->final
                Сертификат root всегда есть в браузере. Промежуточных может не быть.

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

                Если их нет — браузеру придётся их где-то подгрузить, руководтствуясь записями в final и т. д. по цепочке вверх — там обычно пишут, «где найти ЦС». Но в состоянии «оффлайн, инета нет, нужно просто проверить подпись файла» это невозможно.
        • 0
          А можно раскрыть состав себестоимости?
          • 0
            Все просто у нас на эти сертификаты максимальный уровень скидки. Как и у кого берем раскрывать не могу.
            Конечно с такой ценой мы почти ничего не зарабатываем, но сейчас больше интересна лояльность клиентов. С сертификатами работаем давно, в основном работаем с банками и компаниями сферы телекома, теперь вот хотим и для физ. лиц сделать интересное предложение.

            Если интересна партнерка по этим сертификатам — тожем можем предложить вкусные условия
            • +2
              Интересна не партнёрка, а корень зла, из за которого сертификаты стоят денег, причём приличных. Думал, что вы сможете описать схему себестоимости сертификата с нуля, а не только свою накрутку.
              • 0
                Чем-то это похоже на RIPE, например, из чего выходит стоимость за LIR, за то, за сё… тоже не понятно. А RIPE так вообще монополист в регионе, так что, думаю, с сертификатами ещё не всё так плохо.
              • 0
                К сожалению данных из чего состоит себестоимость у меня нету. Но можно предположить, что для сертификатов с валидацией организации — закладывается стоимость выполнения такой проверки, некоторые центры сертификации выполняют такую проверку через субподрядчиков — специальные компании, которые берут на себя ответственность проверять компанию.
                • 0
                  И отчислений в фонд выплаты «гарнтий». Никто их не выплачитвает, но зато чем больше «гарантия» тем большую сумму на отчисления можно заложить в стоимость. А потом в описании выделять «гарантию» большими красными мирающими буквами. И, что интересно, это работает. Сам сталкивался при выборе сертификата с ситуацией когда выбирали при прочих равных сертификат от более дорогого издателя, объясняя это размерами «гарантии». Хотя большинству конечных клиентов глубоко пофигу на тип, издателя и, уж тем более, на размер гарантий.
  • 0
    А можно сгенерировать под Windows? есть ли в природе софт для этого?
    • –1
      Запрос на сертификаты генерируется не операционное системой, а самим веб-сервером или его модулем. В случае с хостингом на windows запрос CSR генерируется прямо в IIS.
    • 0
      makecert.exe
      • 0
        Цитата с оф. сайта про утилитку: «Инструмент для создания сертификатов генерирует сертификаты X.509, предназначенные исключительно для тестирования.»
        • +1
          Разве эти «тестовые» сертификаты как-то по внутреннему устройству отличаются от «настоящих»?

          Другими словами, есть ли способ отличить сертификат, сгенерированный makecert, от сертификата, сделанного тем же openssl?
          • –2
            Открытый ключ, который CSR подпись скорей всего никак не отличается, а вот закрытый ключ (сертификат) отличается тем, что браузер будет «ругаться» на такой сертификат.
            • +1
              О… оказыватся, вы не в курсе.

              Закрытый ключ != сертификат.

              Более того, сертификат — штука полностью публичная, он никаким образом не содержит закрытый ключ, даже зашифрованный. Но он содержит электронную подпись, выполненную с помощью закрытого ключа ЦС, выдавшего сертификат.
              • –2
                Действительно данное упрощение не совсем корректно. Закрытый ключ хранится на сервере и его категорически запрещается предоставлять кому либо.
                • +3
                  Всё-таки, «совсем некорректно».

                  Кстати говоря, CSR тоже не эквивалентно открытому ключу. И называется он поэтому не так — не «открытый ключ», не «public key», а «запрос подписи сертификата», «certificate signing request». Там, помимо ключа, ещё и дополнительные данные, которые хотелось бы к нему «приделать» и чтобы подпись сертификата (собственно центра сертификации) удостоверяла и их тоже.

                  Это очень важный вопрос. Именно эти «дополнительные данные» и содержат, например, dns-имя сервера, которое требуется подтвердить сертификатом.
                  • 0
                    Наверное действительно стоило раскрыть, что же содержится в самом сертификате.
                    Это:
                    — полное (уникальное) имя владельца сертификата
                    — открытый ключ владельца
                    — дата выдачи ssl сертификата
                    — дата окончания сертификата
                    — полное (уникальное) имя центра сертификации
                    — цифровая подпись издателя

                    Добавлю эту информацию в статью.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Вообще да, в статье тема вопросов отзыва сертификатов не затронута, а зря. Для проверки подлинности CRL ровно настолько же важны, насколько и сами сертификаты ;)
                      • 0
                        Статья была рассчитана на широкую публику, пока что в своей практике с отзывом сертификатов не сталкивались, если удастся что-то узнать по этой теме, то напишу в следующей части.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Похоже мы друг друга не поняли, давайте уточним какой отзыв вы имеете в виду? Вы имели в виду отмену/отзыв (revoke) сертификата клиентом? Или?

                            Случаи, когда клиент отменял сертификат были, но почти во всех случаях это было из-за неправильно заполненных данных и необходимости оформить заказа заново, либо из-за неверно выбранного типа сертификата.
                            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              А по теме: если я с помощью MakeCert подпишу какой-нибудь объект с секретным ключом доверенного ЦС (предположим, такой ключ у меня есть), то браузер ругаться не будет.
      • 0
        > makecert.exe
        openssl.exe
    • 0
      а можно и openssl пот windows использовать. Работает точно так же. Есть ещё набор скриптов, упрощающих его использование — easy-rsa (кстати, идёт в комплекте с openvpn).
  • +3
    1. Вот корневые ЦС продают сертификаты, рассчитывая на то, что в браузерах сертификаты их самих уже есть. А что с этого имеют производители браузеров? По идее, я, выпуская свой браузер, вполне имею право выкинуть оттуда какой-нибудь VeriSign. Мой браузер, что хочу, то и делаю. А, все сайты отображаются как недоверенные? Ну так они и есть недоверенные, я, как производитель браузера не доверяю этому ЦС. Если ЦС хочет, чтобы я ему доверял, пусть он мне платит, скажем, проценты с продаж сертификатов.

    Так рассуждая, приходим к тому, что, скажем условный Verisign должен много денег разработчикам lynx.

    1а. А теперь я не производитель браузера, но разрабатываю дистрибутив Linux. В моём репозитарии в пакете с этим браузером сертификат Verisign отсутствует. Ну и далее — по тексту выше.

    2. Вот браузер, в нём встроены сертификаты ЦС. Что мешает держателю очередного сайта с софтом, типа all-new-soft.ru, перепаковать дистрибутив, добавив туда в список доверенных какой-нибудь свой ЦС? Или же при запросе на скачивание использовать уязвимость HTTP к подделке и подсунуть другой файл с дистрибутивом. Ведь все браузеры, как правило, скачиваются по HTTP, без проверки подлинности источника.

    Всё, теперь я — ЦС, и могу продавать сертификаты. Более того, я могу продать сертификат, например, для сайта microsoft.com, и браузер будет рассматривать его как доверенный, а поддельный сайт microsoft.com — как подлинный.

    Из всего этого я могу сделать ровно один неутешительный вывод: вся эта продажа сертификатов — чистой воды торговля воздухом. Действительно доверять можно только тем ЦС, которые ты установил в бразуер сам.
    • 0
      Не совсем так. Во первых центры сертификации регулярно проходят проверку, на их соответствие существующем правилам. Во вторых кто угодно не может получить права выдавать сертификаты, для этого нужно соответствовать достаточно длинному списку требований. Ну и в третьих у некоторых сертификатов есть так называемая гарантия. То есть центр сертификации гарантирует посетителю сайта с таким сертификатом, что на таком сайте он не пострадает от фрауда. Об этом я также упомянул в статье.
      • 0
        Вы меня так и не поняли
        1. С какой стати я, производитель браузера, обязан включать все эти ЦС в свой дистрибутив?
        2. Почему это я, производитель бразуера, не могу включить любой другой ЦС в свой дистрибутив?
        • 0
          Спасибо за пояснение.
          1. Очевидно существует некоторая договоренность между центрами сертификации и производителями браузеров и есть вероятность, что производители браузеров получают с этого некоторые отчисления.

          С другой стороны если в браузере не будет не одного корневного сертификата пользователь такого браузера увидит ошибку на множестве сайтов, которые до этого ошибки не выдавали и скорей всего перестанет использовать такой браузер.

          Так что есть свой интерес и у производителей браузеров.

          2. Можете.
          • +1
            Отлично! И теперь снова ко второму вопросу: я, производитель браузера, подписал с помощью своего собственного ЦС сертификат для paypal.com. А потом кто-нибудь сделал сайт, отравил DNS и направил ничего не подозревающего пользователя на поддельный ресурс. Браузер, однако, будет считать этот поддельный paypal настоящим — ведь сертификат-то прошёл проверку подлинности!

            Как в этой всей схеме PKI учитывается такой вариант?
            • 0
              Это уже вопрос ответственности производителя браузера перед своими клиентами.
              К тому же у крупных организаций почти у всех стоит если не EV сертификат, то как минимум сертификат с валидацией организации. А если центр сертификации выдаст такой сертификат фейковой организации, то он с большой вероятностью лишиться своей аккредитации и права выдавать сертификаты.
              • +1
                Да нет у меня никакой аккредитации! Я всего лишь производитель браузера, а то и просто злоумышленник, который сделал свой дистрибутив со своим ЦС и подсовываю его пользователям через уязвимости в протоколах.
                • 0
                  Не проще ли сразу бэкдор поставить в браузер?
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Этот способ не использует никаких недокументированных или секретных особенностей. Никаких уязвимостей в коде. То есть, анализ кода не выявит никаких проблем.

                    Для выявления нужно анализировать конкретный дистрибутив, причём очень внимательно. Дело в том, что я могу даже сделать свой ЦС и заполнить поля в нём такими же значениями, как у Verisign. Отличить от настоящего можно только позвонил в Verisign и сверив отпечатки ключа, больше никак.
                    А сертификатов предустановлено порядка сотни. Представляете себе проверку каждого дистрибутива для каждого релиза?

                    Так сложно затем, что потом это сложно заметить.
        • 0
          1. Не обязаны. Но получите по голове от своих же пользователей за такое
          2. Можете. Получите по голове от аналитиков и тех, кто проверяет безопасность.
          Кроме того, вы можете сделать в своём бразуере backdoor или сливать всю информацию о пользователях. Это гораздо более эффективный путь.
          • +1
            Встроить ещё один сертификат может не только производитель браузера, а и дистрибьютор. Скажем, Яндекс возьмёт и добавит ещё и свой ЦС в свой дистрибутив Файерфокса, вместе с Я.баром. Мозилла в этом никак не будет замешана.

            И злоумышленник тоже может так сделать — он тоже подсунет пользователю свой файерфокс, со своим встроенным ЦС.

            Повторюсь, пока браузеры у нас скачивают по HTTP и подписи никакие никто не проверяет — дистрибутив можно подделать, и вся, вся схема с «предустановленными в браузере сертификатами» ненадёжна и порочна.
            • +1
              Злоумышленнику недостаточно подсунуть пользователю свою сборку (а это уже не просто), надо еще заставить пользователя зайти на нужный ресурс. Причем не просто абы какому пользователю, а целевому. Та еще задачка, правда? Да и скажите мне, как много пользователей скачивают и пользуется «левыми» браузерами и сборками? Думаю, что не ошибусь, если их процент пренебрежительно мал.
              По поводу яндекса: он не будет добавлять свой УЦ в свою же сборку firefox`a по очень простой причине: это бессмысленно, потому как сертификаты яндекса будут работать только под его сборками, а соответственно все остальные посетители, использующие другие браузеры, будут получать предупреждение о не валидном сертификате. Яндексу это не надо.
              На мой взгляд, вы сгущаете краски. Сертификаты работают вот уже много лет и это говорит о том, что их надежность вполне достаточна для абсолютного большинства пользователей.
              • 0
                Задачи направленной атаки — несколько иные, не такие широкие, как вы тут представили: есть некий пользователь и некий ресурс, взаимодействие которых нужно скомпроментировать. Никого не нужно заставлять куда-то заходить. Достаточно поймать момент, когда выпустят очередную версию файерфокса, и подсунуть обновление с сертификатом.

                Месяца два-три назад тут обсуждалась конкретная атака, реализованная таким способом (подделкой инсталлятора, переданного жертве с использованием ARP spoofing). Там поставили трояна на комп жертвы, а могли засандалить сертификат — его и обнаружить гораздо сложнее, чем троян. И потом можно тем же способом перехватить взаимодействие жертвы с искомым ресурсом.
                • 0
                  Ну вряд ли успех такой атаки — это проблема сертификатов. Напротив, использование https при скачивании обновлений существенно бы снизило риск заражения, здесь вы верно заметили — проблема в том, что до сих пор при обновлении может использоваться http без всяких проверок. Кстати, как в настоящий момент с этим обстоят дела у современных хрома и firefox`a?

                  Да и к тому же особенность направленной атаки — это ее заточка под жертву, здесь и меры предосторожности должны быть совершенно другого уровня. Серебряной пули не существует, комплексная защита рулит ;-)
                • 0
                  Собственно, именно для этого все «очередные» версии Файрфокса тоже подписываются сертификатами, но уже для Code signing. И, скачав «левый» браузер, Вы увидите, что он выпущен не Mozilla Corporation, а Zloy Cracker Ltd. Отсюда и всеобщая тенденция к подписыванию пакетов/исполняемых файлов. И чтобы подделать подпись пакета, уже придется устанавливать на компьютер «патченую» ОС, доверяющую «злому» ЦС.
                  • 0
                    Про Code Signing планирую рассказать в следующей статье.
                  • 0
                    То, что я предлагаю, не влияет на код. Сертификаты, интегрированные в бразуер, не хранятся в коде.

                    Вопрос в подписывании не кода, а самого пакета. В линуксах эта проблема давно решена — всё ставится из репозитариев, где опять же всё подписано; в винде решения пока что нет — для установки браузера качаем инсталлятор по http, а потом при установке, даже если система спросит «доверять ли этому издателю», нажмём «всё равно установить».
                    • 0
                      Ну я по большей части и имел в виду подписывание пакета. Но Вы же сами говорите, что «нажмем „всё равно установить“» — значит проблема не в «винде», а в пользователе. Любая безопасность сводится к самому слабому звену — человеку. Который, кстати, и нажать «всё равно открыть страницу с поддельным сертификатом» запросто может, даже если идет в клиент-банк. Ведь очень нужно за интернет заплатить, например. Безопасен только неработающий компьютер.
              • 0
                Так вот, а последнее предложение вообще нонсенс. Вот, опять же, недавно исправили 25-летний баг во FreeBSD. Да, баги могут жить так долго, и быть незамеченными.
                • 0
                  Нормальная ситуация, на мой взгляд. От багов избавлены только те продукты, которые никогда не создавались. Уверен, если поколупать сорцы повнимательнее, то можно найти еще парочку таких «старичков». Это не повод, отказываться от сертификатов или от любой другой технологии. Вступайте в сообщества, думайте, предлагайте и совершенствуйте. Все в ваших руках.
      • 0
        Если быть американским юристом, то после прочтения этих гарантий станет ясно, что гарантия распространятеся на тот случай, когда сам удостоверяющий центр будет скомпрометирован, и кто-то выпустит левый сертификат, откроет на нем поддельный сайт ситибанка и украдет 100500 миллиардов долларов. Да, ситибанку вернут 100 тыщ долларов.

        Иными словами — это просто маркетинговая лапша

        При выдаче простого (не-EV) сертификата проверяется только то, что почту в домене может прочитать запросивший сертификат клиент, какие там требования — пустая формальность.

        Сертификаты пытаются выдать за доверие, а это давно уже простое шифрование транспортного уровня. Попыткой это изменить стали EV-сертификаты. Да, зелененькой полоске доверия больше, чем серенькому замочку.
        • 0
          Поэтому эту самую гарантию можно смело игнорировать как параметр, при выборе сертификата.
          А по уровню доверия типа всего три: валидация домена, валидация организации и EV.
    • –1
      Если вы сравните цены на сертификаты, это будет намного очевидней.
      Например rapidssl и у его же реселлеров: $50 и $10, или вот те же $10 и $150 у Thawte.
      Если одно и то же кто-то продает в 15 раз дешевле, то он явно продает воздух.
      • 0
        Если кто-то продаёт воздух, а кто-то другой продаёт то же самое в 15 раз дороже, то этот кто-то другой просто продаёт воздух в 15 раз дороже, верно?
      • 0
        Наверное все таки будет корректнее сказать, что продается уровень доверия, ведь чисто технически https можно поднять и на самоподписном сертификате.
        • –1
          Почему же сертификат за 10 баксов в моём браузере стоит рядом с сертификатом за 150 баксов, и работает совершенно так же? Где здесь «уровень доверия»?

          Специально посмотрел спецификации: никаких стандартных полей типа «уровня доверия» и «тщательности проверки» в сертификатах нет, т.е. схема PKI не рассматривает такие вопросы.

          Эти сертификаты не различаются ничем, кроме поля «issuer». Браузеру же это поле неинтересно, он его никак не анализирует, т.е. с точки зрения браузера — вообще ничем не отличаются. И работают одинаково.

          Неискушённого пользователя элементарно просто обмануть и вызвать в нём ложное чувство безопасности — ведь SSL же и сертификат доверенный, какая там разница, кем он выдан?
          • 0
            Действительно во многих случаях сертификаты от разных центров сертификации технически никак между собой не отличаются, тут уже роль может играть привычный пользователю бренд.

            У нас были клиенты, которые готовы были переплачивать за сертификаты от Verisign, хотя мы им разъяснили, что принципальных отличий от более дешевых сертификатов у них нет.
          • 0
            Выяснилось, что я ошибся. Есть расширение, которое имеет ASN1 номер 2.16.840.1.113733.1.7.48.1 (в символьной нотации {joint-iso-itu-t(2) country(16) us(840) organization(1) symantec(113733) pki(1) policies(7) 48 1}) и носит смысл смысл «Thawte Extended Validation (EV) Certification Practice Statement (CPS) v. 3.3».

            Браузеры (по крайней мере, Fx) его обрабатывают. Т.е. браузер отличает сертификат Thawte EV от других валидных сертификатов.

            Разумеется, ни один уважающий себя ЦС мне сертификат с таким полем не захочет выдавать (если только это не Thawte и он не произвёл EV, разумеется). Но опять же, любой не уважающий себя ЦС вполне (технически) способен это сделать, т.е. я могу сам себе сделать ЦС и выдать как бы Thawte EV-сертификат.
      • 0
        1) некоторые компании для всех вопросов работают с одним поставщиков, они готовы переплачивать в 10 раз, но не распыляться за каждую копейку, ища где подешевле
        2) покупается не столько продукт (сертефикат), сколько поддержка (у траста она будет одна, у ресселера совсем другая, или просто будет отсутствовать)
        • 0
          На счет поддержки, тоже по собственной практике, если сравнивать когда клиент напрямую пытается решить проблему с центром сертификации и когда через нас — у нас обычно получается быстрее. Хотя бы потому, что есть уже накопленный опыт взаимодействия с центрами сертификации.
  • +1
    Для своих сайтов использую www.startssl.com/ — бесплатный отличный сертификат для персонального использования.
    Для корпоративных в основном www.rapidssl.com/
    • 0
      RapidSSL — хороши своей ценой, но у них нет сертификатов с валидацией организации. Хотя в этом их фишка, только дешевые сертификаты с мгновенным выпуском.
  • 0
    Спасибо за инфу!
  • +2
    >> Для того, чтобы активировать возможность работы протокола HTTPS… потребуется выделенный IP для конкретного сайта.

    А разве SNI (Server Name Indication) не снимает это ограничение?
    • 0
      Снимает. Это ошибка в статье.
    • –4
      SNI — относительно новая возможность, доступна в PHP c версии 5.3.2 и требует PHP собранного с библиотекой OpenSSL версии 0.9.8j или выше.
      Поддерживается всеми новыми браузерами, начиная с версий:

      Opera 8.0;
      MSIE 7.0 (но только на Windows Vista и выше);
      Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1;
      Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше);
      и Chrome (Windows-версия также поддерживает SNI только на Vista и выше).

      Но далеко не все знают про эту опцию и используют ее, в большинстве случаев клиенты используют SSL вместе с выделенным IP.
      • +2
        Уважаемый, сдерживался я, сдерживался, но не могу больше.

        Вы некомпетентны.

        Во-первых, поддержка SNI никакого отношения к PHP не имеет. Веб-сервер может и вообще не знать про PHP, а SNI он будет уметь.

        Это в Apache принято встраивать PHP при помощи SAPI-модуля — тут да, сервер как бы «сам умеет» выполнять php-скрипты с помощью плагина. А вот nginx с PHP не знаком — интерпретатор не встроен в сервер, он связывается с интепретатором по стандартному протоколу, которым может быть CGI, FastCGI, UWSGI.

        А SNI умеет как Apache, так и nginx (и оба — потому, что его умеет бибиотека OpenSSL).

        Во-вторых, то, что про SNI кто-то там не знает, не значит, что он не будет работать и что его невозможно настроить.
        • 0
          Спасибо за пояснения, действительно про SNI лично ранее не знал, выше процитировал статью про настройку SNI для nginx.

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

          Спасибо за полезную подсказку…
          • +1
            На всякий случай, RFC 4366, пункт 3.1 — место, где SNI описано. Кстати, из названия RFC (именно, TLS extensions) следует, что SNI — это (стандартизированное) расширение протокола TLS v1, и может вполе применяться не только для HTTPS, но и любых других протоколов, которые способны работать поверх с TLS. А это, например, SMTP, IMAP, POP3, XMPP (в котором ещё есть свой собственный механизм, реализующий то же самое).

            Кстати говоря, что касается покупки и использования сертификатов — абсолютно всё, что применимо к HTTP, применимо и к ним тоже. Т. е. для IMAP over TLS на своём сервере потребуется купить сертификат. И можно настроить проверку клиентских сертификатов, и даже аутентифицировать пользователей по ним — по Subject DN в клиентском сертификате, а не по логину-паролю, как это делается традиционно.
            • +1
              На всякий случай: RFC 4366 уже 4 года как устарел. Актуальный RFC 6066.
          • 0
            Какую статью? В статье на nginx.org про php ни слова, и никогда не было.
        • –2
          Для nginx есть нюансы
          — системный OpenSSL может оказаться старой версии (ниже 1.0.1)
          — сам nginx версии ниже 1.1.13 и 1.0.12
          — TLSv1.1/1.2 могут быть не включены в директиве ssl_protocols
          А так да, вполне себе работает
          • 0
            Эмм… What?

            — OpenSSL поддерживает SNI начиная с версии 0.9.8f
            — Nginx поддерживает SNI начиная с версии 0.5.32
            — TLSv1.1/1.2 тут ни при чём.
        • 0
          Это одна из тех статей, где в комментариях узнаешь чуть больше, чем из основной статьи.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Как минимум ключ должен хранится в директории недоступной извне и для пользователей.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          В определённых сферах деятельности нельзя доверяться HSM'у без сертификации FIPS -140.
          В добавок должны быть отдельные карты для админа (ACS) и оператора (OCS), что б это дела работало

    • 0
      Запарольте ключ, и сервер (Апач точно) при старте будет спрашивать пароль. Минус простой — сам не запустится
      • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Теоретически, для этого придуман TPM. OpenSSL может использовать TPM в качестве криптодвижка, т.е. основные функции, вроде собственно шифрования, делегирования и т. п., делать с его помощью.

      Однако, попробовать это самому ни разу не довелось, в нашей стране TPM нелегален.

      • 0
        мда, мысли вперёд слов…

        имел ввиду: «основные функции, вроде собственно шифрования, делегировать ему». например, можно запечатать в TPM собственно парольную фразу секретного ключа.
  • 0
    > после успешной проверки выпустит SSL сертификат с вашими данными и разрешит вам использовать SSL

    Выпустить сертификат — это как раз да, то, что я от них и жду. Но «разрешать мне использовать SSL» — это не совсем в их власти и функциях. Я SSL могу использовать, когда захочу (если настрою, конечно), разница только в том, кто создаст сертификат.
    • 0
      Спасибо за уточнение, скорректировал фразу.
  • 0
    Спасибо за статью! К сожалению, совсем нет информации по сертификатам для разработчиков (Code Signing сертификаты), например, какой тип сертификата, а так же какой центр сертификации вы можете посоветовать для подписи расширений для Firefox, что бы при установке браузер не выдавал предупреждения и не писал «Author not verified»?

    Спасибо!
    • 0
      Про Code Signing планирую написать в следующей статье, в этой статье только про SSL.
  • 0
    Добавлю про wildcard — они действуют только на домены, которые на один уровень выше, чем тот, на который был выдан сертификат, т.е. если вы покупаете wildcard на *.site.ru, то www.site.ru, admin.site.ru в браузере будут выглядеть нормально, но на www.admin.site.ru браузер уже выведет предупреждение.
    • 0
      Полезное уточнение, спасибо.
      Еще один момент забыл упомянуть в статье. Если обычный сертификат заказать для www.domainname.com то такой сертификат будет работать и на domainname.com, а вот наоборот работать не будет.

      Поддержка этой опции: защита домена с www и без www есть не у всех сертификатов, работает эта опция у следующих сертификатов:

      • RapidSSL
      • QuickSSL Premium
      • True BusinessID
      • True BusinessID with EV
      • 0
        > Если обычный сертификат заказать для www.domainname.com то такой сертификат будет работать и на domainname.com, а вот наоборот работать не будет.

        Это вовсе не всегда так, а только если в сертификате прописаны subject alt name (ну то есть, сертификат выдан «для нескольких доменов сразу»). Некоторые делают так «по умолчанию», если основное subject cname начинается с www, но это необязательно.

        А вообще так можно сделать и для любых других имён. Прописываем пять разных subject alt name, и для всех шести (основной + пять альтов) наш сертификат работает. Правда, как и SNI, это поддерживается не всеми. Например, вот сообщение, что это не поддерживалось в Андроиде (не знаю, починили ли).
        • 0
          Сертификаты в которых можно прописать пять разных subject alt name — это SAN сертификаты, я писал о них в статье, в остальных сертификатах такой возможности нет.
          • 0
            wiki.cacert.org/VhostTaskForce#Interoperability_Test вот анализ софтовой поддержки различных способов запихнуть несколько имён в один сертификат

            SAN — один из способов. Другой — wildcard.

            Других способов нет ;) если ваш сертификат поддерживает несколько имён (случай «с www и без www в том числе), значит, он сделан одним из этих способов.
  • 0
    Где происходит физически генерация csr? На вашем сервере? Если так, то одновременно с csr генерируется закрытый ключ. По каким каналам вы осуществляете доставку закрытого ключа?
    В любом случае, даже если этот канал очень надежный, я считаю такой закрытый ключ скомпрометированным, поскольку он был доступен вышим сотрудникам
    • 0
      CSR клиент генерирует сам при заказе сертификата, где сохранять закрытый ключ также решает клиент, для выпуска сертификата нам не нужен закрытый ключ и клиент нам его никак не передает.
      Естественно если это происходит на обычном виртуальном, то у администраторов с root доступом к серверу есть доступ и к ключам, которые там хранятся.
      • 0
        Генерирует сам клиент, но программа генерации запускается на вашем сервере? Тогда вам ничто не мешает параллельно с выдачей закрытого ключа клиенту сохранить его у себя
        • 0
          Если сертификат будет использоваться клиентом у себя на сервере, то и генерирует он ключ у себя на сервере, если сертификат будет использовать у нас на виртуальном хостинге — то и генерация происходит на том сервере, где размещен клиент.

          Вы ведь, когда свои сайты храните на хостинге, тоже доверяете какому-то хостеру все свои файлы и данные и осознаете при этом, что часть сотрудников хостера имеет полный доступ к данным на сервере.
        • –2
          Вы создаёте приватный ключ и вместе с ним csr. csr — публичная штука (открытый ключ + допинформация), покидает комп. Приватный ключ — создаётся вами на вашей системе и никогда никуда с неё не перемещается.

          Например, у startssl free это сделано в браузере, посредством javascript, т.е. приватный ключ генерируется прямо в браузере на стороне клиента, и никуда из него не пересылается.
          • +1
            Повторюсь еще раз CSR и приватный ключ генерируется на сервере, где будет использоваться сертификат, какими средствами зависит от сервера и операционной системы.
            Хотя при желании вы можете сгенерировать сертификат и у себя на компьютере.

            Приватный ключ — не создается на нашей системе, за исключением случаев, когда клиент покупает у нас виртуальный хостинг и генерирует сертификат через панель управления хостингом.
            • 0
              Теперь понятно, спасибо
            • 0
              Я просто спрашивал это потому, что сам в свое время реализовывал со студентами учебный проект, в котором пользователям подписывались сертификаты. Была дилемма: либо пользователи должны знать openssl (утилиту) и сами генерировать ключ, либо сервис генерирует пользователю ключ и выдает при регистрации, но тогда ключ сразу скомпрометирован. Классическая пролемы удобство vs безопасность. Тогда пришли к выводу, что компромиссный вариант — создать java applet — и пользователю удобно, и генерация на его десктопе без передачи по каналам. Альтернативные варианты — activex, flash или javascript (последние 2 — для маньяков-программистов). Однако этот вариант с java или альтернативами так и остался не реализованным…
          • 0
            >у startssl free это сделано в браузере, посредством javascript
            интересно, есть какие-нибудь библиотеки, или они самостоятельно реализовывали md5, sha1, rsa и т. п. Кстати, и генератор ПСЧ еще нужен, интересно его проверить на уязвимости.
            • 0
              А в чём проблема с реализацией md5 на javascript? Такая реализация есть даже на странице входа в веб-интерфейс модемов Zyxel P600 третьего поколения, что уж говорить про startssl.

              Про ГСЧ я не помню — кажется, просили дёргать мышкой для повышения случайности
  • 0
    s0laris, Вы привели в пример скриншоты сайтов с самоподписанным сертификатом и сертификатом «расширенной проверки» EV. А покажите, как будут выглядеть сертификаты DV и OV. В виде скриншотов или ссылки на сайты с этими видами сертификатов дайте, пожалуйста.
    • 0
      • 0
        Правильно ли я понимаю, что для посетителя сайта «визуальной» разницы между DV и OV нет никакой?
        • 0
          Если не заходить в информацию о сертификате, то в адресной строке они никак не отличаются.
  • 0
    Вторая часть статьи по Code Signing сертификаты опубликована: habrahabr.ru/company/tuthost/blog/152867/
  • 0
    Спасибо Вам большое за статью! По этой статье я как раз для себя развеял вопросы по SSL сертификатам.
  • 0
    Вопрос, с точки зрения безопасности, чем отличается TLS и SSL сертификат?

    Почему SSL считается менее безопасным?
    • +2
      Сертификат это файл, который подписан кем-либо, и он нет знает где его будут использовать. TLS и SSL это протоколы, которые используют сертификат.
      SSL не безопасен в связи с тем что он уязвим к атакам BEAST и POODLE, эти уязвимости невозможно починить только с серверной стороны.
      p.s. для вопросов есть toster

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

Самое читаемое Разное