Веб-сертификат для Kerio connect и google chrome :: В помощь системному администратору :: Компьютерный форум Ru.Board

Перейти из форума на сайт.

Новости • Файловые архивы
Поиск • Активные темы • Топ лист
Правила • Кто в on-line?

Вход • Забыли пароль? • Первый раз на этом сайте? • Регистрация

Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Веб-сертификат для Kerio connect и google chrome

Модерирует : lynx, Crash_Master, dg, emx, ShriEkeR
Версия для печати • Подписаться • Добавить в закладки

Открыть новую тему

Написать ответ в эту тему

tgkonvent

Full Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

В домене есть ЦС, для Kerio Connect выписал веб-сертификат.
Если на рабочих станциях открыть https страничку к локальному почтовому серверу - то все открывается нормально
Если же тоже самое сделать в Google Chrome - то он ругается на то, что данное соединение не защищено и т.п.
Сертификат закодирован по формату PEM. На сайте гугля прочитал, что DER он не поддерживает.
Помогите разобраться - что надо еще ковырнуть для гугля хрома?

Всего записей: 438 | Зарегистр. 02-11-2005 | Отправлено: 11:20 09-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

https://www.emaro-ssl.ru/blog/sha1/
и
https://technet.microsoft.com/ru-ru/library/security/2880823.aspx

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 14:58 09-04-2018

tgkonvent

Full Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Перевыпустил корневой сертификат, перед этим сменил алгоритм шифрования на SHA256
по ссылке как советуют вот тут - http://www.bulygin.su/2016/04/sha1-sha256-windows-ca.html
Перевыпустил сертификат для почтовика. И все равно такая же ситуация (((

Всего записей: 438 | Зарегистр. 02-11-2005 | Отправлено: 16:05 09-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Перевыпустил, перевыпустил, проверил?
Можно же с клиента увидеть сертификат сервера, и во вкладке "Путь сертификации" просмотреть сертификат СА. Тыркунть там и увидеть Signature hash algorithm
sha1
Если SHA256, то смотрите причину, которую пишет Хром. Может он коревому СА не доверяет в принципе.

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 20:38 09-04-2018

tgkonvent Full Member	Редактировать \| Профиль \| Сообщение \| Цитировать \| Сообщить модератору Paromshick Проверил там сертифика с SHA256 Скорее всего не доверяет. Но тогда вопрос - где косяк? Как заставить его доверять этому сертификату?
	Всего записей: 438 \| Зарегистр. 02-11-2005 \| Отправлено: 20:49 09-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Пардон, что значит "скорее всего"? В ошибке всегда прямо указано, в данном случае должно быть "нет доверия к центру, выпустившему сертификат" или что-то созвучное. Смысл понятен. Нет доверия СА.

Цитата:

Как заставить его доверять этому сертификату?

Ну вы, блин, даете. А как раньше заставляли? Импортом сертификата СА в доверенные корневые локальной машины. Случай с AD DS иной, там автоматом, через CDP. Рестартуйте СA Service, дождитесь репликации

UPD. Как это барузер слово рестартуйте на расторгуйте поправил... Не заметил

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 21:00 09-04-2018 | Исправлено: Paromshick, 21:06 09-04-2018

Mavrikii

Platinum Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

tgkonvent

Цитата:

Скорее всего не доверяет

ну так прочитайте о причине, по которой браузер не доверяет - там же написано все.
например такое

Цитата:

NET::ERR_CERT_AUTHORITY_INVALID

когда самоподписанный сертификат, либо, как пример

Цитата:

NET::ERR_CERT_COMMON_NAME_INVALID

какую именно ошибку выдает браузер?

Всего записей: 15112 | Зарегистр. 20-09-2014 | Отправлено: 21:03 09-04-2018

tgkonvent

Full Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Mavrikii
NET::ERR_CERT_COMMON_NAME_INVALID

Paromshick
рестартовал - сам ЦС, тестовые станции тоже.
Вот тут самый интересный момент пока для меня, так как с ЦС работаю в первые. Если я выпустил новый корневой сертификат, а предыдуший так же присутствует. То, новые запросы на выдачу сертификатов будут подписаны уже новым корневым сертификатом. А, как быть с действительными по срокам предыдущим сертификатов клиентов? Они же по сроку как бы тоже действующие, но в тоже время их необходимо заменить на другие подписанные уже с SHA256. Пробовал отзывать сертификат и через прекращение работы, и через замену сертификата, но конечная станция не запрашивает новый сертификат. Может я что-то не допонял в ртфм от мелких по этой части?! Подскажите как правильно в такой ситуации надо отозвать ненужный действующий по срокам сертификат и чтобы станция запросила новый?

Всего записей: 438 | Зарегистр. 02-11-2005 | Отправлено: 06:46 10-04-2018

Mavrikii

Platinum Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

tgkonvent

Цитата:

NET::ERR_CERT_COMMON_NAME_INVALID

проблема не с корневым.
https://support.google.com/chrome/a/answer/7391219?hl=ru
https://productforums.google.com/forum/#!topic/chrome/JU7je3HmtfI

Всего записей: 15112 | Зарегистр. 20-09-2014 | Отправлено: 06:53 10-04-2018 | Исправлено: Mavrikii, 06:55 10-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Знаете, вы так славно пишете, что складывается впечатление, что вы сертификаты по пять раз на дню перевыпускаете. А потом вдруг выдаете пачку вопросов из книжки RTFM...
Так легко полезли действующий СА курочить, играючи. А вдуг ссылка так себе? Вот я хоть и добавил ее в мемориз, но не уверен. Я просто новый СА развернул, это пустяк. Но не суть. Тема вообще не об этом ни разу.
Я не сторонник заучивания конкретных кодов ошибок конкретных браузеров, т.к. не веб мастер. Есть отраслевые стандарты и их обычно достаточно.
Вы ошиблись в выпуске сертификата, не то имя указали. Это английским по белому написано.
И тема тогда MS Exchange server, как минимум. Если я правильно телепатировал модель вашего "почтовика". Начните с изучения матчасти, а клиентам придётся потерпеть несмертельную ошибку.

Добавлено:
Первый спойлер откройте и найдите вашу ошибку
https://support.microsoft.com/ru-ru/help/17430/windows-internet-explorer-certificate-errors-faq
хоть что-то будет прредметно. а вообще, вы ничего кроме Хром и Керио не сказали. Последний вообще не при делах, а первы так, постольку поскольку. Всё остальное "догадайся мол сама"

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 07:24 10-04-2018

tgkonvent Full Member	Редактировать \| Профиль \| Сообщение \| Цитировать \| Сообщить модератору Mavrikii Понятно! Все дело в том, что корневой сертификат самоподписанный ЦС
	Всего записей: 438 \| Зарегистр. 02-11-2005 \| Отправлено: 07:53 10-04-2018

Mavrikii

Platinum Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

tgkonvent

Цитата:

Понятно!

уверены, что прочитали и поняли?
сообщение говорит о том, что в сертификате нет поля SAN - https://en.wikipedia.org/wiki/Subject_Alternative_Name с DnsName или IP, а Хром требует его

Цитата:

В ОС Microsoft® Windows® можно создать самозаверенный сертификат в PowerShell с помощью командлета New-SelfSignedCertificate и добавить в него параметр DnsName.
В пакете OpenSSL альтернативное имя субъекта задается посредством расширения subjectAltName

Всего записей: 15112 | Зарегистр. 20-09-2014 | Отправлено: 07:57 10-04-2018 | Исправлено: Mavrikii, 07:59 10-04-2018

tgkonvent

Full Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Paromshick

Цитата:

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

)) Пришлось менять корневой сертификат с SHA1 на SHA256. Причина описана выше.
А, на счет перевыпуска сертификатов - это чисто интерес. Потому как читал теорию, на практике не сталкивался в локальном ЦС. Вот и задал вопрос людям, которые уже занимались этим

Цитата:

Так легко полезли действующий СА курочить, играючи.

Перед этим погуглил инет на тему смены корневого сертификата, что и как.

Цитата:

Вы ошиблись в выпуске сертификата, не то имя указали. Это английским по белому написано.
И тема тогда MS Exchange server, как минимум. Если я правильно телепатировал модель вашего "почтовика". Начните с изучения матчасти, а клиентам придётся потерпеть несмертельную ошибку.

Давайте тогда с самого начала. Требовался сертификат для https доступа к почтовому серверу. Т.е., чтобы можно было заходить в свои ящики через браузер. На сайте керио было написано, что нужен сертификат web-доступа.
А, сертификат по шаблону MS Exchange server, это совсем для других вещей.

Всего записей: 438 | Зарегистр. 02-11-2005 | Отправлено: 08:04 10-04-2018 | Исправлено: tgkonvent, 08:27 10-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Mavrikii
Я по ссылкам не ходил, но осуждаю))) Шутка. а как быть, если одно имя и всё. такое бывает. Ну, вот не надо больше. Зачем же subject alternate name? Чисто базу знаний расширить

Добавлено:
Посмотрел сейчас сертификаты монстров, типа тындекса с хухелем... Много нового, однако. У Google wildcard сертификат на имена четвёртого уровня. Раньше такое ни один браузер не воспринимал.
Интересно, почитать что ли...

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 08:07 10-04-2018

Mavrikii

Platinum Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Paromshick

Цитата:

если одно имя и всё. такое бывает. Ну, вот не надо больше. Зачем же subject alternate name?

https://tools.ietf.org/html/rfc6125
RFC 6125 (2011 года), о желательном переходе к SAN, с дублированием в CN для обратной совместимости. Гугль решил форсировать и требовать SAN вместо CN.

Цитата:

For the secondary audiences, in essence this document encourages
certification authorities, application service providers, and
application client developers to coalesce on the following practices:

o Move away from including and checking strings that look like
domain names in the subject's Common Name.

o Move toward including and checking DNS domain names via the
subjectAlternativeName extension designed for that purpose:
dNSName.

o Move toward including and checking even more specific
subjectAlternativeName extensions where appropriate for using the
protocol (e.g., uniformResourceIdentifier and the otherName form
SRVName).

o Move away from the issuance of so-called wildcard certificates
(e.g., a certificate containing an identifier for
"*.example.com").

These suggestions are not entirely consistent with all practices that
are currently followed by certification authorities, client
developers, and service providers. However, they reflect the best
aspects of current practices and are expected to become more widely
adopted in the coming years.

ps: проверил свои комодошные, там SAN с dnsName есть, а получал их несколько лет назад.

Всего записей: 15112 | Зарегистр. 20-09-2014 | Отправлено: 08:16 10-04-2018 | Исправлено: Mavrikii, 08:23 10-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Mavrikii

Цитата:

а получал их несколько лет назад

Если заказно несколько имен, то неудивительно, а наоборот - обязательно. Либо wildcard, но у него было ограничение: не выше имён третьего уровня. Да и дороже он был.
Удивительно то, что... а если у меня одно имя? Ну, не у меня, а некоего субъекта. Ему что, придумывать вымышленное второе?
Примем как есть.

PS Помешались на этих ssl, как мне кажется, и всё из-за АНБ. А что делать? Если ты не интересуешься политикой, то политика всё равно интересуется тобой

Молчу, молчу

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 09:04 10-04-2018

Mavrikii

Platinum Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:

Ну, не у меня, а некоего субъекта. Ему что, придумывать вымышленное второе?

прописать его и там и там.
в том же RFC сказано, что первым проверяется SAN, и если есть, то CN не проверяется вообще.

Всего записей: 15112 | Зарегистр. 20-09-2014 | Отправлено: 09:07 10-04-2018

Silver Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Хухоль красавчег. Решил флорсировать, а сам использует wildcard да еще четвертого уровня

Добавлено:

Цитата:

первым проверяется SAN, и если есть, то CN не проверяется вообще.

Движки делали иначе. И по мановению RFC они не меняются. Видимо, уже произошла ротация, ку примеру, ОС, если решено форсировать вопрос.
Маркетинг, сдается мне, не на последнем месте

Добавлено:
tgkonvent

Цитата:

Давайте тогда с самого начала. Требовался сертификат для https доступа к почтовому серверу. Т.е., чтобы можно было заходить в свои ящики через браузер. На сайте керио было написано, что нужен сертификат web-доступа. А, сертификат по шаблону MS Exchange server, это совсем для других вещей.

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

----------
Скучно

Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 09:07 10-04-2018

tgkonvent

Full Member

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Mavrikii
Огромная благодарность мил человек!
По вашей наводке разобрался и сделал. Пришлось самому создавать по реквест ключу от керио сертификат с добавлением SUB поля. Теперь все заработало.

Всего записей: 438 | Зарегистр. 02-11-2005 | Отправлено: 10:08 10-04-2018

Открыть новую тему

Написать ответ в эту тему

Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » Веб-сертификат для Kerio connect и google chrome

Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC