Перевыпускаем сертификат с SHA-2 — если Webnames не идет к Магомету…
- вторник, 11 ноября 2014 г. в 02:10:58
geektimes
http://habrahabr.ru/post/242799/
Как было объявлено 5 сентября 2014 года, разработчики браузера Chromium уже не очень жалуют алгоритм хеширования SHA-1. Сам вид адресной строки браузера будет давать понять посетителям https-сайтов, «закрытых» такими сертификатами, что с сайтом что-то «не те». Вид строки будет меняться со временем, давая время для более-менее плавного перехода, а в конце сертификаты с SHA-1 перестанут считаться вообще сколько-нибудь безопасными:
В результате, все браузеры на основе Chromium (в том числе и Google Chrome) перестанут поддерживать SHA-1. Эту инициативу Google поддержали Mozilla и Microsoft. Chrome должен начать показывать «особое отношение к SHA-1» с версии 39, которую ждем в конце ноября 2014 г.
У нас в компании в служебных веб-интерфейсах использовался wildcard-сертификат, выпущенный как раз с использованием SHA-1. Покупался он у WebNames.ru (они же — ООО «Регтайм»), так что с вопросом, как перевыпустить тот же сертификат, но уже с SHA-2, мы обратились в техподдержку Регтайм.
Ответ был краток:
«Ого,» — подумали мы, — «обидно как-то!» Подумали-подумали, и вспомнили, что Webnames сертификаты создает не сам, а заказывает их на стороне, в нашем случае — у RapidSSL (они же GeoTrust). Написали уже в их техподержку — и, о чудо, все наши проблемы решились быстро и безболезненно.
Итак, вот что мы узнали: сертификат перевыпускается безо всякой дополнительной оплаты путем повторной загрузки CSR и выбора SHA-2 в качестве хеширующего алгоритма в веб-панели заказа сертификата на сайте GeoTrust. А платным либо бесплатным окажется (пере-)выпуск сертификата, определяют лишь данные в CSR: если они совпадают с данными сертификата, который уже заказывался клиентом, то никакой оплаты не будет взыматься.
А теперь хитрость: данные в CSR, подаваемом Регтаймом для своих клиентов, вовсе не напоминают какие-либо данные самого клиента. Вот какие поля Регтайм использует, и что нужно указать, чтобы через GeoTrust перевыпустить сертификат с SHA-2 бесплатно:
(неплохо так у них со скромность, не находите?)
Итого, создаем новый CSR с этими данными (поле Common name, естественно, должно содержать имя домена, для которого мы перевыпускаем сертификат):
загружаем его в разделе "Self Service Reissuance" сайта GeoTrust, и получаем то, что хотели — новый сертификат.
Как вывод — не всегда стоит верить отрицательным ответам техподдержки (тем более что Webnames, по опыту, вообще довольно часто любят отвечать «нет»), а стоит включать голову и решать свои проблемы напрямую. Спокойнее выйдет!
Как было объявлено 5 сентября 2014 года, разработчики браузера Chromium уже не очень жалуют алгоритм хеширования SHA-1. Сам вид адресной строки браузера будет давать понять посетителям https-сайтов, «закрытых» такими сертификатами, что с сайтом что-то «не те». Вид строки будет меняться со временем, давая время для более-менее плавного перехода, а в конце сертификаты с SHA-1 перестанут считаться вообще сколько-нибудь безопасными:
В результате, все браузеры на основе Chromium (в том числе и Google Chrome) перестанут поддерживать SHA-1. Эту инициативу Google поддержали Mozilla и Microsoft. Chrome должен начать показывать «особое отношение к SHA-1» с версии 39, которую ждем в конце ноября 2014 г.
У нас в компании в служебных веб-интерфейсах использовался wildcard-сертификат, выпущенный как раз с использованием SHA-1. Покупался он у WebNames.ru (они же — ООО «Регтайм»), так что с вопросом, как перевыпустить тот же сертификат, но уже с SHA-2, мы обратились в техподдержку Регтайм.
Ответ был краток:
Такой возможности, к сожалению, нет. Это бует уже заказ _нового_ сертификата.
«Ого,» — подумали мы, — «обидно как-то!» Подумали-подумали, и вспомнили, что Webnames сертификаты создает не сам, а заказывает их на стороне, в нашем случае — у RapidSSL (они же GeoTrust). Написали уже в их техподержку — и, о чудо, все наши проблемы решились быстро и безболезненно.
Итак, вот что мы узнали: сертификат перевыпускается безо всякой дополнительной оплаты путем повторной загрузки CSR и выбора SHA-2 в качестве хеширующего алгоритма в веб-панели заказа сертификата на сайте GeoTrust. А платным либо бесплатным окажется (пере-)выпуск сертификата, определяют лишь данные в CSR: если они совпадают с данными сертификата, который уже заказывался клиентом, то никакой оплаты не будет взыматься.
А теперь хитрость: данные в CSR, подаваемом Регтаймом для своих клиентов, вовсе не напоминают какие-либо данные самого клиента. Вот какие поля Регтайм использует, и что нужно указать, чтобы через GeoTrust перевыпустить сертификат с SHA-2 бесплатно:
Organization:
Regtime
Organizational unit:
Regtime
City/locality:
Samara
State/province:
Samara
Country:
RU
(неплохо так у них со скромность, не находите?)
Итого, создаем новый CSR с этими данными (поле Common name, естественно, должно содержать имя домена, для которого мы перевыпускаем сертификат):
openssl req -new -newkey rsa:4096 -sha512 -nodes -keyout www-example-com.pem -out www-example-com.csr
загружаем его в разделе "Self Service Reissuance" сайта GeoTrust, и получаем то, что хотели — новый сертификат.
Как вывод — не всегда стоит верить отрицательным ответам техподдержки (тем более что Webnames, по опыту, вообще довольно часто любят отвечать «нет»), а стоит включать голову и решать свои проблемы напрямую. Спокойнее выйдет!