Active Directory для чайников часть 10 (Центр сертификации)

Службы сертификатов Active Directory (AD CS) — это роль Windows Server для выдачи сертификатов инфраструктуры открытых ключей (PKI), используемых в протоколах безопасной связи и проверки подлинности.



Вот тут подробно про все расписано: https://learn.microsoft.com/ru-ru/windows-server/identity/ad-cs/active-directory-certificate-services-overview но мы не будем терять много времени на теорию и сыро ознакомимся.

AD CS (Active Directory Certificate Services) — это компонент в Windows Server, который позволяет организациям создавать и управлять своими собственными центрами сертификации (CA, Certificate Authority). Он используется для выдачи, управления и проверки цифровых сертификатов внутри корпоративной сети.



Зачем нужен AD CS:​
Аутентификация: Проверяет подлинность пользователей, устройств или сервисов.
Шифрование: Защищает данные, например, при использовании VPN или Wi-Fi.
Цифровая подпись: Подтверждает целостность и подлинность данных (например, документов или кода).
Как работает AD CS:​
Создает сертификаты: Для пользователей, серверов, устройств.
Управляет сертификатами: Отслеживает срок действия, отзывает сертификаты (если утерян ключ или произошел компромет).
Работает в инфраструктуре PKI: Интегрируется с Active Directory для автоматического выпуска сертификатов.
Примеры использования AD CS:​
VPN: Сертификаты для безопасного подключения.
Wi-Fi: Аутентификация устройств.
HTTPS: Сертификаты для шифрования веб-сайтов внутри компании.
SMIME: Защищенная электронная почта.
Коротко: AD CS — это инструмент для создания и управления сертификатами внутри организации, который делает корпоративную сеть более безопасной.



Как Kerberos работает без AD CS:​
Kerberos без сертификатов:
Kerberos использует симметричное шифрование и обмен ключами для аутентификации.
В инфраструктуре Active Directory, Kerberos не требует сертификатов, так как работает на основе секретных ключей, хранимых в службах домена (KDC - Key Distribution Center).
Основные механизмы Kerberos:
Ticket-Granting Ticket (TGT): Получение общего доступа на основе доверия.
Service Ticket: Предоставляет доступ к конкретным службам.


Когда AD CS не нужен:
В стандартной среде Active Directory сертификаты не обязательны для работы Kerberos.
Аутентификация пользователей и устройств происходит на основе паролей и ключей шифрования.

Когда AD CS может понадобиться с Kerberos:​
Smart Card Logon (аутентификация с помощью смарт-карт):
Смарт-карты требуют сертификатов для аутентификации.
Для реализации этого требуется инфраструктура PKI (например, AD CS).

Kerberos PKINIT (Public Key Cryptography for Initial Authentication):
Расширение Kerberos для использования сертификатов в процессе начальной аутентификации.
Это нужно, если вместо пароля вы хотите использовать публичные/приватные ключи (например, при использовании смарт-карт).

Безопасность на уровне сервиса:
Если требуется шифрование трафика на уровне TLS (например, для LDAP over SSL/TLS), то сертификаты от AD CS становятся необходимыми.

Вывод:​
Kerberos может работать без AD CS, полагаясь на внутренние механизмы аутентификации Active Directory.
AD CS нужен, если требуется использование сертификатов для дополнительных функций, таких как смарт-карты, PKINIT или шифрование трафика через TLS.






римеры внутреннего (Internal) и внешнего (External) центров сертификации (Certificate Authorities, CA):



1. Внутренний центр сертификации (Internal Certificate Authority):​Это центр сертификации, развернутый внутри организации, например, с использованием AD CS.



Пример:​
Microsoft Active Directory Certificate Services (AD CS):
Развертывается внутри корпоративной сети.
Используется для выпуска сертификатов для внутренних нужд, таких как:
Аутентификация пользователей и устройств.
VPN.
Wi-Fi (802.1x).
Электронные подписи (S/MIME).
Сертификаты для внутренних HTTPS-сайтов.



Особенности:​
Удобен для использования в закрытых корпоративных сетях.
Сертификаты не признаны "доверенными" вне организации (например, в Интернете).
Стоимость низкая, так как лицензия на сервер часто уже покрыта корпоративным соглашением.

2. Внешний центр сертификации (External Certificate Authority):​Это сторонний (публичный) CA, который предоставляет сертификаты, признанные "доверенными" всеми основными браузерами, операционными системами и устройствами.



Пример:​
Let's Encrypt:
Бесплатный центр сертификации.
Выдает SSL/TLS-сертификаты для шифрования веб-сайтов (HTTPS).
Сертификаты признаются всеми основными браузерами.

DigiCert, GlobalSign, Sectigo:
Коммерческие центры сертификации.
Предоставляют сертификаты для веб-сайтов, шифрования электронной почты, аутентификации пользователей и других целей.
Часто используются для критически важных внешних веб-сайтов, корпоративных API и сервисов.


Особенности:​
Сертификаты признаются "доверенными" везде, где используется общедоступная инфраструктура (Интернет).
Стоимость может варьироваться: от бесплатных сертификатов (Let's Encrypt) до премиум-сертификатов с расширенной проверкой (EV SSL).





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



EKU (Enhanced Key Usage) — это расширение сертификата X.509, которое определяет, для чего может быть использован данный сертификат. EKU указывает конкретные цели использования ключа, например, для шифрования, аутентификации, подписания кода или защиты веб-сайтов через HTTPS.



CSR (Certificate Signing Request) — это запрос на выдачу цифрового сертификата. CSR отправляется в Центр сертификации (CA, Certificate Authority), чтобы получить сертификат. Этот запрос содержит информацию о заявителе (например, домене, компании или пользователе) и публичный ключ, который будет включен в сертификат.

  Сервер (генерация CSR)

  [Публичный ключ + Информация о субъекте]

  [Приватный ключ создается и остается на сервере]

          |

          v

  =======================================

  | CSR формируется:                    |

  | - Публичный ключ                    |

  | - Информация (домен, компания)      |

  | - Подпись CSR (с помощью приватного |

  |   ключа, чтобы доказать владение)   |

  =======================================

          |

          v

  ========================

  | Отправка CSR в CA    |

  ========================

          |

          v

Центр Сертификации (CA)

  [Проверка информации: ]

  [ - Доменное имя       ]

  [ - Легитимность заявки]

          |

          v

  ========================

  | Выдача сертификата: |

  | - Подписанный CA     |

  | - Содержит публичный |

  |   ключ и данные      |

  ========================

          |

          v

Сервер получает сертификат

  [Сертификат (с публичным ключом)       ]

  [ хранится на сервере вместе с приватным]

  [ ключом (для использования в HTTPS и др.) ]




		
	

CSR можно классифицировать по:




Назначению сертификата (SSL/TLS, S/MIME, подпись кода).
Формату (PEM, DER).
Содержимому (SAN, Wildcard).
Методу генерации (локальный, через браузер).
Типу ключей (RSA, ECDSA).




		
	




		
	

		
	




		
	




		
	

.pfx (Personal Information Exchange) — это формат файла, который используется для хранения сертификатов и связанных с ними ключей, включая:




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



Основные характеристики .pfx:​
Полное название формата:
PFX (Personal Information Exchange) или PKCS#12.
PKCS#12 — это стандарт, разработанный RSA Security для безопасного хранения и передачи сертификатов и ключей.

Шифрование и защита:
Файлы .pfx защищены паролем, чтобы предотвратить несанкционированный доступ к приватным ключам.

Расширение файлов:
.pfx или .p12 (оба взаимозаменяемы).






Подпись CSR (Certificate Signing Request) — это процесс подтверждения подлинности запроса на сертификат, который отправляется в Центр сертификации (CA). При создании CSR, запрос подписывается приватным ключом, чтобы удостоверить, что запрос исходит от владельца этого ключа.



Зачем нужна подпись CSR?​
Подтверждение владения приватным ключом:
Подпись CSR гарантирует, что заявитель действительно владеет приватным ключом, соответствующим публичному ключу, включенному в запрос.
Это важно, чтобы злоумышленник не мог подделать запрос на сертификат.

Обеспечение целостности данных:
Подпись защищает данные внутри CSR от изменений. Если кто-то попытается изменить содержимое CSR, подпись станет недействительной.

Шаг аутентификации:
CA проверяет подпись CSR перед выдачей сертификата, удостоверяясь, что запрос подлинный.


Как работает подпись CSR:​
Создание ключей:
Заявитель генерирует пару ключей:
Приватный ключ: Остается у заявителя и используется для подписи CSR.
Публичный ключ: Включается в CSR.


Составление CSR:
В CSR включаются:
Информация о субъекте (доменное имя, компания, страна).
Публичный ключ.


Подпись CSR:
CSR подписывается заявителем с использованием его приватного ключа.

Отправка в CA:
Подписанный CSR отправляется в Центр сертификации для проверки.

Проверка в CA:
CA использует публичный ключ из CSR, чтобы проверить цифровую подпись.
Если подпись верна, CA выдает сертификат.






роцесс работы CSR (Certificate Signing Request) и его подписи можно сравнить с использованием ключей в SSH (Secure Shell), так как оба механизма зависят от концепции асимметричного шифрования с использованием пары ключей: приватного и публичного. Вот основные параллели:



1. Генерация пары ключей​CSR:​
Генерируется пара ключей:
Приватный ключ: Остается у заявителя (на сервере или устройстве) и никогда не передается.
Публичный ключ: Включается в CSR, который отправляется в центр сертификации (CA).


SSH:​
При настройке SSH-ключей пользователь генерирует:
Приватный ключ: Хранится локально на устройстве пользователя.
Публичный ключ: Передается на сервер и добавляется в файл ~/.ssh/authorized_keys.


2. Использование приватного и публичного ключей​CSR:​
Приватный ключ: Используется для подписи CSR, чтобы доказать, что запрос исходит от владельца этого ключа.
Публичный ключ: Включается в запрос CSR и используется CA для проверки подписи.

SSH:​
Приватный ключ: Используется для аутентификации при подключении к серверу. Пользователь доказывает, что владеет соответствующим приватным ключом.
Публичный ключ: Хранится на сервере и используется для проверки подписи при входе.

3. Проверка и доверие​CSR:​
CA проверяет подпись, созданную приватным ключом, с помощью публичного ключа, включенного в CSR.
Если подпись верна, CA выдает сертификат, который подтверждает подлинность субъекта.

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

4. Конечная цель​CSR:​
Цель — получить сертификат от CA, который подтверждает подлинность субъекта и может использоваться для шифрования (например, HTTPS) и других целей.

SSH:​
Цель — установить защищенное соединение между клиентом и сервером, используя пару ключей для аутентификации и шифрования.



CSR — это запрос на сертификат, который подписывается приватным ключом для проверки подлинности.








ESC1-ESC8 — это обозначения восьми стандартов, входящих в спецификацию ETSI (European Telecommunications Standards Institute) для обеспечения доверенной инфраструктуры открытых ключей (PKI) и цифровых сертификатов.



Название ESC происходит от аббревиатуры "Electronic Signature and Certificate", что отражает их основное назначение: управление электронными подписями и сертификатами.



Почему такое название:​
E — Electronic (электронные):

Описывает, что стандарты относятся к цифровым (электронным) системам и процессам.
S — Signature (подпись):

Основная цель — управление процессами создания, проверки и использования цифровых подписей.
C — Certificate (сертификат):

Стандарты охватывают работу с цифровыми сертификатами, используемыми для обеспечения безопасности и доверия.
1-8 — Нумерация стандартов:

Цифры обозначают различные аспекты работы с электронными подписями и сертификатами, начиная от инфраструктуры PKI до проверки подписей.






		
	






		
	



Оба ключа можно хранить в различных форматах, в зависимости от требований инфраструктуры или приложений.

AD CS тесно связано с криптографией, так как оно управляет сертификатами, ключами и другими криптографическими данными. Это ключевой элемент в реализации PKI, которая обеспечивает безопасность и доверие в цифровых системах.



Основные элементы PKI:​
Центр сертификации (CA):
"Паспортный стол", который выдает и проверяет сертификаты.

Цифровые сертификаты:
Документ, который подтверждает подлинность субъекта (сайта, человека, устройства).

Ключи:
Приватный ключ: Хранится в секрете и используется для подписи или расшифровки.
Публичный ключ: Распространяется свободно и используется для проверки подписи или шифрования.

Зачем нужна PKI:​
Шифрование: Чтобы никто не смог перехватить ваши данные (например, при входе на сайт).
Аутентификация: Чтобы убедиться, что сайт или пользователь — это те, за кого себя выдают.
Цифровая подпись: Для проверки, что документ или сообщение не изменено.
Коротко:​PKI — это система, которая обеспечивает безопасность и доверие в интернете, используя сертификаты и ключи для шифрования, аутентификации и подписи. Это как цифровой паспортный стол, который помогает вам знать, с кем вы общаетесь, и защищает ваши данные.





Шаблоны сертификатов в Active Directory Certificate Services (AD CS) — это предварительно настроенные параметры, которые определяют, как должны выглядеть и работать выдаваемые сертификаты. Они используются для упрощения и стандартизации процесса выпуска сертификатов в корпоративной инфраструктуре.



Основные цели шаблонов в AD CS:​
Унификация сертификатов:
Шаблоны задают структуру и параметры сертификатов для разных целей, таких как:
Сертификаты для пользователей (логин с использованием смарт-карт).
Сертификаты для серверов (SSL/TLS).
Сертификаты для приложений (подпись кода).


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

Автоматизация:
Пользователи, устройства и службы могут автоматически запрашивать сертификаты на основе заданного шаблона через Active Directory.

Настройка безопасности:
Шаблоны позволяют задавать требования безопасности, такие как длина ключа, алгоритмы шифрования и условия для использования сертификата.

Что задается в шаблонах?​
Типы сертификатов:
Определяет, для кого или чего предназначен сертификат (пользователь, устройство, сервер).

Допустимые ключи:
Указывает, какие алгоритмы и параметры ключей использовать (например, RSA, ECDSA, длина ключа).

Enhanced Key Usage (EKU):
Определяет, для каких целей можно использовать сертификат (например, аутентификация сервера, подпись кода).

Срок действия сертификата:
Определяет, как долго сертификат остается действительным.

Автоматическая выдача:
Настраивает автоматическое получение сертификатов для пользователей или устройств без необходимости ручного вмешательства.

Доступ и права:
Определяет, кто может использовать данный шаблон (пользователи, группы, компьютеры).

Примеры использования шаблонов​
Пользовательские сертификаты:
Для аутентификации в корпоративной сети.
Шаблон: "User".

Серверные сертификаты:
Для защиты соединений (SSL/TLS).
Шаблон: "Web Server".

Смарт-карты:
Для входа в систему с использованием двухфакторной аутентификации.
Шаблон: "Smart Card Logon".

Подпись кода:
Для подписания приложений, чтобы они считались доверенными.
Шаблон: "Code Signing".

VPN и Wi-Fi:
Для аутентификации пользователей или устройств.
Шаблон: "Workstation Authentication" или "Computer".

Преимущества использования шаблонов AD CS​
Централизованное управление:
Настройки всех сертификатов управляются из единой точки.

Экономия времени:
Не нужно вручную настраивать параметры сертификатов для каждого нового запроса.

Соответствие стандартам безопасности:
Шаблоны обеспечивают соблюдение корпоративных или отраслевых требований к безопасности.

Гибкость:
Можно создать разные шаблоны для разных целей, например, сертификаты для внутренних и внешних пользователей.

Итог​Шаблоны в AD CS — это инструмент для стандартизации, автоматизации и управления процессом выдачи сертификатов. Они позволяют организациям легко и безопасно использовать сертификаты для различных задач, таких как аутентификация, шифрование и защита соединений.



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





ертификат состоит из набора полей, которые содержат информацию о владельце, центре сертификации и других аспектах, необходимых для его использования в системе PKI (Public Key Infrastructure). Стандартным форматом является X.509.



Основные элементы сертификата​1. Информация о сертификате​Это базовые сведения, которые уникально идентифицируют сертификат:




Версия:
Указывает версию стандарта X.509 (например, X.509 v3 — наиболее популярный).

Серийный номер:
Уникальный идентификатор сертификата, назначаемый CA.

Алгоритм подписи:
Алгоритм, используемый для подписания сертификата (например, SHA256RSA).

2. Данные о владельце (Subject)​Информация о субъекте, которому выдан сертификат:




Common Name (CN):
Имя субъекта (например, домен example.com или имя пользователя).

Organization (O):
Название организации.

Organizational Unit (OU):
Подразделение организации.

Country (C):
Код страны (например, US или RU).

Subject Alternative Names (SAN):
Дополнительные имена субъекта (например, поддомены).

3. Данные о центре сертификации (Issuer)​Информация о CA, выдавшем сертификат:




Common Name (CN):
Имя центра сертификации.

Organization (O):
Название организации CA.

Country (C):
Код страны CA.

4. Публичный ключ (Public Key)​
Содержит публичный ключ субъекта, используемый для шифрования и проверки подписи.
Типы ключей:
RSA.
ECDSA.
Ed25519.

5. Срок действия (Validity Period)​Информация о времени действия сертификата:




Дата начала (Not Before):
С какого момента сертификат действителен.

Дата окончания (Not After):
До какого момента сертификат остается действительным.

6. Подпись сертификата​
Цифровая подпись, созданная приватным ключом CA.
Обеспечивает целостность и подлинность сертификата.
7. Расширения сертификата​Дополнительная информация, определяющая возможности и ограничения использования сертификата:




Enhanced Key Usage (EKU):
Указывает, для каких целей может использоваться сертификат (например, аутентификация сервера, подпись кода).

Key Usage:
Указывает операции с ключами (например, шифрование данных, цифровая подпись).

CRL Distribution Points:
Указывает, где можно получить список отозванных сертификатов.

Authority Information Access (AIA):
Указывает путь для проверки цепочки доверия (например, адрес OCSP или промежуточного сертификата).

Пример структуры X.509-сертификата​yaml

Копировать код

Certificate:

Version: 3

Serial Number: 1234567890

Signature Algorithm: sha256RSA

Issuer:

CN = Example CA

O = Example Organization

C = US

Validity:

Not Before: Jan 1 00:00:00 2025 GMT

Not After : Jan 1 00:00:00 2026 GMT

Subject:

CN = www.example.com

O = Example Organization

C = US

Subject Public Key Info:

Public Key Algorithm: RSA

RSA Public-Key: (2048 bit)

X509v3 extensions:

Key Usage: Digital Signature, Key Encipherment

Extended Key Usage: TLS Web Server Authentication

Subject Alternative Name:

DNS: www.example.com, DNS: example.com

Authority Information Access:

OCSP - URI:http://ocsp.example.com

CA Issuers - URI:http://ca.example.com/ca.crt

Signature:

Algorithm: sha256RSA

Signature: [hexadecimal data]




		
	



Итог:​Сертификат состоит из нескольких ключевых компонентов: информации о владельце и центре сертификации, публичного ключа, подписи, срока действия и дополнительных расширений. Все эти элементы работают вместе, чтобы обеспечить безопасность, доверие и аутентификацию в инфраструктуре PKI.



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



Основная задача ROOT CA - это подписывать серты для промежуточных CA. И обычно ROOT CA выключен, чтобы не быть подверженным компрометации.



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



Для резервного копирования сертификатов и связанных данных используются различные форматы файлов и расширения. Какой именно формат используется, зависит от среды и инструментов, которые вы применяете для управления сертификатами.



Основные расширения для бэкапа сертификатов:​1. .PFX / .P12 (PKCS#12)​
Что хранится:
Сертификаты (включая цепочку доверия).
Приватный ключ (если экспортируется вместе с сертификатом).
Дополнительные атрибуты (например, пароль для защиты).

Особенности:
Используется для резервного копирования сертификатов с приватным ключом.
Шифруется и защищается паролем.

Применение:
Экспорт и импорт сертификатов в Windows Server, IIS, OpenSSL, и других платформах.

2. .CER / .CRT (X.509 Certificate)​
Что хранится:
Только сертификат (публичный ключ).
Без приватного ключа.

Особенности:
Формат PEM (текстовый, Base64) или DER (бинарный).
Используется для импорта/экспорта сертификатов без закрытого ключа.

Применение:
Хранение сертификатов для серверов (например, HTTPS).

3. .KEY​
Что хранится:
Приватный ключ.

Особенности:
Формат PEM (текстовый) или DER (бинарный).
Часто используется с .CRT для разделённого хранения ключей и сертификатов.

Применение:
Хранение приватного ключа для TLS/SSL и других сертификатов.

4. .PEM​
Что хранится:
Сертификаты (один или несколько, включая цепочку доверия).
Приватный ключ (если требуется).

Особенности:
Универсальный текстовый формат (Base64).
Может содержать как сертификаты, так и ключи.

Применение:
Используется в OpenSSL, Apache, Nginx.

5. .BAK​
Что хранится:
Резервная копия конфигурации CA (включая сертификаты, базу данных и закрытый ключ CA).

Особенности:
Генерируется при резервном копировании CA в AD CS.
Файлы часто сопровождаются инструкцией для восстановления.

Применение:
Используется для восстановления CA в Windows Server.

6. .PKI / .PKCS7 (.P7B / .P7C)​
Что хранится:
Сертификаты (включая цепочку доверия).
Без приватного ключа.

Особенности:
Формат PKCS#7, подходящий для передачи сертификатов.
Используется для создания доверенных хранилищ.

Применение:
Обмен сертификатами в Windows, Java.

7. Прочие форматы​
.JKS (Java KeyStore):
Приватные ключи и сертификаты в Java-ориентированном формате.

.HSM-зашифрованные файлы:
Для бэкапа ключей и сертификатов, хранимых в аппаратных модулях безопасности (HSM).

Что хранится в бэкапах?​
Сертификаты:
Корневой сертификат (Root CA).
Промежуточные сертификаты (Intermediate CA).
Конечные сертификаты (End-Entity Certificates).

Приватные ключи:
Используемые для подписи сертификатов или расшифровки данных.

Цепочки сертификатов:
Включают полный путь от конечного сертификата до Root CA.

Дополнительные данные:
Конфигурация CA.
Журналы транзакций.
CRL (Certificate Revocation List).
Файлы политики (CAPolicy.inf).

Резюме:​
Расширения зависят от содержания: .pfx для сертификатов с ключами, .crt или .cer для сертификатов без ключей, .bak для резервных копий CA.
Бэкап должен быть защищён паролем или шифрованием, особенно если включает приватные ключи.
Каждый сертификат в инфраструктуре PKI имеет свой уникальный закрытый ключ. Это основа безопасности асимметричной криптографии. Уникальность ключей гарантирует защиту, подлинность и целостность системы.



Каждый закрытый ключ в инфраструктуре PKI (Public Key Infrastructure) имеет своё предназначение в зависимости от уровня и роли субъекта. Закрытые ключи Root CA, промежуточных CA и пользователей выполняют разные задачи в экосистеме доверия. Давайте разберём их роли.



1. Закрытый ключ Root CA​Предназначение:​
Подпись сертификатов промежуточных CA:
Root CA подписывает сертификаты промежуточных CA, создавая основу доверия.
Корневой сертификат самоподписан (self-signed), что означает, что Root CA является начальной точкой доверия.

Роль в PKI:​
Root CA — это "верхний уровень доверия". Все субъекты, ниже в цепочке (промежуточные CA, пользователи), зависят от подлинности этого ключа.
Особенности:​
Закрытый ключ Root CA хранится максимально защищённо:
Часто используется только в оффлайн-режиме.
Хранится в HSM или в защищённой среде.

Используется редко:
Только для создания новых промежуточных CA или обновления CRL.

2. Закрытый ключ Промежуточного CA​Предназначение:​
Подпись конечных сертификатов:
Промежуточный CA выдаёт сертификаты пользователям, серверам, устройствам и сервисам.

Делегирование доверия:
Промежуточный CA продолжает цепочку доверия, создаваемую Root CA.

Роль в PKI:​
Промежуточный CA используется для разделения ответственности и снижения рисков:
Если скомпрометирован промежуточный CA, это затрагивает только сертификаты, подписанные им, но не всю инфраструктуру.

Особенности:​
Промежуточный CA обычно работает в онлайн-режиме, что делает его более подверженным атакам.
Часто используется для выпуска сертификатов по конкретным категориям (например, для пользователей или серверов).
3. Закрытый ключ Пользователя (или сервиса)​Предназначение:​
Подпись данных:
Пользователь или сервис может подписывать данные своим закрытым ключом (например, для электронной подписи).

Расшифровка данных:
Только закрытый ключ владельца может расшифровать данные, зашифрованные его публичным ключом.

Аутентификация:
Используется для доказательства подлинности субъекта (например, аутентификация пользователя или сервера).

Роль в PKI:​
Закрытый ключ пользователя — это "конечный уровень доверия". Он используется для повседневных операций, таких как шифрование, подпись или аутентификация.
Особенности:​
Закрытый ключ генерируется и хранится на стороне пользователя или устройства:
Смарт-карта.
Токен.
Программное хранилище.

Безопасность закрытого ключа лежит на пользователе или устройстве.






Тут более подробно расписано: https://posts.specterops.io/certified-pre-owned-d95910965cd2

Эта первая мысль хакера. ШО нам вообще нужно. С помощью закрытого ключа вы можете создавать и подписывать новые сертификаты для ЛЮБОГО пользователя и использовать эти поддельные сертификаты для аутентификации в AD до тех пор, пока сертификат CA действителен (по умолчанию 5 лет, но часто дольше). Так что если вы украдете закрытый ключ, то по сути вы скомпрометируете весь домен.

Злоумышленник может скомпрометировать AD CS через:




Кражу закрытых ключей CA.
Эксплуатацию уязвимых шаблонов сертификатов.
Манипуляцию CRL/OCSP.
Использование веб-регистрации или автоматической выдачи сертификатов.