Windows центр сертификации: Установка центра сертификации | Microsoft Learn

Установка центра сертификации | Microsoft Learn

Twitter LinkedIn Facebook Адрес электронной почты

• Статья
• 09/21/2022
• Чтение занимает 3 мин

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Эту процедуру можно использовать для установки служб сертификатов Active Directory (AD CS), чтобы можно было зарегистрировать сертификат сервера на серверах, на которых выполняется сервер политики сети (NPS), служба маршрутизации и удаленного доступа (RRAS) или оба.

Важно!

• Перед установкой служб Active Directory сертификатов необходимо присвоить компьютеру имя, настроить компьютер со статическим IP-адресом и присоединить компьютер к домену. дополнительные сведения о том, как выполнить эти задачи, см. в разделе руководство по сети Windows Server 2016 Core.
• Для выполнения этой процедуры компьютер, на котором устанавливается AD CS, должен быть присоединен к домену, где установлена служба домен Active Directory Services (AD DS).

членство в группах «администраторы Enterprise

» и «администраторы домена корневого домена» является минимальным требованием для выполнения этой процедуры.

Примечание

чтобы выполнить эту процедуру с помощью Windows PowerShell, откройте Windows PowerShell и введите следующую команду, а затем нажмите клавишу ввод.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

После установки AD CS введите следующую команду и нажмите клавишу ВВОД.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Установка служб сертификатов Active Directory

Совет

если вы хотите использовать Windows PowerShell для установки Active Directory служб сертификации, см. раздел install-адксцертификатионаусорити для командлетов и необязательных параметров.

1. войдите в систему как член группы администраторов Enterprise и группы администраторов домена корневого домена.

2. Откройте диспетчер серверов, щелкните Управление, а затем нажмите кнопку Добавить роли и компоненты. Откроется мастер добавления ролей и компонентов.

3. На странице Перед началом работы нажмите кнопку Далее.

   Примечание

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

4. На странице Выбор типа установки убедитесь, что выбрана Установка ролей или компонентов, затем нажмите кнопку Далее.

5. На странице Выбор целевого сервера убедитесь, что выбран пункт Выберите сервер из пула серверов. На странице Пул серверов

   проверьте, что выбран локальный компьютер. Нажмите кнопку Далее.

6. В окне Выбор ролей серверав списке роливыберите Active Directory службы сертификации. Когда появится запрос на добавление необходимых компонентов, щелкните Добавить компоненты, а затем нажмите кнопку Далее.

7. В окне Выбор компонентовнажмите кнопку Далее.

8. В Active Directory службах сертификациипрочтите предоставленные сведения и нажмите кнопку Далее.

9. На странице Подтверждение выбранных элементов для установки нажмите кнопку Установить. Не закрывайте мастер в процессе установки. После завершения установки щелкните настроить Active Directory службы сертификатов на целевом сервере

   . Откроется мастер настройки служб сертификатов Active Directory. прочитайте сведения об учетных данных и при необходимости укажите учетные данные для учетной записи, которая является членом группы «администраторы Enterprise». Нажмите кнопку Далее.

10. В службах ролейщелкните центр сертификации, а затем нажмите кнопку Далее.

11. на странице тип установки убедитесь, что выбран параметр Enterprise CA , а затем нажмите кнопку далее.

12. На странице Укажите тип страницы ЦС убедитесь, что выбран параметр корневой ЦС , и нажмите кнопку Далее.

13. На странице Указание типа закрытого ключа убедитесь, что выбран параметр создать новый закрытый ключ

    , а затем нажмите кнопку Далее.

14. на странице шифрование для центра сертификации сохраните параметры по умолчанию для CSP (RSA # Software Key служба хранилища Provider) и хэш-алгоритм (SHA2) и определите максимальную длину символов ключа для развертывания. Большие ключевые длины символов обеспечивают оптимальную безопасность; Однако они могут повлиять на производительность сервера и могут быть несовместимы с устаревшими приложениями. Рекомендуется использовать значение по умолчанию 2048. Нажмите кнопку Далее.

15. На странице имя ЦС сохраните Предлагаемое общее имя ЦС или измените имя в соответствии с вашими требованиями. Убедитесь, что имя ЦС совместимо с соглашениями об именовании и целями, так как вы не можете изменить имя ЦС после установки служб AD CS.

    Нажмите кнопку Далее.

16. На странице срок действия в поле Укажите срок действиявведите число и выберите значение времени (годы, месяцы, недели или дни). Рекомендуется использовать значение по умолчанию, равное пяти годам. Нажмите кнопку Далее.

17. На странице база данных ЦС в поле укажите расположения базы данныхукажите расположение папки для базы данных сертификатов и журнала базы данных сертификатов. Если указаны расположения, отличные от расположений по умолчанию, убедитесь, что папки защищены с помощью списков управления доступом (ACL), которые не позволяют неавторизованным пользователям или компьютерам получать доступ к базе данных и файлам журналов ЦС. Нажмите кнопку Далее.

18. В окне Подтверждениенажмите кнопку настроить , чтобы применить параметры, а затем нажмите кнопку

    Закрыть.

Установка центра сертификации на предприятии. Часть 1 / Хабр

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Вторая часть серии

Третья часть серии

Введение

Целевая аудитория

ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа (ИОК), набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба, выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS
  (Transport Layer Security) — технология, обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, являющийся частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.

Зачем нужен частный PKI?

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет.

Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).

Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.

Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.

Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.

Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:

Если компания решает использовать частный PKI в пределах организации, встаёт другой насущный вопрос: как же правильно его организовать, чтобы он отвечал современным практикам и стандартам хотя бы в пределах организации. В интернете можно найти многочисленные статьи о том, как развернуть PKI в компании на основе Active Directory Certificate Services (ADCS). Но в большинстве своём они изобилуют ошибками, исходят из неверных предпосылок и нередко являются копированием какого-то исходного (не всегда удачного) материала, а к имеющимся фундаментальным ошибкам привносят ещё и свои. Как следствие, многочисленные провалы в развёртывании PKI. Об этом можно судить по количеству соответствующих тем на форумах (в частности, TechNet Server Security). Качественной документации на английском языке не хватает, а на русском… Этот цикл статей призван восполнить этот пробел и систематизировать современные наработки.
 

Общие положения

PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:

• Шифрование – защищает данные от несанкционированного доступа третьих лиц путём шифрования данных криптографическими ключами. Только пользователи, имеющие необходимые ключи, могут получить доступ к данным. Шифрование обеспечивает секретность данных, но не защищает от их подмены.
• Цифровая подпись – защищает данные от несанкционированного изменения или подделки путём применения к данным специальных алгоритмов, которые образуют цифровую подпись. Любые манипуляции по изменению данных будут немедленно обнаружены при проверке цифровой подписи. Цифровая подпись обеспечивает не конфиденциальность данных, а их целостность. Путём комбинирования шифрования и цифровой подписи можно организовать обеспечение конфиденциальности и защиты данных от несанкционированных изменений.

Типичная инфраструктура PKI состоит из следующих компонентов:

• Центр Сертификации (ЦС) – служба, предоставляющая цифровые сертификаты потребителям и обеспечивающая функционирование PKI.
• Сервер отзыва – служба, предоставляющая информацию о списках отозванных (скомпрометированных или недействительных) сертификатов, выпущенных конкретным ЦС.
• Клиент – получатель заверенного цифрового сертификата от центра сертификации. Клиентами могут выступать люди, устройства, программное обеспечение, а также другие ЦС.

Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:

• Корневой ЦС – специальный тип ЦС, который имеет самоподписанный сертификат и является корнем дерева (отсюда и название). Этот тип ЦС является стартовой точкой доверия ко всем сертификатам в данной иерархии (дерева). Иными словами, клиент должен явно доверять конкретному корневому сертификату (а именно, комбинации: издатель и открытый ключ), чтобы доверять сертификатам, находящимся в остальной части дерева. Важно отметить, что доверие транзитивно. Клиент при проверке конечного сертификата будет выстраивать цепочку (путь) от конечного сертификата до вершины иерархии (корневого сертификата). И если клиент доверяет вершине, то будут и основания доверять конечному сертификату на правах транзитивности.
• ЦС политик – технически, это такой же ЦС, как и все остальные (в разрезе иерархии), с тем отличием, что дополняется внешними политиками и ограничениями по выдаче и использования цифровых сертификатов.
• Издающий ЦС – это ЦС общего назначения, который выполняет подпись и выдачу цифровых сертификатов потребителям.

Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine — how it works. Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.

Поскольку ЦС выстраиваются в древовидную иерархию, возможно организовать многоуровневую иерархию, где на каждом уровне ЦС будет выполнять как роль издающего ЦС, так и дополнительные функции. В самом простом случае один ЦС может совмещать все роли, т.е. быть корневым, обеспечивать какие-то политики выдачи и выдавать сертификаты конечным потребителям. Более крупные компании и/или с более зрелой организацией ИТ-процессов уже используют разделение ЦС по ролям. Например, в головном офисе держат корневой ЦС, выдающий сертификаты только другим ЦС, которые уже на себе накладывают политики выдачи. Они могут не обслуживать напрямую конечных потребителей, а выдавать сертификаты другим подчинённым ЦС, которые, в свою очередь, и будут обслуживать конечных потребителей. В каждом подходе есть свои плюсы и минусы, которые будут рассмотрены ниже.

Отзыв сертификатов

Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. CRL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.

Каждый клиент после установки доверия сертификата через цепочку должен убедиться, что ни один сертификат в цепочке не был отозван своим издателем. Для этого клиент перебирает каждый сертификат в цепочке, выбирает CRL предоставленный издателем и проверяет наличие/отсутствие текущего сертификата в списке CRL. Если текущий сертификат находится в CRL, то доверие к сертификату (и всем ветвям дерева под ним) автоматически обрывается.

Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.

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

Типовые схемы развёртывания иерархии PKI

В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.

Одноуровневая иерархия

Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:

Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.

Однако одноуровневая иерархия обладает рядом достаточно существенных недостатков. Самый крупный из них – низкий уровень безопасности. Поскольку ЦС в такой схеме должен быть постоянно включенным в сеть, чтобы клиенты могли запрашивать сертификаты, значительно увеличивается риск его компрометации. Последствия компрометации могут быть чудовищными, вплоть до полной потери контроля над Active Directory и краху ИТ систем. Это может быть вызвано как недостаточными мерами безопасности, наличием не закрытых уязвимостей ОС или компонентах системы, которые позволяют удалённое исполнение кода и т.д. Как отмечалось выше, отозвать нормальным способом такой сертификат уже нельзя, и последствия будут действительно тяжёлыми.

Другой момент связан с гибкостью разделения ЦС на функциональные уровни (делегирование). Например, невозможно организовать несколько различных политик выдачи, разделить на классы (например, один ЦС издаёт сертификаты только машинам и устройствам, другой только для пользователей) и т.д., потому что он всего один.

Недостатки одноуровневой иерархии заметно перевешивают её преимущества в лёгкости и компактности. Именно поэтому такая конфигурация имеет смысл лишь в каких-то небольших и изолированных сетях с низкими требованиями по безопасности. Например, это может быть какая-то тестовая среда. В бизнес-среде такое решение использовать не рекомендуется.

Двухуровневая иерархия

Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:

Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.

В двухуровневой иерархии уже возможно решить недостатки одноуровневой иерархии. Здесь корневой ЦС выпускает сертификаты только для подчинённых ЦС, а уже подчинённый ЦС выдаёт сертификаты конечным потребителям. Поскольку издающие ЦС развёртываются не так часто, и срок их действия достаточного велик, это позволяет изолировать корневой ЦС от сети. Это автоматически сводит к нулю шанс компрометации такого ЦС, поскольку без сети к нему не добраться. Более того, основное время жизни он может (и должен) проводить в выключенном состоянии. Включать его нужно только для обновления собственного сертификата, подчинённого ЦС или для публикации нового CRL. В остальное время он никому не нужен.

Другим достоинством двухуровневой иерархии является улучшенная гибкость в разбиении подчинённых ЦС на какие-то классы. Тот же типичный сценарий, когда два ЦС управляются разными подразделениями ИТ, и каждый ЦС выпускает сертификаты для своих групп потребителей. Например, для машин отдельно, для пользователей отдельно. Можно для корпоративных разработчиков (которые обычно живут в своих средах) выделить свой подчинённый ЦС.

Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи) и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.

Из недостатков можно выделить лишь некоторое увеличение как административных, так и финансовых издержек (требуется дополнительная лицензия). К административным издержкам добавятся контроль за сроком действия каждого ЦС и списка отзыва корневого ЦС, а также их своевременное обновление. Кроме того, несколько увеличится время построения и проверки цепочек сертификатов, поскольку добавляется ещё один уровень. На практике это время практически не ощутимо.

Для небольших и средних предприятий такая схема является наиболее оптимальной, поскольку она позволяет обеспечить должный уровень безопасности и приемлемый уровень гибкости разделения ЦС на определённые функции.

Трёх- и более уровневые иерархии

В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе. Представьте международную компанию с региональными офисами в разных странах. В них может действовать своё законодательство в вопросах безопасности, например, при обработке персональных данных. Для соблюдения подобных юридических формальностей на каждый такой регион выделяется свой собственный ЦС политик (при этом, размещается он, как правило, в головном офисе компании). В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).

В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:

Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.

К плюсам такой схемы можно отнести гибкость полученной PKI с возможностью адаптации под практически любые условия. Правда, за это придётся платить. Во-первых, многоуровневые иерархии удорожают стоимость развёртывания и сопровождения PKI. Во-вторых, клиентам требуется больше времени на построение и проверки на отзыв полных цепочек сертификатов, что может вызывать отказы из-за превышения таймаутов верхних протоколов передачи данных. И на практике такие схемы зачастую являются избыточными. Поэтому при выборе подходящей иерархии ЦС следует искать баланс между гибкостью и практической целесообразностью с учётом капитальных и операционных затрат на содержание PKI.

В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

Настройка HTTPS с использованием нового сертификата, подписанного центром сертификации—Администрирование ArcGIS Server (Windows)

В этом разделе показано, как настроить HTTPS для ArcGIS Server с помощью сертификата, подписанного центром сертификации. Для настройки HTTPS с помощью сертификата, подписанного центром сертификации, выполните следующие шаги:

1. Создайте самозаверяющийся сертификат.
2. Отправьте запрос в центр сертификации на подпись сертификата.
3. Настройте сайт ArcGIS Server на использование сертификата, подписанного центром сертификации.
4. Настройте каждый ArcGIS Server в развертывании.
5. Импортируйте корневой сертификат центра сертификации в хранилище сертификатов Windows.
6. Настройка HTTPS для сайта.
7. Осуществите доступ к сайту при помощи HTTPS.

Создание нового самозаверенного сертификата

1. Войдите в ArcGIS Server Administrator Directory по адресу https://gisserver.domain.com:6443/arcgis/admin.
2. Перейдите в machines > [имя компьютера] > sslcertificates.
3. Щёлкните создать
4. Введите значения параметров на этой странице:
5. Щелкните Создать, чтобы сформировать сертификат.

Обращение в центр сертификации с запросом на подпись сертификата

Чтобы веб-браузеры считали сертификат доверенным, он должен быть проверен и получить вторую подпись одного из известных центров сертификации, например – Verisign или Thawte.

1. Откройте самозаверенный сертификат, созданный вами в предыдущем разделе, и щелкните generateCSR. Скопируйте содержимое в файл, обычно с расширением . csr.
2. Отправьте CSR-файл в выбранный центр сертификации. Вы можете получить сертификаты с кодировкой Distinguished Encoding Rules (DER) или Base64. Если CA запрашивает тип веб-сервера, для которого готовится сертификат, укажите Other\Unknown или Java Application Server. После проверки вашей личности вам будет отправлен файл .crt или .cer.
3. Сохраните подписанный сертификат, полученный из центра сертификации, на компьютере, к которому имеется доступ из ArcGIS Server Administrator Directory. Помимо подписанного сертификата центр сертификации также издает корневой сертификат. Сохраните корневой сертификат на компьютере.
4. Войдите в ArcGIS Server Administrator Directory: https://gisserver.domain.com:6443/arcgis/admin.
5. Выберите machines > [имя компьютера] > sslcertificates > importRootOrIntermediate, чтобы импортировать корневой сертификат центра сертификации. Если центр сертификации издал дополнительные промежуточные сертификаты, импортируйте их тоже.
6. Перейдите в меню machines > [имя компьютера] > sslcertificates.
7. Выберите имя самозаверенного сертификата, направленного в центр сертификации.
8. Щелкните importSignedCertificate и перейдите к местоположению, где находится сохраненный подписанный сертификат, полученный из центра сертификации.
9. Щелкните Подтвердить. Он заменит самозаверенный сертификат, который вы создали ранее, на сертификат, подписанный центром сертификации.

Настройте сайт ArcGIS Server на использование сертификата, подписанного центром сертификации.

CRL Distribution Points (CDP), указанный в подписанном CA сертификате, должен быть действительным и доступным с компьютеров, на которых установлен ArcGIS Server. Если CDP, заданный в сертификате, недействителен или недоступен из-за отсутствия доступа к интернету, неполадок в сети или настроек брандмауэра, то публикация из ArcGIS Desktop будет невозможна. Чтобы исправить эту проблему, выполните шаги из раздела Я не могу опубликовать сервис на сайте ArcGIS Server, который использует сертификат, выданный CA главы Часто встречающиеся проблемы и их решения.

1. Войдите в ArcGIS Server Administrator Directory по адресу https://gisserver.domain.com:6443/arcgis/admin. Замените gisserver.domain.com полным именем компьютера, где установлен ArcGIS Server.
2. Перейдите к компьютеры > [имя компьютера].
3. Выберите Редактировать.
4. Введите имя подписанного сертификата в поле SSL-сертификат веб-сервера. Указанное имя должно соответствовать псевдониму самозаверенного сертификата, который был заменен на заверенный центром сертификации в предыдущем разделе.
5. Нажмите кнопку Сохранить изменения, чтобы применить изменения. Сайт ArcGIS Server будет автоматически перезагружен.
6. После перезапуска сайта проверьте, что у вас имеется доступ к URL-адресу https://gisserver.domain.com:6443/arcgis/admin. Если вы не получаете ответа с этого URL-адреса, ArcGIS Server не может использовать указанный SSL-сертификат. Выполните вход в ArcGIS Server Administrator Directory по адресу http://gisserver. domain.com:6080/arcgis/admin, отметьте свой сертификат SSL и настройте ArcGIS Server на использование нового или другого сертификата.
7. На текущей странице проверьте значение свойства SSL-сертификат веб-сервера, где для HTTPS должен быть указан нужный сертификат.

Настройте каждый компьютер с ArcGIS Server в развертывании

Если ArcGIS Server развернут на нескольких компьютерах, необходимо получить и настроить подписанный центром сертификации сертификат для каждого компьютера с ArcGIS Server, который входит в состав сайта.

Импорт корневого сертификата центра сертификации в хранилище сертификатов Windows

Если в хранилище сертификатов Windows нет корневого сертификата Центра сертификации, его следует импортировать.

1. Выполните вход на компьютере с ArcGIS Server.
2. Сохраните на компьютере подписанный сертификат, полученный из центра сертификации.
3. Откройте этот сертификат и щелкните вкладку Путь к сертификату. Если Статус сертификата: показывает Данный сертификат в порядке., то это значит, что корневой сертификат Центра сертификации имеется в хранилище Windows, и его не надо импортировать. Перейдите к шагу 12.
4. Сохраните на компьютере корневой сертификат, полученный из центра сертификации.
5. Откройте этот сертификат и щелкните вкладку Общие. Щелкните кнопку, чтобы Установить сертификат.
6. Когда Мастер импорта сертификата откроется с панелью Добро пожаловать, нажмите Далее.
7. На панели Хранилище сертификата выберите опцию Поместить все сертификаты в следующее хранилище.
8. Щелкните кнопку Обзор. В диалоговом окне Выбрать хранилище сертификата включите опцию Показать физические хранилища.
9. Раскройте папку Доверенные корневые центры сертификации, чтобы просмотреть ее содержание. Выберите Локальный компьютер в качестве используемого хранилища сертификата. Щелкните ОК.
10. На панели Хранилище сертификата нажмите Далее.
11. Щелкните Готово.
12. Повторите шаги 1-11 для каждого компьютера с ArcGIS Server на вашем сайте.
13. Перезапустите ArcGIS Server на каждом компьютере.

Настройка HTTPS для сайта

1. Проверьте, что вы можете получить доступ к URL-адресу https://gisserver.domain.com:6443/arcgis/admin. Если вы не получаете ответа с этого URL-адреса, ArcGIS Server не может использовать указанный сертификат. Проверьте сертификат и настройте ArcGIS Server на использование нового или другого сертификата.
2. Если доступ к URL-адресу https://gisserver.domain.com:6443/arcgis/admin имеется, перейдите к security > config > update.
3. Установите параметр Протокол, выбрав опцию Только HTTPS, затем щелкните Обновить.

ArcGIS Web Adaptor потребуется около одной минуты, чтобы распознать изменение протокола связи вашего сайта.

Прежние версии:

В версиях 10. 2.1 и ниже требовалась перенастройка ArcGIS Web Adaptor после обновления протокола связи ArcGIS Server. В 10.2.2 и более новых версиях этого больше не требуется.

Доступ к сайту с помощью HTTPS.

После настройки HTTPS, ArcGIS Server прослушивает порт 6443 на наличие HTTPS-запросов. Для безопасного доступа к ArcGIS for Server используйте следующие URL-адреса:

ArcGIS Server Manager	https://gisserver.domain.com:6443/arcgis/manager
ArcGIS Server Services Directory	https://gisserver.domain.com:6443/arcgis/rest/services

Если переименовать ArcGIS Server при включенном протоколе HTTPS, доступ к ArcGIS Server с использованием HTTPS сохранится, однако необходимо создать новый сертификат и настроить ArcGIS Server на его использование.

---

Отзыв по этому разделу?

Установить центр сертификации | Microsoft Узнайте

Обратная связь Редактировать

Твиттер LinkedIn Фейсбук Эл. адрес

• Статья
• 29.07.2021
• 3 минуты на чтение

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016

Эту процедуру можно использовать для установки служб сертификации Active Directory (AD CS), чтобы можно было зарегистрировать сертификат сервера на серверах, на которых запущены сервер политики сети (NPS), служба маршрутизации и удаленного доступа (RRAS) или и то, и другое.

Важно

• Перед установкой служб сертификации Active Directory необходимо дать компьютеру имя, настроить для него статический IP-адрес и присоединить компьютер к домену. Дополнительные сведения о выполнении этих задач см. в руководстве по основной сети Windows Server 2016.
• Для выполнения этой процедуры компьютер, на котором вы устанавливаете AD CS, должен быть присоединен к домену, в котором установлены доменные службы Active Directory (AD DS).

Членство как в группе Администраторы предприятия , так и в группе Администраторы домена корневого домена является минимальным требованием для выполнения этой процедуры.

Примечание

Чтобы выполнить эту процедуру с помощью Windows PowerShell, откройте Windows PowerShell и введите следующую команду, а затем нажмите клавишу ВВОД.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

После установки AD CS введите следующую команду и нажмите клавишу ВВОД.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Чтобы установить службы сертификации Active Directory

Совет

Если вы хотите использовать Windows PowerShell для установки служб сертификации Active Directory, см. Install-AdcsCertificationAuthority для командлетов и необязательных параметров.

1. Войдите в систему как член группы администраторов предприятия и группы администраторов домена корневого домена.

2. В диспетчере серверов нажмите Управление , а затем нажмите Добавить роли и функции . Откроется мастер добавления ролей и компонентов.

3. В Перед началом работы нажмите Далее .

   Примечание

   Страница Перед началом работы мастера добавления ролей и компонентов не отображается, если вы ранее выбрали Пропустить эту страницу по умолчанию при запуске мастера добавления ролей и компонентов.

4. В выберите тип установки , убедитесь, что выбран вариант Установка на основе ролей или компонентов , а затем нажмите Далее .

5. В Выберите целевой сервер убедитесь, что выбрано Выбрать сервер из пула серверов . В пуле серверов убедитесь, что выбран локальный компьютер. Щелкните Далее .

6. В Выберите роли сервера , в Роли выберите Службы сертификации Active Directory . При появлении запроса на добавление необходимых компонентов нажмите Добавить компоненты , а затем нажмите Далее .

7. В Выберите функции , нажмите Далее .

8. В Службы сертификации Active Directory прочтите предоставленную информацию и нажмите Далее .

9. В Подтвердите выбор установки , нажмите Установить . Не закрывайте мастер в процессе установки. После завершения установки нажмите Настройте службы сертификации Active Directory на целевом сервере . Откроется мастер настройки AD CS. Прочтите информацию об учетных данных и, при необходимости, укажите учетные данные для учетной записи, которая является членом группы администраторов предприятия. Щелкните Далее .

10. В службе ролей щелкните Центр сертификации , а затем щелкните Далее .

11. На странице Setup Type убедитесь, что Выбран корпоративный ЦС , затем нажмите Далее .

12. На странице Укажите тип ЦС убедитесь, что выбрано Корневой ЦС , и нажмите Далее .

13. На странице Укажите тип закрытого ключа убедитесь, что выбрано Создать новый закрытый ключ , а затем нажмите Далее .

14. На странице Cryptography for CA оставьте параметры CSP по умолчанию ( RSA#Microsoft Software Key Storage Provider ) и алгоритм хеширования ( SHA2 ), а также определите наилучшую длину символа ключа для вашего развертывания. Большая длина символов ключа обеспечивает оптимальную безопасность; однако они могут повлиять на производительность сервера и могут быть несовместимы с устаревшими приложениями. Рекомендуется оставить значение по умолчанию 2048. Нажмите Далее .

15. На странице CA Name сохраните предлагаемое общее имя для CA или измените имя в соответствии с вашими требованиями. Убедитесь, что имя ЦС совместимо с вашими соглашениями об именовании и целями, поскольку вы не можете изменить имя ЦС после установки AD CS. Нажмите Далее .

16. На странице Срок действия в поле Укажите период действия , введите число и выберите значение времени (Годы, Месяцы, Недели или Дни). Рекомендуется значение по умолчанию, равное пяти годам. Щелкните Далее .

17. На странице CA Database в поле Укажите расположение баз данных укажите расположение папки для базы данных сертификатов и журнала базы данных сертификатов. Если вы укажете расположения, отличные от расположений по умолчанию, убедитесь, что папки защищены списками управления доступом (ACL), которые предотвращают доступ неавторизованных пользователей или компьютеров к базе данных ЦС и файлам журналов. Нажмите Далее .

18. В Confirmation щелкните Configure , чтобы применить выбранные параметры, а затем щелкните Close .

Отправить и просмотреть отзыв для

Этот продукт Эта страница

Просмотреть все отзывы о странице

Обзор развертывания сертификата сервера

| Microsoft Learn

• Статья
• 29. 07.2021
• 5 минут на чтение

Применяется к: Windows Server 2022, Windows Server 2019, Windows Server 2016

Этот раздел содержит следующие разделы.

• Компоненты развертывания сертификата сервера

• Обзор процесса развертывания сертификата сервера

Это руководство можно использовать для установки служб сертификации Active Directory (AD CS) в качестве корневого центра сертификации (ЦС) предприятия и для регистрации сертификатов сервера на серверах, на которых работает сервер политики сети (NPS), служба маршрутизации и удаленного доступа (RRAS). ), или как NPS, так и RRAS.

Если вы развертываете SDN с проверкой подлинности на основе сертификатов, серверы должны использовать сертификат сервера для подтверждения своей личности другим серверам, чтобы обеспечить безопасную связь.

На следующем рисунке показаны компоненты, необходимые для развертывания серверных сертификатов на серверах в вашей инфраструктуре SDN.

Примечание

На рисунке выше изображено несколько серверов: DC1, CA1, WEB1 и множество серверов SDN. В этом руководстве содержатся инструкции по развертыванию и настройке CA1 и WEB1, а также по настройке DC1, который, как предполагается в этом руководстве, уже установлен в вашей сети. Если вы еще не установили свой домен Active Directory, вы можете сделать это с помощью руководства по основной сети для Windows Server 2016.

Для получения дополнительной информации о каждом элементе, изображенном на рисунке выше, см. следующее:

• CA1

• WEB1

• ДС1

• NPS1

ЦС 1 с ролью сервера AD CS

В этом сценарии Корневой центр сертификации (ЦС) предприятия также является выдающим ЦС. ЦС выдает сертификаты серверным компьютерам, имеющим правильные разрешения безопасности для регистрации сертификата. Службы сертификатов Active Directory (AD CS) установлены на CA1.

Для более крупных сетей или в тех случаях, когда соображения безопасности оправдывают себя, можно разделить роли корневого ЦС и выдающего ЦС, а также развернуть подчиненные ЦС, которые выдают ЦС.

В наиболее безопасных развертываниях корневой ЦС предприятия отключается и физически защищается.

CAPolicy.inf

Перед установкой AD CS вы настраиваете файл CAPolicy.inf с определенными параметрами для вашего развертывания.

Копия шаблона сертификата

серверов RAS и IAS

При развертывании сертификатов сервера вы делаете одну копию шаблона сертификата серверов RAS и IAS , а затем настраиваете шаблон в соответствии со своими требованиями и инструкциями в этом руководстве.

Вы используете копию шаблона, а не исходный шаблон, чтобы сохранить конфигурацию исходного шаблона для возможного использования в будущем. Вы настраиваете копию шаблона серверов RAS и IAS , чтобы ЦС мог создавать сертификаты сервера, которые он выдает группам в Active Directory Users and Computers, которые вы указываете.

Дополнительная конфигурация ЦС 1

ЦС публикует список отзыва сертификатов (CRL), который компьютеры должны проверять, чтобы убедиться, что сертификаты, представленные им в качестве подтверждения личности, являются действительными сертификатами и не были отозваны. Вы должны настроить ЦС с правильным расположением CRL, чтобы компьютеры знали, где искать CRL во время процесса аутентификации.

WEB1 с ролью сервера веб-служб (IIS)

На компьютере с ролью сервера веб-сервера (IIS) WEB1 необходимо создать папку в проводнике Windows для использования в качестве места для CRL и AIA.

Виртуальный каталог для CRL и AIA

После создания папки в проводнике Windows необходимо настроить папку как виртуальный каталог в диспетчере служб IIS, а также настроить список контроля доступа для виртуального каталога разрешить компьютерам доступ к AIA и CRL после их публикации там.

DC1 с ролями AD DS и DNS-сервера

DC1 — это контроллер домена и DNS-сервер в вашей сети.

Политика домена по умолчанию групповой политики

После настройки шаблона сертификата в ЦС можно настроить политику домена по умолчанию в групповой политике, чтобы сертификаты автоматически регистрировались на серверах NPS и RAS. Групповая политика настроена в AD DS на сервере DC1.

Запись ресурса псевдонима DNS (CNAME)

Необходимо создать запись ресурса псевдонима (CNAME) для веб-сервера, чтобы другие компьютеры могли найти сервер, а также AIA и CRL, которые хранятся на сервере. Кроме того, использование ресурсной записи псевдонима CNAME обеспечивает гибкость, позволяющую использовать веб-сервер для других целей, например для размещения веб-сайтов и FTP-сайтов.

NPS1, на котором запущена служба роли сервера политики сети роли сервера служб сетевой политики и доступа

Сервер политики сети устанавливается при выполнении задач в руководстве по основной сети Windows Server 2016, поэтому перед выполнением задач в этом руководстве в вашей сети уже должен быть установлен один или несколько серверов политики сети.

Групповая политика применена и сертификат зарегистрирован на серверах

После настройки шаблона сертификата и автоматической регистрации можно обновить групповую политику на всех целевых серверах. В это время серверы регистрируют сертификат сервера из CA1.

Обзор процесса развертывания сертификата сервера

Примечание

Подробная информация о том, как выполнить эти шаги, представлена ​​в разделе Развертывание сертификата сервера.

Процесс настройки регистрации сертификата сервера состоит из следующих этапов:

1. На WEB1 установите роль веб-сервера (IIS).

2. На DC1 создайте запись псевдонима (CNAME) для своего веб-сервера WEB1.

3. Настройте свой веб-сервер для размещения CRL из ЦС, затем опубликуйте CRL и скопируйте сертификат Корневого ЦС предприятия в новый виртуальный каталог.

4. На компьютере, на котором вы планируете установить AD CS, назначьте компьютеру статический IP-адрес, переименуйте компьютер, присоедините компьютер к домену, а затем войдите на компьютер с учетной записью пользователя, который является членом Группы администраторов домена и администраторов предприятия.

5. На компьютере, на котором вы планируете установить AD CS, настройте файл CAPolicy. inf с параметрами, характерными для вашего развертывания.

6. Установите роль сервера AD CS и выполните дополнительную настройку ЦС.

7. Скопируйте CRL и сертификат CA из CA1 в общую папку на веб-сервере WEB1.

8. В ЦС настройте копию шаблона сертификата серверов RAS и IAS. ЦС выдает сертификаты на основе шаблона сертификата, поэтому вы должны настроить шаблон для сертификата сервера, прежде чем ЦС сможет выдать сертификат.

9. Настройте автоматическую регистрацию сертификатов сервера в групповой политике. При настройке автоматической регистрации все серверы, указанные вами с членством в группах Active Directory, автоматически получают сертификат сервера при обновлении групповой политики на каждом сервере. Если позже вы добавите дополнительные серверы, они также автоматически получат сертификат сервера.

10. Обновить групповую политику на серверах. При обновлении групповой политики серверы получают сертификат сервера, основанный на шаблоне, который вы настроили на предыдущем шаге. Этот сертификат используется сервером для подтверждения своей личности клиентским компьютерам и другим серверам в процессе аутентификации.

    Примечание

    Все компьютеры-члены домена автоматически получают сертификат корневого ЦС предприятия без настройки автоматической подачи заявок. Этот сертификат отличается от сертификата сервера, который вы настраиваете и распространяете с помощью автоматической подачи заявок. Сертификат ЦС автоматически устанавливается в хранилище сертификатов доверенных корневых центров сертификации для всех компьютеров-членов домена, чтобы они доверяли сертификатам, выданным этим ЦС.

11. Убедитесь, что все серверы зарегистрировали действительный сертификат сервера.

Что такое центр сертификации Microsoft?

Что такое центр сертификации?

Центр сертификации (ЦС) — это объект, который распространяет цифровые сертификаты на устройства. Они помогают проверять подлинность веб-сайтов, отдельных лиц и устройств перед администрированием цифровых сертификатов.

В системе PKI клиент создает пару открытого и закрытого ключей. Открытый ключ и информация о конечном пользователе отправляются в ЦС. Затем ЦС создает цифровой сертификат, состоящий из открытого ключа пользователя и атрибутов сертификата, подтверждая правильность информации. Сертификат подписывается ЦС своим закрытым ключом, что подтверждает легитимность сертификата.

Центры сертификации, несомненно, являются неотъемлемой частью PKI, которая может значительно повысить безопасность. Служба SecureW2 Cloud PKI позволяет легко создавать центры сертификации и распространять сертификаты. Это также дешевле, чем локальные альтернативы, поскольку обслуживание облачной PKI стоит ⅓ стоимости локальной PKI. Посмотрите, как мы помогли одному из наших клиентов здесь.

В этой статье мы объясним, что такое ЦС Microsoft и как лучше всего воспользоваться им.

Что такое частный центр сертификации?

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

Хотя можно создать собственные частные центры сертификации, этот процесс не очень прост. К счастью, компании создали программное обеспечение, позволяющее использовать преимущества сертификатов, не создавая PKI с нуля. Эти решения могут иметь решающее значение, поскольку неправильно настроенный или просроченный частный ЦС может сделать вашу сеть уязвимой и подверженной риску.

Центр сертификации Microsoft с AD CS

Одним из решений является доменная служба Microsoft Azure AD (AD DS), которая предоставляет настраиваемые ресурсы для выдачи и управления цифровыми сертификатами, используемыми в системах безопасности программного обеспечения, использующих технологии с открытым ключом. Корпорация Майкрософт предлагает свои собственные ЦС, поэтому среды на базе Майкрософт могут реализовать инфраструктуру открытых ключей (PKI) с AD CS.

Организации, работающие в средах Microsoft, могут использовать Microsoft CA для использования Active Directory и служб сертификации Microsoft для распространения сертификатов на все устройства, подключенные к домену, с помощью групповых политик. Службы Microsoft CA также бесплатны (технически, хотя человеческие ресурсы, необходимые для их запуска, на самом деле делают их одним из самых дорогих решений PKI), поскольку они включены в сервер Windows.

Развернуть центр сертификации Microsoft и управлять им — непростая задача. Вам понадобится специальная команда с опытом работы с PKI, чтобы внедрение прошло гладко. После настройки ваша команда должна быть в курсе лучших практик PKI, чтобы поддерживать безотказную работу и надежность. Это включает в себя множество встреч и принятие решений.

Центры сертификации Майкрософт включают в себя скрытые расходы на оборудование, наем группы экспертов и ежегодное обслуживание этой командой экспертов. Эти расходы могут складываться, делая заявление о «бесплатности» практически бессмысленным.

Программное обеспечение для управления частным ЦС с SecureW2

Вы можете избежать настройки и хлопот, используя расширенную PKI SecureW2. Наш современный инструмент управления позволяет вам пользоваться частным ЦС без сопутствующих неудобств. Вы можете за считанные минуты создать как корневые, так и промежуточные частные центры сертификации, а также управлять и настраивать свой центр сертификации, чтобы удовлетворить все ваши потребности в безопасности. Он поставляется с набором функций управления центром сертификации, поэтому вы можете настроить срок действия сертификата в зависимости от статуса пользователя и гарантировать, что срок действия сертификата не истечет без предварительного уведомления с помощью наших замечательных функций уведомления.

SecureW2 также позволяет интегрировать любого поставщика удостоверений SAML/LDAP с вашим частным ЦС, что упрощает выпуск сертификатов, создание надежных политик и создание пользовательских шаблонов сертификатов на основе групп пользователей, которые уже существуют в вашем каталоге. Наш облачный RADIUS может даже выполнять поиск идентификационных данных в любом облачном каталоге, предоставляя еще одну меру безопасности для вашей сети.

Управление сертификатами в Azure AD

Ниже мы перечислили несколько функций, которые SecureW2 может предоставить в сочетании с Microsoft CA, и то, как они упрощают управление сетью.

Шаблоны сертификатов для Azure AD

Шаблоны сертификатов легче настраивать и управлять с помощью SecureW2, поскольку наш графический интерфейс более интуитивно понятен, чем AD CS. Нет необходимости дублировать сертификаты по умолчанию и требуется меньше шагов. Администраторы могут повысить безопасность, создав сетевые группы на основе разрешений уровня доступа, чтобы настроить шаблон для каждой соответствующей группы.

Azure AD CRL

Серверы RADIUS могут просматривать все отозванные сертификаты с помощью списка отзыва сертификатов (CRL), чтобы знать, какие сертификаты все еще действительны. Этот список периодически загружается, чтобы сервер RADIUS оставался в актуальном состоянии. SecureW2 дает администраторам возможность настраивать интервалы обновления, чтобы CRL всегда был актуальным.

SecureW2 использует первую в отрасли технологию, позволяющую нашему Dynamic RADIUS взаимодействовать с вашим IDP и применять политики для ваших пользователей в зависимости от ваших потребностей без необходимости отзывать или перевыпускать сертификаты, повышая общую безопасность вашей сети. Это позаботится о любых потенциальных нарушениях безопасности, которые могут произойти между интервалами загрузки.

Шлюзы управляемых устройств

SecureW2 дает администраторам возможность создавать шлюз SCEP для регистрации сертификатов и настройки политик. Вместо того чтобы тратить время на настройку каждого отдельного устройства вручную или оставлять это на усмотрение конечного пользователя, администраторы могут настроить шлюз SCEP для отправки полезных данных, позволяющих управляемым устройствам настроить себя для регистрации сертификатов.

Если ваша среда Azure содержит Microsoft Intune, ознакомьтесь с нашим руководством по интеграции SCEP для регистрации сертификатов в Intune.

Интеграция ЦС Microsoft с SecureW2

Дополнительные затраты на запуск локальной PKI без множества полезных функций управления сертификатами трудно оправдать. Не говоря уже о том, что ручная настройка каждого устройства с помощью сертификата утомительна и просто не подходит для крупных организаций. Ваш ИТ-отдел достаточно занят без дополнительной нагрузки. Вместо всех головных болей используйте программное обеспечение SecureW2, чтобы упростить адаптацию ваших устройств.

Узнать об этом авторе

Эйтан Рафаэли

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