20 июля компания Google объявила о том, что браузер Chrome перестает считать доверенными SSL-сертификаты, выданные центром сертификации (CA) WoSign и его дочерним предприятием StartCom. Как пояснили в компании, решение связано с рядом инцидентов, не соответствующим высоким стандартам CA, — в частности, выдаче сертификатов без авторизации со стороны ИТ-гиганта.
Чуть ранее в этом году также стало известно, что организации, ответственные за выдачу сертификатов, должны будут начать учитывать специальные DNS-записи. Эти записи позволят владельцам доменов определять «круг лиц», которым будет дозволено выдавать SSL/TLS-сертификаты для их домена.
Все эти решения в какой-то степени связаны с увеличением числа хакерских атак и фишинговых сайтов. Зашифрованные соединения с веб-сайтами по HTTPS приобретают всё большее распространение в интернете. Сертификаты не только позволяют зашифровать данные, пересылаемые между браузером и веб-сервером, но и удостоверить организацию, которой принадлежит сайт. В сегодняшнем материале мы посмотрим, какие виды сертификатов бывают и коснемся вопросов их получения.
/ Flickr / montillon.a / CC
Все SSL-сертификаты используют одинаковые методы защиты данных. Для аутентификации применяются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Однако при этом они различаются по методу проверки: любой сертификат должен быть верифицирован центром сертификации, дабы удостовериться, что он принадлежит корректному и авторизованному сайту. Выделяют несколько видов сертификатов.
Первый тип сертификатов — это сертификаты с проверкой домена (Domain Validated). Они подходят для некоммерческих сайтов, поскольку подтверждают только обслуживающий сайт веб-сервер, на который осуществлён переход. DV-сертификат не содержит идентифицирующей информации в поле имени организации. Обычно там числится значение «Persona Not Validated» или «Unknown».
Для проверки лица запросившего сертификат центр сертификации высылает письмо на электронный адрес, связанный с доменным именем (например, admin@yourdomainname.com). Это делается для того, чтобы удостовериться, что лицо, запросившее сертификат, действительно является владельцем доменного имени. Компании Google не нужно доказывать общественности, что www.google.com принадлежит ей, поэтому она вполне может использовать простые сертификаты с проверкой домена (однако ИТ-гигант все равно использует OV-сертификаты, о которых далее).
Другие варианты верификации — добавление TXT-записи в DNS или размещение на сервере специального файла, который может быть прочитан CA. Этот вид сертификата самый дешевый и популярный, но не считается полностью безопасным, поскольку содержит информацию лишь о зарегистрированном доменном имени. Поэтому они часто используются для защиты во внутренних сетях или на небольших веб-сайтах.
Второй тип сертификатов носит название Organization Validated, или сертификаты с проверкой организации. Они более надежны, по сравнению с DV, поскольку дополнительно подтверждают регистрационные данные компании-владельца онлайн-ресурса. Всю необходимую информацию компания предоставляет при покупке сертификата, а CA затем напрямую связывается с представителями организации для её подтверждения.
Третий тип — это Extended Validation, или сертификат с расширенной проверкой, который считается самым надежным. Впервые появился в 2007 году и нужен веб-сайтам, которые проводят финансовые транзакции с высоким уровнем конфиденциальности. В этом случае целая адресная строка браузера будет выделяться зеленым цветом (поэтому их и называют «с зеленой строкой»). Плюс в зеленой области будет указано название компании.
О том, как разные браузеры информируют пользователей о наличии того или иного сертификата можно почитать тут.
Отметим, что если для совершения платежей и обработки транзакций пользователь перенаправляется на сторонний сайт, подтверждённый сертификатом с расширенной проверкой, то в этом случае хватит обычных сертификатов OV.
EV-сертификаты полезны, если необходимо «жестко» связать домен с физической организацией. Например, Bank of America и домен bankofamerica.com. В этом случае сертификат с проверкой организации гарантирует, что ресурс действительно принадлежит банку, куда пользователь может физически занести свои деньги — это как минимум удобно для пользователей.
Более того, EV-сертификаты защищают от атак с использованием фишинговых сайтов, как это было в случае с Mountain America Credit Union. Злоумышленники сумели получить легальный SSL-сертификат для копии сайта кредитной организации. Дело в том, что банк использовал доменное имя macu.com, а атакующие использовали имя mountain-america.net и при подаче заявки «вывесили» невинно выглядящий сайт. После получения сертификата сайт был заменен на фишинговый ресурс. EV-сертификаты серьезно затрудняют выполнение подобного «фокуса» — как минимум адрес виновника становится сразу известен.
Выдавая сертификаты типа OV или EV, сертификационный центр должен убедиться, что компания, получающая сертификат, действительно существует, официально зарегистрирована, имеет офис, а все указанные контакты — рабочие. Оценка организации начинается с проверки её официальной государственной регистрации. На территории России это выполняется с помощью реестра юридических лиц, представленного на сайте ФНС.
После получения заявки на сертификат, CA присылает бланки с вопросами об организации, которые нужно заполнить и подписать. Свои подписи и печати ставят руководитель компании и главный бухгалтер. После чего отсканированные документы отправляются обратно в центр сертификации, где их проверяют по идентификаторам ЕГРЮЛ и ИНН.
Если предоставленные данные полностью удовлетворяют сотрудников сертификационного центра, то выдается сертификат. Если же потребуется провести легализацию документов, то придется отправить по электронной почте в центр сертификации отсканированные изображения запрошенных документов.
Предварительно стоит уточнить, требуется ли перевод этих документов и нотариальное удостоверение перевода, а также требуется ли удостоверение нотариуса апостилем. Вместо апостиля для подтверждения полномочий нотариуса, можно сообщить центру сертификации соответствующую ссылку на сайте Федеральной нотариальной палаты. И перевод, и нотариальные услуги, и апостиль потребуют некоторых дополнительных расходов и организационных усилий, поэтому до подтверждения необходимости этих действий центром сертификации заниматься ими не стоит.
CA могут выдавать EV-сертификаты и государственным учреждениям, однако последние должны удовлетворять ряду требований. Во-первых, существование организации должно подтверждаться административно-территориальным образованием, в котором она оперирует. Во-вторых, организация не должна находиться в стране, где запрещена деятельность CA, выдающего сертификат. Также сама государственная структура не должна быть представлена в каком-либо из перечней запрещенных организаций.
При этом отметим, что также существуют международные агентства, которые могут проверять официальные документы компании и выступать удостоверителем её законного существования. Наиболее известным из таких агентств является Dun & Bradstreet. После проверки организации D&B выдаёт цифровой идентификатор — DUNS (Digital Universal Numbering System) — на который можно ссылаться для подтверждения легальности организации.
Оформление SSL-сертификата типа OV или EV потребует от организации, желающей его получить, некоторых расходов. Однако результатом всех затраченных усилий станет повышение репутации и уровня доверия клиентов к организации в интернете.
Вообще, чтобы зашифровать данные, пересылаемые между веб-сервером и браузером пользователя, достаточно одного сертификата. Однако, если посмотреть на путь сертификации ресурса google.ru, можно увидеть, что их целых три.
При посещении многих сайтов, например, банков или железнодорожных касс, пользователи хотят уверенными не только в том, что соединение защищено, но и в том, что открывшийся сайт — правильный. Для удостоверения этого факта одного сертификата недостаточно. Нужно, чтобы третья сторона (центр сертификации) подтвердила, что для защиты соединения используется сертификат, выпущенный именно для этого сайта.
Если некто «Б» удостоверил личность «А», и вы доверяете «Б», то проблема решена.
Если же вы не знаете «Б», то он может сообщить, что его знает «В».
Длина цепочки удостоверений не ограничена. Главное, чтобы в ней оказался тот, кому доверяет пользователь. Более того, исторически и технологически сложилось так, что ряд центров сертификации получили наибольшее признание в ИТ-области. Поэтому было принято согласованное решение назвать их криптографические сертификаты корневыми и всегда доверять таким подписям.
Перечень корневых центров сертификации и их публичных ключей хранится на компьютере пользователя. Если цепочку последовательно подписанных сертификатов завершает корневой сертификат, все сертификаты, входящие в эту цепочку, считаются подтверждёнными.
Напоследок хотелось бы сказать, что помимо обозначенной градации сертификатов — DV, OV, EV — существуют и другие типы сертификатов. Например, сертификаты могут отличаться по количеству доменов, на которые они выдаются. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, указываемому при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, но за каждое наименование, включаемое в список сверх обозначенного количества, придется доплачивать отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать помимо доменов несколько поддоменов. В таких случаях стоит приобретать сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL. Отметим, что в этом случае можно также приобрести обычный мультидоменный сертификат, в котором просто указать необходимые поддомены.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого получается через любой генератор, например, бесплатный OpenSSL. Такие защищенные каналы связи можно с легкостью использовать для внутренних нужд компании: для обмена между устройствами сети или приложениями. Однако для использования на внешнем веб-сайте необходимо покупать официальный сертификат. В этом случае браузеры не будут показывать сообщения о небезопасном соединении, а будут спокойны за пересылаемые данные.
P.S. Несколько материалов по теме из нашего блога:
Чуть ранее в этом году также стало известно, что организации, ответственные за выдачу сертификатов, должны будут начать учитывать специальные DNS-записи. Эти записи позволят владельцам доменов определять «круг лиц», которым будет дозволено выдавать SSL/TLS-сертификаты для их домена.
Все эти решения в какой-то степени связаны с увеличением числа хакерских атак и фишинговых сайтов. Зашифрованные соединения с веб-сайтами по HTTPS приобретают всё большее распространение в интернете. Сертификаты не только позволяют зашифровать данные, пересылаемые между браузером и веб-сервером, но и удостоверить организацию, которой принадлежит сайт. В сегодняшнем материале мы посмотрим, какие виды сертификатов бывают и коснемся вопросов их получения.
/ Flickr / montillon.a / CCВсе SSL-сертификаты используют одинаковые методы защиты данных. Для аутентификации применяются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Однако при этом они различаются по методу проверки: любой сертификат должен быть верифицирован центром сертификации, дабы удостовериться, что он принадлежит корректному и авторизованному сайту. Выделяют несколько видов сертификатов.
Первый тип сертификатов — это сертификаты с проверкой домена (Domain Validated). Они подходят для некоммерческих сайтов, поскольку подтверждают только обслуживающий сайт веб-сервер, на который осуществлён переход. DV-сертификат не содержит идентифицирующей информации в поле имени организации. Обычно там числится значение «Persona Not Validated» или «Unknown».
Для проверки лица запросившего сертификат центр сертификации высылает письмо на электронный адрес, связанный с доменным именем (например, admin@yourdomainname.com). Это делается для того, чтобы удостовериться, что лицо, запросившее сертификат, действительно является владельцем доменного имени. Компании Google не нужно доказывать общественности, что www.google.com принадлежит ей, поэтому она вполне может использовать простые сертификаты с проверкой домена (однако ИТ-гигант все равно использует OV-сертификаты, о которых далее).
Другие варианты верификации — добавление TXT-записи в DNS или размещение на сервере специального файла, который может быть прочитан CA. Этот вид сертификата самый дешевый и популярный, но не считается полностью безопасным, поскольку содержит информацию лишь о зарегистрированном доменном имени. Поэтому они часто используются для защиты во внутренних сетях или на небольших веб-сайтах.
Второй тип сертификатов носит название Organization Validated, или сертификаты с проверкой организации. Они более надежны, по сравнению с DV, поскольку дополнительно подтверждают регистрационные данные компании-владельца онлайн-ресурса. Всю необходимую информацию компания предоставляет при покупке сертификата, а CA затем напрямую связывается с представителями организации для её подтверждения.
Третий тип — это Extended Validation, или сертификат с расширенной проверкой, который считается самым надежным. Впервые появился в 2007 году и нужен веб-сайтам, которые проводят финансовые транзакции с высоким уровнем конфиденциальности. В этом случае целая адресная строка браузера будет выделяться зеленым цветом (поэтому их и называют «с зеленой строкой»). Плюс в зеленой области будет указано название компании.
О том, как разные браузеры информируют пользователей о наличии того или иного сертификата можно почитать тут.
Отметим, что если для совершения платежей и обработки транзакций пользователь перенаправляется на сторонний сайт, подтверждённый сертификатом с расширенной проверкой, то в этом случае хватит обычных сертификатов OV.
EV-сертификаты полезны, если необходимо «жестко» связать домен с физической организацией. Например, Bank of America и домен bankofamerica.com. В этом случае сертификат с проверкой организации гарантирует, что ресурс действительно принадлежит банку, куда пользователь может физически занести свои деньги — это как минимум удобно для пользователей.
Более того, EV-сертификаты защищают от атак с использованием фишинговых сайтов, как это было в случае с Mountain America Credit Union. Злоумышленники сумели получить легальный SSL-сертификат для копии сайта кредитной организации. Дело в том, что банк использовал доменное имя macu.com, а атакующие использовали имя mountain-america.net и при подаче заявки «вывесили» невинно выглядящий сайт. После получения сертификата сайт был заменен на фишинговый ресурс. EV-сертификаты серьезно затрудняют выполнение подобного «фокуса» — как минимум адрес виновника становится сразу известен.
Выдавая сертификаты типа OV или EV, сертификационный центр должен убедиться, что компания, получающая сертификат, действительно существует, официально зарегистрирована, имеет офис, а все указанные контакты — рабочие. Оценка организации начинается с проверки её официальной государственной регистрации. На территории России это выполняется с помощью реестра юридических лиц, представленного на сайте ФНС.
После получения заявки на сертификат, CA присылает бланки с вопросами об организации, которые нужно заполнить и подписать. Свои подписи и печати ставят руководитель компании и главный бухгалтер. После чего отсканированные документы отправляются обратно в центр сертификации, где их проверяют по идентификаторам ЕГРЮЛ и ИНН.
Если предоставленные данные полностью удовлетворяют сотрудников сертификационного центра, то выдается сертификат. Если же потребуется провести легализацию документов, то придется отправить по электронной почте в центр сертификации отсканированные изображения запрошенных документов.
Предварительно стоит уточнить, требуется ли перевод этих документов и нотариальное удостоверение перевода, а также требуется ли удостоверение нотариуса апостилем. Вместо апостиля для подтверждения полномочий нотариуса, можно сообщить центру сертификации соответствующую ссылку на сайте Федеральной нотариальной палаты. И перевод, и нотариальные услуги, и апостиль потребуют некоторых дополнительных расходов и организационных усилий, поэтому до подтверждения необходимости этих действий центром сертификации заниматься ими не стоит.
CA могут выдавать EV-сертификаты и государственным учреждениям, однако последние должны удовлетворять ряду требований. Во-первых, существование организации должно подтверждаться административно-территориальным образованием, в котором она оперирует. Во-вторых, организация не должна находиться в стране, где запрещена деятельность CA, выдающего сертификат. Также сама государственная структура не должна быть представлена в каком-либо из перечней запрещенных организаций.
При этом отметим, что также существуют международные агентства, которые могут проверять официальные документы компании и выступать удостоверителем её законного существования. Наиболее известным из таких агентств является Dun & Bradstreet. После проверки организации D&B выдаёт цифровой идентификатор — DUNS (Digital Universal Numbering System) — на который можно ссылаться для подтверждения легальности организации.
Оформление SSL-сертификата типа OV или EV потребует от организации, желающей его получить, некоторых расходов. Однако результатом всех затраченных усилий станет повышение репутации и уровня доверия клиентов к организации в интернете.
Цепочки сертификатов
Вообще, чтобы зашифровать данные, пересылаемые между веб-сервером и браузером пользователя, достаточно одного сертификата. Однако, если посмотреть на путь сертификации ресурса google.ru, можно увидеть, что их целых три.
При посещении многих сайтов, например, банков или железнодорожных касс, пользователи хотят уверенными не только в том, что соединение защищено, но и в том, что открывшийся сайт — правильный. Для удостоверения этого факта одного сертификата недостаточно. Нужно, чтобы третья сторона (центр сертификации) подтвердила, что для защиты соединения используется сертификат, выпущенный именно для этого сайта.
Если некто «Б» удостоверил личность «А», и вы доверяете «Б», то проблема решена.
Если же вы не знаете «Б», то он может сообщить, что его знает «В».
Длина цепочки удостоверений не ограничена. Главное, чтобы в ней оказался тот, кому доверяет пользователь. Более того, исторически и технологически сложилось так, что ряд центров сертификации получили наибольшее признание в ИТ-области. Поэтому было принято согласованное решение назвать их криптографические сертификаты корневыми и всегда доверять таким подписям.
Перечень корневых центров сертификации и их публичных ключей хранится на компьютере пользователя. Если цепочку последовательно подписанных сертификатов завершает корневой сертификат, все сертификаты, входящие в эту цепочку, считаются подтверждёнными.
Другие виды сертификатов
Напоследок хотелось бы сказать, что помимо обозначенной градации сертификатов — DV, OV, EV — существуют и другие типы сертификатов. Например, сертификаты могут отличаться по количеству доменов, на которые они выдаются. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, указываемому при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, но за каждое наименование, включаемое в список сверх обозначенного количества, придется доплачивать отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать помимо доменов несколько поддоменов. В таких случаях стоит приобретать сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL. Отметим, что в этом случае можно также приобрести обычный мультидоменный сертификат, в котором просто указать необходимые поддомены.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого получается через любой генератор, например, бесплатный OpenSSL. Такие защищенные каналы связи можно с легкостью использовать для внутренних нужд компании: для обмена между устройствами сети или приложениями. Однако для использования на внешнем веб-сайте необходимо покупать официальный сертификат. В этом случае браузеры не будут показывать сообщения о небезопасном соединении, а будут спокойны за пересылаемые данные.
P.S. Несколько материалов по теме из нашего блога:
Поделиться с друзьями
Комментарии (34)
sotnikdv
28.07.2017 01:27-1Как пояснили в компании, решение связано с рядом инцидентов, не соответствующим высоким стандартам CA, — в частности, выдаче сертификатов без авторизации со стороны ИТ-гиганта.
Да ты что, прямо за то, что выдали кому-то сертификат без одобрения гугла? Вай-вай, какой гугл охреневший! Ваще обнаглел, решил, что он владычица морская и все ДЦ у него на посылках! Вай-вай! Забанил несчастный ДЦ, за то что тот имел наглость выдать сертификат кому-то без его авторизации. Упыри! Самоуправцы! Монополисты, проклятые!
А, стоп, оказывается WoSign выдали сертификат на имя GitHub, без авторизации GitHub? И расследование было публичное с участием Mozilla? А потом уже по результату гугл принял решение
Господа, вы бы писали менее желтушно.
grossws
28.07.2017 03:18Не сертификат, а precert 'ы засветившиеся в certificate transparency log. В том числе на гугловые адреса.
grossws
28.07.2017 03:34-1Первый тип сертификатов — это сертификаты с проверкой домена (Domain Validated). Они подходят для некоммерческих сайтов, поскольку подтверждают только обслуживающий сайт веб-сервер, на который осуществлён переход. DV-сертификат не содержит идентифицирующей информации в поле имени организации. Обычно там числится значение «Persona Not Validated» или «Unknown».
Обычно там вообще нет полей
o,ou,l,c.
Этот вид сертификата самый дешевый и популярный, но не считается полностью безопасным, поскольку содержит информацию лишь о зарегистрированном доменном имени. Поэтому они часто используются для защиты во внутренних сетях или на небольших веб-сайтах. Однако есть и исключения. Например, компании Google не нужно доказывать общественности, что www.google.com принадлежит ИТ-гиганту. Поэтому они используют простые сертификаты с проверкой домена (как и amazon.com).
Certificate: Data: Version: 3 (0x2) Serial Number: 6831279663967598973 (0x5ecd94a92423797d) Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Google Inc, CN = Google Internet Authority G2 Validity Not Before: Jul 19 11:55:57 2017 GMT Not After : Oct 11 11:31:00 2017 GMT Subject: C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c2:d1:c8:7a:f6:62:1e:71:c2:1c:29:f5:d3:61: d8:ae:59:14:b6:89:75:4f:8c:ce:a6:fa:ee:89:c1: 0d:2b:34:c6:94:cb:29:d9:e0:3e:e6:c4:bc:da:9c: e0:9a:bd:ec:20:08:ab:3e:9e:dd:7c:45:9e:64:64: ea:1f:13:67:5f:97:56:0c:9a:73:cb:0f:00:24:d9: 24:37:19:10:53:b2:5b:4a:44:e3:6d:a3:b5:1b:f4: 02:b9:13:d6:4d:f9:97:e0:f1:51:9f:c5:a7:6e:4f: 78:2a:13:7b:5e:94:f0:87:12:88:97:1d:f3:61:47: 4f:aa:49:73:21:83:7e:4a:5e:05:3d:10:84:93:2a: 8e:ed:a8:f3:a1:66:0f:34:a9:29:2a:22:d9:0f:1a: 44:6c:4c:e7:f2:c4:62:eb:ce:55:25:89:1f:2a:c5: 75:6e:86:1a:3f:71:04:21:33:47:a0:80:7c:35:ef: a8:e0:17:49:5a:b0:6e:ef:c6:6c:7d:a8:72:0b:2f: 1f:97:e7:1a:34:b0:9a:db:e0:3e:04:e3:1a:e6:18: 42:12:cb:95:43:01:2d:1f:82:ba:fb:23:37:8d:55: ac:a9:4f:36:66:cd:3f:6c:7b:f5:3b:4e:36:36:0d: 58:d0:38:7a:be:d2:f7:a0:15:0b:a8:93:41:26:c7: 38:e9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Alternative Name: DNS:www.google.com Authority Information Access: CA Issuers - URI:http://pki.google.com/GIAG2.crt OCSP - URI:http://clients1.google.com/ocsp X509v3 Subject Key Identifier: 8D:2E:25:9F:E5:C7:E5:26:3B:FE:30:21:51:29:D8:E1:5B:0D:70:3D X509v3 Basic Constraints: critical CA:FALSE X509v3 Authority Key Identifier: keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.11129.2.5.1 Policy: 2.23.140.1.2.2 X509v3 CRL Distribution Points: Full Name: URI:http://pki.google.com/GIAG2.crl Signature Algorithm: sha256WithRSAEncryption 65:b2:69:e3:c3:9d:da:3c:07:9f:68:cc:10:35:8b:ca:e8:a0: 58:14:75:a0:5f:89:f2:7b:43:90:1f:12:6e:f7:1c:c7:92:21: 93:e0:79:2e:32:56:55:bb:d4:1a:48:e5:0f:00:61:41:b6:94: bc:1b:94:3e:0c:a1:15:d3:29:b7:02:fa:60:9e:ce:1c:02:46: 43:08:dd:96:83:a2:0a:84:10:89:fd:aa:69:36:e6:62:ed:58: f1:a9:06:5f:1b:94:74:67:7b:2a:6b:66:bd:1e:88:77:f9:4d: e6:b9:ef:8f:dd:3e:bb:5c:3f:ec:71:32:6e:0c:ca:bc:83:ca: af:09:a8:6d:07:34:b0:a3:5f:16:d4:d7:70:c2:3a:2a:21:62: 54:b4:34:40:25:ec:7a:d7:d5:e1:13:03:11:c3:7a:44:d4:51: 2b:57:84:36:ae:d4:64:09:3b:65:7b:00:47:0f:10:7f:6b:b1: e4:85:b2:b3:27:04:80:25:7b:c2:04:ca:ac:b8:6d:34:f5:d4: fd:bc:40:00:01:0d:1f:a6:a8:f1:12:e2:59:3f:86:b0:27:90: 96:d1:7b:13:ba:f2:0f:05:d8:6c:39:d4:a6:71:6d:11:17:5c: 31:0f:b1:0f:ec:32:59:a8:9b:af:a5:92:48:9d:48:c8:46:86: 97:6a:93:bf
В общем, пишите статьи, так хоть разберитесь в том о чём пишите хотя бы минимально.
Для amazon.com полный дамп не привожу, но он тоже OV:
/C=US/ST=Washington/L=Seattle/O=Amazon.com, Inc./CN=www.amazon.com
nullemotion
30.07.2017 11:01Не вполне по теме, но раз уж тут упомянули LetsEncrypt.
Есть некий сайт, хостится дома, на условно белом ip. А-запись DNS размещена у Cloudflare. Когда LetsEncrypt пытается связаться с сайтом по ip для выдачи сертификата, Cloudflare отдаёт ему другой ip и всё идёт прахом — handshake failure. Как побороть?symbix
30.07.2017 23:57Самое простое — пройти валидацию через DNS, см. ACME DNS Challenge.
rkosolapov
31.07.2017 09:01+1Тут лучше таки разобраться с Cloudflare, и получить сертификаты для входных точек у них самих. Ибо коннект пользователя будет на CDN entry point, и сертификат нужен именно на тот домен.
grossws
31.07.2017 11:54Плюс, если вам нужен сертификат только для своего хоста, чтобы cf ходил по защищенному каналу — у них есть origin cert, который подписывают они сами.
symbix
Вы забыли упомянуть Letsencrypt, хотя статью начали с WoSign/StartSSL, которые известны прежде всего бесплатными сертификатами. :-)
povargek
Использую Let's encrypt уже вполне давно, полет нормальный.
neonox
Ну Вы же понимаете, что компании, в том числе, занимающейся продажей SSL-сертификатов это экономически невыгодно.
1cloud
Коллега, экономического заговора здесь нет. Мы просто стараемся делиться чем-то полезным.
Действительно, один из вариантов получения SSL-сертификатов — воспользоваться бесплатными сервисами. Как верно заметил symbix, мы упомянули WoSign, например. Однако, будем честны, применимость бесплатных сертификатов ограничена — далеко не все компании готовы ими пользоваться.
Finesse
Какова причина?
Gasaraki
Сложность настройки и поддержки автообновлений сертификатов и отслеживание мест где он не обновился. Плюс специфичный софт в который просто так сертификат не пропишешь. Т.е. если у тебя будет где-то сбоить обновление — на это уйдут затраты времени работника при разборе проблемы. В этом случае проще и дешевле будет купить сертификат на 5-10 лет и вспоминать про его обслуживание только в конце срока действия.
pred8or
С долгосрочными сертификатами есть немалая вероятность забыть о необходимости его обновления, если отсутствуют процедуры напоминания. А это чревато внезапной неработоспособностью массы приложений, которые их используют. Так что краткосрочный сертификат от того же Let's Encrypt при правильно настроенной процедуре обновления убирает этот риск.
Есть ещё и другие риски долгосрочных сертификатов
1cloud
Это несомненно так, но хорошо, что есть выбор из разных вариантов — каждый может пользоваться тем, что удобнее для него
Gasaraki
Если у вас унифицированая инфраструктура с небольшим набором систем, то в летсенкрипт смысл есть (т.е. например у вас только иис и windows server 2012r2 или там RHEL7 со стандартным набором пакетов). Но если у вас например холдинг компаний разработчиков, где набор разномастных систем которые смотрят наружу (win2003/2008/2012к2+iis, vpn'ы разные, rdpaps, S4B, разных кастомизированных линухов вобще можно не считать) просто зашкаливает и небольшой инженерный отдел, то по трудозатратам на внедрение и поддержку лучше наиболее долгоиграющие сертификаты (в идеале лет на 10) — получил сертификат, воткнул, завел в мониторинг, забыл про систему до момента заявки. Реальная экономия времени на раскуривание — а какой готовый скрипт летсэнкрипта в данной системе заработает и не отвалится ли он скажем через год, два, три (у меня например отвалился через пол года после автоматического обновления скрипта автопродления) и если отвалится — его все равно придется чинить либо вам либо другому человеку. Чтобы не забыть про сроки — воткнуть в тот-же заббикс проверку срока в готовый шаблон.
Долгоиграющий сертификата имеют еще один плюс — если он реально на большой срок, то скорее всего бизнес уже в какой-то момент перестроится и вам еще раз придется их внедрять уже в новые системы. И проще опять же внедрить либо его либо купить новый долгоиграющий, чем опять разбираться в готовых скриптах (вы же не будете писать его сами).
Не надо краткосрочные сертификаты возводить в абсолют, они конечно бесплатны, по идее более безопасны и для многих проектов прекрасно подойдут. Но вот затраты времени на их внедрение и поддержку это весьма неоднозначно. Стоимость 1 дня работы инженера гораздо больше чем 1 сертификат на 5-10 лет установленный 1 раз за 10 минут.
symbix
И чем же платный DV-сертификат отличается от бесплатного?
grossws
Некоторые настолько не готовы, что предпочитают самоподписанные сертификаты, и предлагают пользователям ставить из root ca. Это вообще за гранью, но такова реальность.
symbix
Вот именно поэтому letsencrypt — это отлично. Хватит уже воздухом торговать. Выдача DV не стоит почти ничего. Цена даже в 10-15 рублей окупит затраты на сервер, запускающий openssl в автоматическом режиме. По сути, торговля воздухом. А тут-то вообще перепродажа воздуха, зарегистрировались партнером и все, затрат вообще ноль. Польза только в том, что налоги плятят :-)
Alexsandr_SE
letsencrypt работает, но менять сертификат каждые три месяца и нет (или не нашел) как поддомен поставить и как с винды нормально взять сертификат.
symbix
Сертификат меняется автоматически, вот список клиентов: https://letsencrypt.org/docs/client-options/ — наверняка под виндой что-то из них да работает. С субдоменами — если достаточно фиксированного списка, то можно прописать сотню с лишним altName-ов, если нужны wildcard — обещают в январе.
9660
Если бы letsencrypt выдавал сертификаты на 5-10 лет то это было бы отлично. Но, как я понял, это в корне противоречит всей их идее.
Поэтому, спасибо конечно, но воспользуемся услугами других.
Но про торговлю воздухом (DV-сертификаты) полностью согласен. За такое деньги если и брать то чисто символические.
rkosolapov
1. https://letsencrypt.org/2015/11/09/why-90-days.html
2. «CAB Forum Ballot 193, which was proposed by Entrust, will place a new limit on maximum lifetime for all publicly trusted SSL certificates. The new limit will be 825 days – that’s two years with some padding built in to allow for renewal and replacement – and will come into effect on March 1st of 2018.
Currently, the maximum SSL certificate validity period is 3 years (39 months to be exact), and CAs will continue to issue such certificates until the new ballot comes into effect.»
9660
Невероятно. Думал ничто их не прошибет. Неужели дождемся и сертификатов на 10 лет?
rkosolapov
Эмм, не понял, откуда следует радость и ожидание появления сертификатов на 10 лет.
Форум сократил максимальный лайфтайм с трёх лет до двух лет. Изначально хотели сократить до года, но там какие-то интересные кейзы вылезли (не разбирался), и чтобы долго не спорить, сошлись на двух годах.
Тенденция к сокращению лайфтайма есть, и она правильная, ибо сертификаты должны быть довольно короткие, по причинам, изложенным в документе от let's encrypt. И если причину секурити можно (и даже нужно) побеждать всякими oscp, hpkp, dane etc, то вторую причину (давление на автоматизацию реньювала) никуда не денешь. А отсутствие автоматизации настолько угроза для всей системы TLS, что если грубо не давить на общество, форсируя эту самую автоматизацию, то развал всей системы видится очень так неиллюзорно и в довольно краткосрочной перспективе (пяток лет).
9660
Тогда жопа. Надежды на развал такой системы автоматизации мало.
А можно раскрыть мысль про развал системы TLS по причине отсутствия автоматизации?
rkosolapov
На данный момент индустрия может бороться с атаками только усложнением процедур. Чем процедура сложнее — тем её сложнее делать человеку, соответственно, без автоматизации либо это не будут делать (у скольки людей настроен и работает hpkp? «работает» — это когда можно не бояться окончания срока действия сертификата и когда можно отозвать сертификат без проблем с клиентами, учитывая все кешинги, CDN-ы и подобные вещи), либо будут делать с ошибками (типичный пример — hsts).
Одной из проблем всей системы является централизация, то есть вот те самые корневые CA, которым договорились доверять. Уже сейчас это реально проблема как со стороны секурити (собственно, dane, hpkp, ocsp stapling и так далее одной из причин имеют ту самую централизацию), так и со стороны хайлоада. Одной из основных нерешённых вещей является процедура отзыва сертификата (вероятность компрометации приватного ключа вовсе не такая уж маленькая, как многие думают, а текущая тенденция всё виртуализировать/контейнезировать только повышает её), короткий лайфтайм — это попытка решить эту проблему наиболее простым способом.
9660
Интересно было прочесть.
Вот только, разве, при обновлении сертификата у LE меняется первичный ключ?
rkosolapov
Let's Encrypt не имеет никакого отношения к приватному ключу. Как и всегда, приватный ключ (да и CSR целиком, да и коммуникации по ACME-протоколу, ибо приватный ключ никогда не должен покидать той машины, на которой он генерился, то есть если ты что-то подописываешь, то должен это делать на той машине, на которой генерил ключ) должен генериться на том сервере, с коротого происходит запрос на выписку сертификата.
1. https://letsencrypt.org/how-it-works/
2. https://letsencrypt.org/docs/faq/ + поиск по слову private key
При желании можно использовать приватный ключ повторно, но единственная причина так делать — отсутствие автоматизации. Ну и естественно это ухудшает безопасность — если мы постоянно используем один и тот же ключ, посылая пакетики известной структуры, то сложность взлома шифрования уменьшается.
9660
О чем и речь. Автоматизация сама по себе мало чем поможет от компроментации приватного ключа.
Все снова упирается в того кто настраивает.
Ну да ладно, это все лирика.
grossws
Ещё letsencrypt с 2018 собирается выдавать wildcard, что ещё подрежет рынок
grossws
https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html кому интересно