Комментарии 11
Crypt32 пользуясь случаем опять позадаю дурацкие вопросы:
1. Так ли нужен RSA 4096 для промежуточного ЦС и все ли устройства научились его понимать?
2. Есть ли какие-то противопоказания у удаления из базы отозванных сертификатов после истечения срока действия через certutil -deleterow 01.01.2018 cert? КМК, в этом случае можно обойтись без Delta CRL при разумном сроке действия конечных сертификатов.
3. В сроках действия сертификатов (Root CA = Issuing CA) нет ошибки? Или нет смысла заморачиваться с half-life renewals, как описано на слайде?
1. Так ли нужен RSA 4096 для промежуточного ЦС и все ли устройства научились его понимать?
2. Есть ли какие-то противопоказания у удаления из базы отозванных сертификатов после истечения срока действия через certutil -deleterow 01.01.2018 cert? КМК, в этом случае можно обойтись без Delta CRL при разумном сроке действия конечных сертификатов.
3. В сроках действия сертификатов (Root CA = Issuing CA) нет ошибки? Или нет смысла заморачиваться с half-life renewals, как описано на слайде?
Half-life renewals with same key
По порядку:
1) Не сильно принципиально, 2048 или 4096. Тут дело какое: для ЦС мы делаем сертификат на 15 лет. Кто знает, что случится к этому моменту? Может, уже 2048 похоронят, как похоронили 1024. То, что там по ссылке упоминали про оборудование Cisco, иногда ещё упоминают про Nortel — это дикая древность. Плюс, для Cisco был выпущен патч, чтобы понимать 4096-бит RSA ключи. Более того, мы говорим не про генерацию, а всего лишь про проверку подписей такими ключами. Вряд ли сейчас можно найти такое приложение или устройство, которое бы не сумело прочитать 4к ключ.
2) есть. Это касается сертификатов для цифровых подписей. Если они были отозваны, они должны навечно остаться в списке отзыва (из-за особенностей таймстампов в подписях). И вообще, удаление активных записей из БД (которые со статусом Issued или Revoked) — это очень плохо. Например, для нового профиля OCSP, который описан в RFC6960 есть нововведение, по которому OCSP не может дать утвердительный ответ для сертификата, который не был издан конкретным ЦС. Удалять можно запросы со статусом Pending или Failed.
Но есть мнение, что Delta CRL не нужны совсем, но я пока не готов сказать, правильно это или нет. На момент написания статьи я считаю, что они нужны. Без хороших данных с телеметрии трудно о говорить о чём-либо конкретном. Главное возражение против них (а других и нет) — повальные ошибки сертификатов, если ЦС внезапно умрёт и не успеет продлить списки отзыва. С недельным Base CRL ещё можно перекантоваться и успеть починить ЦС, с суточными дельтами будет хуже. Но это уже вопрос к disaster recovery.
3) ошибки нет, всё правильно. Срок действия корневого ЦС равен сроку действия издающего ЦС. Half-life renewals — это архаизм и ещё обладает рядом побочных эффектов, когда ошибочно выбирается не тот корневой сертификат и всё разваливается. Т.е. обновление всегда с новым ключом, никаких секонд-хендов. Точка. Я об этом более подробно расписал в третьей части, которую ребята из Microsoft обязательно опубликуют скоро. Другой момент вызван исключительно практическими соображениями. Нет смысла мониторить отдельно срок действия промежуточного ЦС и обновлять часто. Подходит к концу срок действия издающего ЦС — обновили сразу всё и корневой ЦС и издающий.
1) Не сильно принципиально, 2048 или 4096. Тут дело какое: для ЦС мы делаем сертификат на 15 лет. Кто знает, что случится к этому моменту? Может, уже 2048 похоронят, как похоронили 1024. То, что там по ссылке упоминали про оборудование Cisco, иногда ещё упоминают про Nortel — это дикая древность. Плюс, для Cisco был выпущен патч, чтобы понимать 4096-бит RSA ключи. Более того, мы говорим не про генерацию, а всего лишь про проверку подписей такими ключами. Вряд ли сейчас можно найти такое приложение или устройство, которое бы не сумело прочитать 4к ключ.
2) есть. Это касается сертификатов для цифровых подписей. Если они были отозваны, они должны навечно остаться в списке отзыва (из-за особенностей таймстампов в подписях). И вообще, удаление активных записей из БД (которые со статусом Issued или Revoked) — это очень плохо. Например, для нового профиля OCSP, который описан в RFC6960 есть нововведение, по которому OCSP не может дать утвердительный ответ для сертификата, который не был издан конкретным ЦС. Удалять можно запросы со статусом Pending или Failed.
Но есть мнение, что Delta CRL не нужны совсем, но я пока не готов сказать, правильно это или нет. На момент написания статьи я считаю, что они нужны. Без хороших данных с телеметрии трудно о говорить о чём-либо конкретном. Главное возражение против них (а других и нет) — повальные ошибки сертификатов, если ЦС внезапно умрёт и не успеет продлить списки отзыва. С недельным Base CRL ещё можно перекантоваться и успеть починить ЦС, с суточными дельтами будет хуже. Но это уже вопрос к disaster recovery.
3) ошибки нет, всё правильно. Срок действия корневого ЦС равен сроку действия издающего ЦС. Half-life renewals — это архаизм и ещё обладает рядом побочных эффектов, когда ошибочно выбирается не тот корневой сертификат и всё разваливается. Т.е. обновление всегда с новым ключом, никаких секонд-хендов. Точка. Я об этом более подробно расписал в третьей части, которую ребята из Microsoft обязательно опубликуют скоро. Другой момент вызван исключительно практическими соображениями. Нет смысла мониторить отдельно срок действия промежуточного ЦС и обновлять часто. Подходит к концу срок действия издающего ЦС — обновили сразу всё и корневой ЦС и издающий.
Возможно я забегаю вперед, но все-таки — будет рассмотрена ситуация, когда домен у нас с «внутренним» именем типа name.local, а надо в нем ЦС для домена, например, name.ru разместить? Или может сразу в какую полезную (для дураков) статью на эту тему ткнете?
Имя домена тут вообще не играет никакой роли. И что такое «ЦС для домена xyz»?
ЦС- центр сертификации. Расширим.
1. есть домен name.local. В нем есть exchange. На exchange стоит сертификат, выписанный для exchange.name.local. Естественно у всех недоменных компьютеров проблема с подключением к нему. Хочется ее решить без переименования домена.
2. Хочется подписывать почту от пользователей их сертификатами. Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут. Хочется, чтобы могли.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
1. есть домен name.local. В нем есть exchange. На exchange стоит сертификат, выписанный для exchange.name.local. Естественно у всех недоменных компьютеров проблема с подключением к нему. Хочется ее решить без переименования домена.
2. Хочется подписывать почту от пользователей их сертификатами. Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут. Хочется, чтобы могли.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
> На exchange стоит сертификат, выписанный для exchange.name.local
выпишите ему сертификат на name.com, т.е. на имя, которое может быть разрешено как изнутри, так и снаружи. Как правило, сертификат выдаётся на внешнее имя сервера, для внутренних клиентов подключение по этому имени разрешается через DNS. Т.е. если надо, создаёте зону для внешнего домена (если нету) и для публичного имени сервера делаете указатель на внутренний адрес сервера.
> Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут.
то же самое. Выписывайте сертификаты на внешние имена и почтовые адреса.
выпишите ему сертификат на name.com, т.е. на имя, которое может быть разрешено как изнутри, так и снаружи. Как правило, сертификат выдаётся на внешнее имя сервера, для внутренних клиентов подключение по этому имени разрешается через DNS. Т.е. если надо, создаёте зону для внешнего домена (если нету) и для публичного имени сервера делаете указатель на внутренний адрес сервера.
> Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут.
то же самое. Выписывайте сертификаты на внешние имена и почтовые адреса.
Любой ЦС может выпускать сертификаты для любых доменов (есть Name Constraints, но им никто не пользуется).
Проблема возникнет лишь у клиентов из внешней сети с вашим сертификатов в доверенных и протухшим CRL, если CDP указывает на интранетовский name.local. Для её решения надо либо изменить CDP на доступный из интернета и настроить публикацию CRL (про это статья), либо поставить на name.ru нормальный сертификат от публичного CA.
Проблема возникнет лишь у клиентов из внешней сети с вашим сертификатов в доверенных и протухшим CRL, если CDP указывает на интранетовский name.local. Для её решения надо либо изменить CDP на доступный из интернета и настроить публикацию CRL (про это статья), либо поставить на name.ru нормальный сертификат от публичного CA.
есть меня сертификат для *.name.ru от Геотраст. Стоит на web-серверах. Непонятно как и можно ли его совместить с внутредоменной структурой, привяpанной к name.local.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
Внутри все будет работать как есть, а внешних получателей вы вряд ли уговорите доверять вашему ЦС и толку от такого S/MIME будет меньше, чем от TLS с DKIM на SMTP-сервере
А вот на Exchange ничего не мешает повесить сертификат от *.name.ru и прописать его в настройках коннекторов, возможно даже получится оставить старое имя для внутренних клиентов. Это описано в документации к Exchange.
А вот на Exchange ничего не мешает повесить сертификат от *.name.ru и прописать его в настройках коннекторов, возможно даже получится оставить старое имя для внутренних клиентов. Это описано в документации к Exchange.
> Внутри все будет работать как есть, а внешних получателей вы вряд ли уговорите доверять вашему ЦС
это зависит от того, что мы понимаем под «внешними» клиентами. Это мобильные/домашние устройства сотрудников (которые за периметром сети являются внешними уже) или просто посторонние клиенты. В первом случае уговорить можно.
это зависит от того, что мы понимаем под «внешними» клиентами. Это мобильные/домашние устройства сотрудников (которые за периметром сети являются внешними уже) или просто посторонние клиенты. В первом случае уговорить можно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка центра сертификации на предприятии. Часть 2