> Внутри все будет работать как есть, а внешних получателей вы вряд ли уговорите доверять вашему ЦС
это зависит от того, что мы понимаем под «внешними» клиентами. Это мобильные/домашние устройства сотрудников (которые за периметром сети являются внешними уже) или просто посторонние клиенты. В первом случае уговорить можно.
> На exchange стоит сертификат, выписанный для exchange.name.local
выпишите ему сертификат на name.com, т.е. на имя, которое может быть разрешено как изнутри, так и снаружи. Как правило, сертификат выдаётся на внешнее имя сервера, для внутренних клиентов подключение по этому имени разрешается через DNS. Т.е. если надо, создаёте зону для внешнего домена (если нету) и для публичного имени сервера делаете указатель на внутренний адрес сервера.
> Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут.
то же самое. Выписывайте сертификаты на внешние имена и почтовые адреса.
По порядку:
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 обязательно опубликуют скоро. Другой момент вызван исключительно практическими соображениями. Нет смысла мониторить отдельно срок действия промежуточного ЦС и обновлять часто. Подходит к концу срок действия издающего ЦС — обновили сразу всё и корневой ЦС и издающий.
С опытом мы пришли к этому. Что касается «windows shops», в нынешнем гетерогенном мире — это утопия. Достаточно заиметь телефон с андроидом или iOS и здрасьте-приехали, они про этот LDAP ничего не знают. Поэтому мы с Брайаном проповедуем максимальную совместимость с различными клиентскими платформами, а в текущем контексте эта совместимость обеспечивается только транспортом HTTP.
Что касается книги, Брайан собирался её актуализировать до 2012 сервера, но написать и качественно переработать книгу (а она немаленькая) — это не за хлебушком сходить, труд титанический. А с учётом темпов развития технологий, многие книги устаревают уже на стадии черновиков. Я сам желал бы обновления книги, но шансов на успех тут мало по объективным причинам.
К сожалению, нет индустриальных стандартов на эту тему. Даже поведение кэша нигде не формализовано. То, что я написал про E-tag и Max-Age, pre-fetch это справедливо только для платформ Microsoft Windows и приложений, использующих CryptoAPI для проверки сертификатов, включая .NET Framework (на счёт .NET Core не уверен). И то, это не стандарт (как RFC), а внутренняя спецификация.
Проверка отзыва — это строго прерогатива клиента, следовательно, на сервере ничего нельзя сделать. Клиент сам решает, хочет он проверять сертификат на отзыв или нет. В частности, современные браузеры (Google Chrome, FireFox) проверяют на отзыв только сертификаты Extended Validation (EV, с зелёнкой). Internet Explorer и Edge проверяют сертификаты на отзыв, но тихо пропускают, если актуальная информация об отзыве недоступна. А тот же клиент VPN SSTP не даёт подключиться к серверу, если отзыв сертификата нельзя проверить. Как-то так.
LDAP быть вообще не должно, только HTTP. Я во второй части (жду публикации) сделал сноску на статью в моём блоге, которая более подробно разъясняет принципы планирования ссылок CDP/AIA.
> исполнения откладывается на пару десятков секунд
Это означает, что список отзыва и/или сертификаты промежуточных ЦС недоступны. Но этот вопрос лучше адресовать на профильных форумах.
Оно не плохо, оно очень накладно. Это и значительный простой PKI между процессом изъятия их эксплуатации скомпрометированного ЦС и введением в работу нового. Придётся ещё выяснять как это случилось и принимать меры, чтобы это не повторилось. Второй момент заключается в том, что корневой сертификат часто установлен не только в домене, но и на множестве мобильных устройств, к которым немедленный доступ получить не так легко. И этот сертификат нужно удалять со всех устройств. В теории выглядит легко «ну мы сейчас на MDM всё сделаем за минуту». Из опыта скажу, что при попытке реализовать это в реальной жизни, сразу возникает множество проблем. Плюс, есть ещё корпоративная бюрократия добавляет хлопот.
Это не совсем так. Начиная с Windows Vista, при скачивании CRL по HTTP, клиент CryptoAPI руководствуется следующими заголовками HTTP: E-tag и Cache-Control. Так же, клиент использует функцию pre-fetch. Таким образом, клиент узнает об отзыве гораздо быстрее, в течении нескольких дней даже при 6-месячном CRL. Т.е. клиент периодически проверяет есть ли обновление у CRL на сервере (за счёт E-tag) без скачивания самого списка отзыва. Эти моменты подробно расписаны в этой статье: How Certificate Revocation Works.
это зависит от того, что мы понимаем под «внешними» клиентами. Это мобильные/домашние устройства сотрудников (которые за периметром сети являются внешними уже) или просто посторонние клиенты. В первом случае уговорить можно.
выпишите ему сертификат на name.com, т.е. на имя, которое может быть разрешено как изнутри, так и снаружи. Как правило, сертификат выдаётся на внешнее имя сервера, для внутренних клиентов подключение по этому имени разрешается через DNS. Т.е. если надо, создаёте зону для внешнего домена (если нету) и для публичного имени сервера делаете указатель на внутренний адрес сервера.
> Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут.
то же самое. Выписывайте сертификаты на внешние имена и почтовые адреса.
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 обязательно опубликуют скоро. Другой момент вызван исключительно практическими соображениями. Нет смысла мониторить отдельно срок действия промежуточного ЦС и обновлять часто. Подходит к концу срок действия издающего ЦС — обновили сразу всё и корневой ЦС и издающий.
Что касается книги, Брайан собирался её актуализировать до 2012 сервера, но написать и качественно переработать книгу (а она немаленькая) — это не за хлебушком сходить, труд титанический. А с учётом темпов развития технологий, многие книги устаревают уже на стадии черновиков. Я сам желал бы обновления книги, но шансов на успех тут мало по объективным причинам.
Проверка отзыва — это строго прерогатива клиента, следовательно, на сервере ничего нельзя сделать. Клиент сам решает, хочет он проверять сертификат на отзыв или нет. В частности, современные браузеры (Google Chrome, FireFox) проверяют на отзыв только сертификаты Extended Validation (EV, с зелёнкой). Internet Explorer и Edge проверяют сертификаты на отзыв, но тихо пропускают, если актуальная информация об отзыве недоступна. А тот же клиент VPN SSTP не даёт подключиться к серверу, если отзыв сертификата нельзя проверить. Как-то так.
Это означает, что список отзыва и/или сертификаты промежуточных ЦС недоступны. Но этот вопрос лучше адресовать на профильных форумах.