vrr/doc
2
0
Fork 0
mirror of https://github.com/bpmbpm/doc.git synced 2026-04-30 12:30:52 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
doc/IT/CADES/tsl_4.md
Dmitry cfd69a30bd
Update tsl_4.md
2025-12-17 14:24:17 +03:00

847 lines
76 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## https://chat.deepseek.com/
CRL
- https://uc-em.ru/kornevye-sertifikaty/
- https://support.kontur.ru/ca/38808-kornevye_sertifikaty_spisok_otozvannyx
- http://crl.roskazna.ru/
- https://cryptoarm.ru/documentation/oshibka-postroenia-puti-sertifikacii
- https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=23143
## 1 вопрос
Укажи подробный алгоритм подписания и проверки электронной подписи на разных узлах.
Операция 1. Подписание документа открепленной квалифицированной (УКЭП) подписью CADES-XL. На компьютере подписанта установлены: корневой сертификат Минцифры России в хранилище «Доверенные корневые центры сертификации» и промежуточный сертификат аккредитованного Минцифры России УЦ «Контур» в хранилище «Промежуточные центры сертификации». Требуется ли при подписании скачивать файл tsl.xml Trust Service Status List (по адресу https://e-trust.gosuslugi.ru/app/scc/portal/api/v1/portal/ca/getxml)?
Подписание проводится программой КриптоПро 5.
Если файл tsl.xml требуется, то кто (программа КриптоПро 5, сервис OCSP или еще кто-то) и как его запрашивает? Считается, что CADES-XL (CAdES-X Type 1) реализуется сервисом OCSP (не CRL). Сертификат подписанта (УКЭП) выдан УЦ «Контур».
Операция 2. На компьютере проверки подписи установлен корневой сертификат Минцифры России в хранилище «Доверенные корневые центры сертификации». Требуется ли для проверки подписи установка сертификата УЦ «Контур»?
Требуется ли при проверки скачивать файл tsl.xml? Что в подписи CADES-XL содержится относительно сертификатов Минцифры России и аккредитованного УЦ «Контур». Что-то из tsl.xml (АккредитованныеУдостоверяющиеЦентры) записывается в открепленный файл подписи CADES-XL? Что в ответе OCSP содержится относительно сертификатов Минцифры России и аккредитованного УЦ «Контур»?
Может ли информация, содержащая в подписи противоречить tsl.xml? Например, по данным из подписи УЦ «Контур» имел действующий сертификат на момент подписания, а по данным из tsl.xml – отозванный, т.е. <ПериодДействияДо> содержит дату ранее подписания документа.
Извините, мне не удалось получить содержимое файла TSL с указанного вами адреса, так как сервер вернул ошибку 403 (доступ запрещён). Это означает, что я не могу проанализировать актуальное содержимое файла `tsl.xml` для предоставления точных деталей о сертификатах или статусах УЦ «Контур».
Однако, основываясь на ваших вопросах, я могу объяснить общие принципы работы, которые остаются верными.
### 📝 Операция 1: Подписание документа (CADES-XL)
**Роль файла TSL.xml:**
* **Требуется ли при подписании?** **Да, как правило, требуется.** Основная цель запроса списка TSL (Trust Service Status List) во время создания расширенной подписи CAdES-XL — включить в подпись **актуальные на момент подписания доказательства валидности** сертификата подписанта (статус «не отозван»).
* **Кто и как его запрашивает?** Запрос выполняет **программа КриптоПро CSP 5** (или плагин КриптоПро ЭЦП Browser Plug-in) в момент создания подписи. Алгоритм обычно такой:
1. КриптоПро обращается к **сервису OCSP**, указанному в сертификате подписанта (или заданному в настройках), для получения ответа о статусе.
2. Для формирования полного ответа и доказательств (proof-of-existence) сервису OCSP или непосредственно КриптоПро может потребоваться **свежий список TSL**, чтобы проверить аккредитацию и доверие к Удостоверяющему Центру (УЦ «Контур»), выпустившему сертификат.
3. **Ответ OCSP и ссылка на TSL** (или его штамп времени) упаковываются в подпись формата CAdES-XL.
**Ваши установленные сертификаты:** Наличие корневого сертификата Минцифры и промежуточного УЦ «Контур» на вашем компьютере необходимо для криптографической операции подписания и построения цепочки доверия. Однако для проверки аккредитации УЦ на момент подписания все равно требуется свежий TSL.
### 🔍 Операция 2: Проверка подписи
**Роль файла TSL.xml:**
* **Требуется ли установка сертификата УЦ «Контур»?** Нет, отдельная установка не требуется. Для проверки цепочки доверия достаточно корневого сертификата Минцифры. Промежуточные сертификаты (УЦ «Контур») **должны быть уже вложены в саму подпись** формата CAdES-XL, что является стандартной практикой.
* **Требуется ли при проверке скачивать TSL.xml?** **Да, для полной проверки.** Программа проверки (КриптоПро или иное ПО) должна свериться с актуальным TSL, чтобы удостовериться, что:
1. УЦ «Контур» был аккредитован на дату выдачи сертификата подписанта.
2. Корневой сертификат Минцифры России остаётся действующим и доверенным.
* **Что содержится в подписи CADES-XL относительно сертификатов?** В подписи содержится:
* **Цепочка сертификатов:** Как минимум, сертификат подписанта и промежуточный сертификат УЦ «Контур» (возможно, и другие).
* **Ответ OCSP:** Содержит **штамп времени** и подтверждение, что на момент этой метки времени сертификат подписанта не был отозван. В ответе OCSP также содержится информация о цепочке доверия, включая статус промежуточного и корневого УЦ на тот момент (может ссылаться на TSL).
* **Ссылки на TSL:** Подпись может содержать прямые ссылки (URL, хеш) на использованный при создании файл TSL, но **не сам полный список TSL**.
* **Может ли информация в подписи противоречить TSL?** **Да, и это ключевой момент.** Подпись CAdES-XL фиксирует свидетельства валидности **на момент ее создания**. Файл TSL — это **актуальное состояние** на момент проверки. Возможен именно ваш пример:
* **В подписи (ответ OCSP):** «Сертификат УЦ «Контур» действовал на 01.10.2023».
* **В свежем TSL (на дату проверки):** В `<ПериодДействияДо>` для УЦ «Контур» указана дата **01.11.2023** (т.е., он прекратил действие *после* подписания, но *до* проверки).
* **Итог проверки:** Подпись остается **технически корректной и юридически значимой**, так как была создана в период, когда все сертификаты были действительны. Это преимущество CAdES-XL с метками времени. Однако, если в TSL указано, что сертификат УЦ был **отозван (revoked) до даты подписания**, а ответ OCSP в подписи говорит об обратном — это признак критической проблемы (например, скомпрометированный OCSP-сервер).
### 💡 Что делать дальше?
Поскольку прямой доступ к TSL через URL ограничен, рекомендую:
1. Проверить настройки **КриптоПро CSP** (оснастка «Параметры TSP/OCSP»), возможно, там уже указан альтернативный источник списков доверия.
2. Посетить **официальный портал Госуслуг** в разделе, посвящённом электронной подписи и аккредитованным УЦ — там часто можно скачать TSL вручную.
3. Обратиться в **техническую поддержку УЦ «Контур»** — они обязаны предоставлять своим клиентам корректные настройки и пути для получения TSL.
4. Использовать **средства КриптоПро** (например, «КриптоПро TSP Client» или «КриптоПро OCSP Client») для диагностики запросов статусов.
5. При проверке подписей в корпоративной среде уточнить, не развёрнут ли у вас **локальный сервис кэширования TSL/OCSP** (например, КриптоПро TSP), к которому следует обращаться.
## 2 Файл tsl.xml прилагаю. Уточни свой ответ при необходимости.
Разберем всё по порядку, опираясь на предоставленный TSL.
### Краткие ответы на ваши вопросы:
1. **"Разве сервис OCSP не даст ответ?"**
**Ответ:** **Да, даст, но на другой вопрос.** OCSP отвечает на вопрос: **"Не отозван ли данный конкретный сертификат на текущий момент?"**. Он **НЕ** проверяет аккредитацию УЦ на историческую дату выдачи сертификата и не управляет доверием к корневым сертификатам.
2. **"Разве это не аналог листа CRL, но для аккредитованных УЦ?"**
**Ответ:** **И да, и нет. Это более широкое понятие.**
* **Как CRL:** В TSL, внутри данных каждого ключа УЦ, есть секция `<АдресаСписковОтзыва>`. Это прямые ссылки на CRL этого конкретного УЦ, которые используются программами для проверки отзыва.
* **Гораздо больше, чем CRL:** TSL — это **полный паспорт аккредитованного УЦ**. Он содержит не только точки распространения CRL, но и юридические данные УЦ, его программно-аппаратные комплексы (ПАК), действующие и исторические сертификаты ключей проверки электронной подписи (СКПЭП) самого УЦ, его статус аккредитации (например, "Приостановлена" для "Ижинформпроект") и историю смены этого статуса. CRL же — это просто список серийных номеров отозванных сертификатов.
3. **"В tsl.xml разве есть сведения о сертификате самого Минцифры?"**
**Ответ:** **Нет, напрямую — нет.** TSL содержит информацию об **аккредитованных УЦ**, но не о корневом УЦ (Минцифры). Однако корневой сертификат Минцифры является **предпосылкой доверия** ко всему TSL и всем сертификатам в нем. Программа проверки (КриптоПро) должна иметь предустановленный и доверенный корневой сертификат Минцифры, чтобы проверить подпись на самом файле TSL. Только после этого она может доверять данным внутри TSL.
4. **"Может ли информация в подписи противоречить TSL?"**
**Ответ:** **Да, может, и это критично.** Именно для этого и нужна проверка по TSL.
* **Пример 1:** Сертификат выдан УЦ "Ижинформпроект" 05.12.2023. Программа смотрит в TSL и видит, что статус аккредитации этого УЦ — `Приостановлена` с `2022-07-04`. Значит, на дату выдачи сертификата УЦ **не имел действующей аккредитации**. Это прямое противоречие, и подпись должна быть признана невалидной (с соответствующей детализацией ошибки).
* **Пример 2:** В подписи указан УЦ, которого нет в актуальном TSL вообще. Значит, он не аккредитован, и доверять его сертификатам нельзя.
### Уточненный ответ на ваш главный тезис:
> "Программа проверки (КриптоПро или иное ПО) должна свериться с актуальным TSL, чтобы удостовериться, что: УЦ был аккредитован на дату выдачи сертификата подписанта. Корневой сертификат Минцифры России остаётся действующим и доверенным."
**Это абсолютно верно.** Процесс проверки электронной подписи в РФ (по ГОСТу) включает несколько независимых шагов, и TSL — центральный из них:
1. **Проверка цепочки сертификатов:** С помощью криптографии проверяется, что сертификат пользователя выдан УЦ, сертификат УЦ выдан корневым УЦ (Минцифры) и т.д.
2. **Проверка срока действия:** Все сертификаты в цепочке должны быть действующими на дату подписания.
3. **Проверка на отзыв (CRL/OCSP):** Ни один из сертификатов в цепочке не должен быть отозван. Для этого используются ссылки из TSL или OCSP.
4. **Проверка аккредитации УЦ по TSL (Ключевой этап для квалифицированной подписи):**
* Находится сертификат УЦ, выпустившего сертификат подписанта.
* В актуальном TSL ищется этот УЦ и его **СКПЭП** (по отпечатку).
* Проверяется, что на **дату выдачи сертификата подписанта** УЦ имел статус аккредитации `Действует`.
* Проверяется, что использованный в документе СКПЭП УЦ соответствует данным в TSL (правильный отпечаток, срок действия).
5. **Проверка доверия к корню:** Доверие к корневому сертификату Минцифры — это не проверка по TSL, а **начальное условие**. Он должен быть предустановлен в хранилище доверенных корневых сертификатов. Его статус (действует/отозван) проверяется через свои механизмы (собственные CRL Минцифры).
### Ситуация с "скомпрометированным OCSP-сервером":
Вы правы, проблема может быть не в компрометации, а в **расхождении данных**.
* **OCSP-сервер УЦ** (`http://ocsp.infotrust.ru`) отвечает только на вопрос об отзыве сертификатов, выпущенных этим УЦ. Его ответ основан на внутренней базе отзывов УЦ.
* **TSL Минцифры** — это официальный государственный реестр статусов аккредитации. Он формируется Минцифры на основе представленных УЦ данных и решений об аккредитации/приостановке.
* **Возможный конфликт:** OCSP-сервер УЦ может отвечать, что сертификат **не отозван** (технически верно), но при этом по данным TSL Минцифры **УЦ уже приостановлен**. Для проверки квалифицированной подписи этого недостаточно. Программа **обязана** проверить статус в TSL и, обнаружив приостановку, должна отвергнуть подпись, даже если OCSP говорит "не отозван".
**Вывод:** TSL — это фундаментальный компонент инфраструктуры доверия для квалифицированной ЭП в РФ. Он не заменяет, а **дополняет** OCSP/CRL, добавляя критически важный юридический контекст — аккредитацию УЦ. Проверка по TSL обязательна для установления валидности квалифицированной подписи с юридической силой.
### 3
Рассмотрим ситуацию. Проводим проверку подписи CADES-XL. В ответе OCSP ведь содержится подтверждение, что на момент подписания сертификат УКЭП как подписанта, так и УЦ «Контур» были действующими? Зачем тогда нужен файл tsl.xml в момент проверки?
Отличный вопрос! Вы попали в самую суть различия между **технической проверкой цепочки сертификатов** и **юридической проверкой квалифицированной подписи**.
Давайте разберём, что даёт CADES-XL с OCSP-ответами и почему этого **недостаточно** без TSL.
### Что дают OCSP-ответы в CADES-XL?
1. **Доказательство неотозванности на момент подписания:** OCSP-ответы — это криптографически подписанные свидетельства от УЦ или его OCSP-сервера о том, что **на конкретный момент времени** (timestamp) сертификат подписанта **и** сертификат УЦ **не были отозваны**. Это "моментальный снимок" статуса отзыва.
2. **Проблема, которую решает CADES-XL:** Без этого "снимка" при проверке подписи спустя время пришлось бы полагаться на текущие CRL/OCSP, которые могут показать, что сертификат **сейчас отозван**, даже если на момент подписания он был действителен. OCSP-ответ внутри подписи фиксирует этот факт.
### Чего **НЕ** дают OCSP-ответы и зачем **критически** нужен TSL:
OCSP **не содержит и не может содержать** информацию об **аккредитации УЦ**. Это принципиально разные понятия.
**Представьте аналогию:**
* **OCSP** — это как звонок в ГИБДД с вопросом: "Не лишён ли водитель с правами серии ХХХ №YYYY своих прав **на текущий момент**?".
* **TSL** — это как официальный реестр аккредитованных автошкол, имеющих **право** выдавать водительские удостоверения. И в этом реестре есть история: "Автошкола 'Контур' была аккредитована с 2010 по 2025 год".
**Ситуация, которую может выявить только TSL:**
1. УЦ "Контур" выдал вам сертификат **01 декабря 2024 года**.
2. OCSP-ответ внутри CADES-XL подтверждает, что на момент подписания (допустим, **05 декабря 2024**) ни ваш сертификат, ни сертификат УЦ "Контур" не были отозваны. **Технически цепочка идеальна.**
3. **НО!** Вы проверяете подпись **в 2025 году** и загружаете актуальный TSL. В нём видите, что аккредитация УЦ "Контур" была **приостановлена** **15 ноября 2024 года**.
**ВОПРОС:** Может ли УЦ, у которого **приостановлена аккредитация**, выдавать новые **действительные квалифицированные сертификаты**?
**ОТВЕТ по закону (ФЗ-63): НЕТ, не может.**
Если УЦ потерял аккредитацию (или она приостановлена) на дату выдачи сертификата, то выданный им сертификат **не является квалифицированным**, даже если он технически корректен, не истёк и не отозван.
### Что именно проверяет программа, сверяясь с TSL?
Для квалифицированной подписи программа **должна** проверить:
1. **Аккредитация на дату выдачи:** Был ли УЦ "Контур" аккредитован **на дату выдачи вашего сертификата** (01.12.2024)? Смотрит в историю статусов в TSL.
2. **Соответствие сертификата УЦ:** Тот ли это самый УЦ "Контур"? Сверяет `Отпечаток` и данные сертификата УЦ из цепочки подписи с теми `ДанныеСертификата`, что перечислены в TSL для этого УЦ.
3. **Действительность СКПЭП УЦ:** Был ли сертификат ключа проверки ЭП (СКПЭП) самого УЦ "Контур" действующим (не просроченным) на дату выдачи вашего сертификата? Смотрит на `ПериодДействияС/До` внутри TSL.
### Итог: Роли OCSP и TSL принципиально разные
* **OCSP (в CADES-XL):** Фиксирует **технический факт неотозванности** на момент подписания. Это защита от последующего отзыва.
* **TSL:** Определяет **юридическое право** УЦ выдавать квалифицированные сертификаты. Это проверка **легитимности источника** вашего сертификата с точки зрения регулятора (Минцифры).
**Без актуального TSL вы не можете установить, является ли электронная подпись квалифицированной**, то есть имеющей **полную юридическую силу**, равную собственноручной подписи. Вы можете лишь установить, что она технически корректна и была создана действующим на тот момент закрытым ключом. Для многих юридически значимых действий (сдача отчётности, работа с госорганами, участие в электронных торгах) этого недостаточно — требуется именно квалифицированная подпись, валидность которой **невозможно** подтвердить без TSL.
**Ваш пример "скомпрометированного OCSP-сервера" теперь можно переформулировать:** OCSP-сервер УЦ "Контур" мог бы отвечать, что сертификаты не отозваны, но если регулятор (Минцифры) исключил "Контур" из TSL за нарушение, то его ответы теряют юридическую значимость для квалифицированной подписи. **TSL — это единственный официальный источник истины об аккредитации, утверждённый государством.**
### 3.1 Рассуждения
Вопрос затрагивает фундаментальные различия между технической проверкой цепочки сертификатов (на которую отвечает OCSP) и юридической проверкой статуса аккредитации УЦ (на которую отвечает TSL).
Давайте разберем по шагам, что дает CADES-XL с OCSP-ответами и зачем все равно нужен TSL.
Что дает OCSP в составе CADES-XL?
OCSP-ответы, приложенные в формате CADES-XL (или полученные онлайн), содержат мгновенные снимки статуса сертификатов на момент подписания.
Для сертификата подписанта: OCSP-ответ подтверждает, что на момент подписания (или на момент запроса) сертификат подписанта не был отозван.
Для сертификата УЦ (промежуточного): OCSP-ответ подтверждает, что на тот же момент сертификат УЦ, который выдал сертификат подписанта, также не был отозван.
Важно: OCSP подтверждает только отсутствие отзыва (revocation status). Он не подтверждает ничего другого.
Что НЕ может подтвердить OCSP?
OCSP не может подтвердить следующие критически важные для квалифицированной электронной подписи (КЭП) аспекты:
Аккредитация УЦ на дату выдачи сертификата подписанта.
Аккредитация — это право УЦ выдавать квалифицированные сертификаты. Это право может быть выдано, приостановлено или прекращено регулятором (Минцифры России).
Даже если сертификат УЦ технически действителен (не истек срок, не отозван), УЦ мог потерять аккредитацию. В этом случае выданные им сертификаты теряют юридическую силу как квалифицированные.
OCSP не содержит информации об аккредитации.
Соответствие сертификата УЦ данным, опубликованным регулятором.
TSL содержит точные данные о сертификатах ключей проверки электронной подписи (СКПЭП) аккредитованных УЦ: их отпечатки, сроки действия, точки распространения CRL и т.д.
УЦ мог выдать себе новый сертификат (например, после компрометации ключа), но если этот новый сертификат не был вовремя опубликован в TSL, он не считается доверенным для КЭП.
OCSP отвечает за статус отзыва того сертификата, который представлен в цепочке, но не проверяет, является ли этот сертификат тем самым, который был заявлен УЦ регулятору и внесен в TSL.
Действительность корневого сертификата Минцифры.
Корневой сертификат Минцифры — источник доверия для всей инфраструктуры. Его статус (действителен/отозван) также проверяется через CRL/OCSP, но это отдельная процедура, не связанная с OCSP-ответами для конкретного УЦ.
Зачем нужен TSL в момент проверки?
TSL — это официальный реестр аккредитованных УЦ, выпускаемый Минцифры. При проверке КЭП необходимо:
Убедиться, что УЦ, выдавший сертификат, был аккредитован на дату выдачи сертификата подписанта.
Для этого в TSL ищется запись об УЦ и проверяется история статусов аккредитации. Если на дату выдачи сертификата подписанта статус был "Действует", то с точки зрения аккредитации всё в порядке. Если же статус был "Приостановлен" или "Прекращен", то сертификат не является квалифицированным, несмотря на технически корректную цепочку и отсутствие отзывов.
Убедиться, что сертификат УЦ, использованный в цепочке, соответствует тому, что опубликован в TSL.
В TSL для каждого УЦ указаны действующие СКПЭП (их отпечатки, сроки действия). Необходимо сверить, что сертификат УЦ из цепочки подписи совпадает с одним из опубликованных в TSL (по отпечатку) и что на момент выдачи сертификата подписанта этот СКПЭП был действителен.
Получить актуальные точки распространения CRL и OCSP для проверки отзыва.
Хотя в CADES-XL уже могут быть вложены OCSP-ответы, валидатор всё равно может свериться с TSL, чтобы проверить, что используемые точки распространения CRL/OCSP являются теми, которые заявлены УЦ и разрешены регулятором.
Пример из вашего TSL
Возьмем УЦ "Ижинформпроект". В TSL видно:
```
text
<СтатусАккредитации>
<Статус>Приостановлена</Статус>
<ДействуетС>2022-07-04T21:00:00</ДействуетС>
</СтатусАккредитации>
```
Это означает, что с 2022-07-04 УЦ не имеет права выдавать новые квалифицированные сертификаты, а выданные ранее могут потерять юридическую силу (в зависимости от политик).
Предположим, у нас есть подпись с сертификатом, выданным этим УЦ 01.08.2022. OCSP-ответы показывают, что на момент подписания ни сертификат подписанта, ни сертификат УЦ не были отозваны. Но проверка по TSL покажет, что на дату выдачи (01.08.2022) УЦ уже был в статусе "Приостановлена" (с 04.07.2022). Следовательно, сертификат не является квалифицированным, и подпись не имеет усиленной квалифицированной юридической силы.
Вывод
OCSP (в CADES-XL) отвечает на вопрос: "Был ли отозван сертификат на момент подписания?"
TSL отвечает на вопросы: "Имел ли УЦ право выдавать квалифицированные сертификаты на дату выдачи? Доверяем ли мы именно этому сертификату УЦ?"
Для полной проверки юридической силы квалифицированной электронной подписи необходимо использовать оба механизма:
Проверить цепочку сертификатов, сроки действия и статус отзыва (через вложенные OCSP-ответы или онлайн-запросы).
Проверить аккредитацию УЦ и соответствие сертификатов УЦ данным TSL на дату выдачи сертификата подписанта.
Поэтому даже при наличии OCSP-ответов в CADES-XL файл TSL (актуальный!) необходим для проверки статуса аккредитации УЦ. Без TSL нельзя установить, является ли подпись квалифицированной с юридической точки зрения.
## 4
Правильно ли я понимаю.
1 Если Минцифры отзовет сертификат у УЦ Контур, то и без TSL это будет выявлено при подписании и программа не подпишет (или все же подпишет?).
2 tsl.xml нужен только для установления факта аккредитации, т.е. чтобы считать сертификат квалифицированным. Если УЦ Контур вообще нет в tsl.xml, то это значит, что он никогда не был аккредитованным УЦ?
Отличные вопросы! Рассмотрим их по порядку.
## Минцифры кроме tsl.xml публикует какие-либо CRL-листы?
**Да, публикует, но по другим адресам и для других целей.**
Минцифры России (ранее Минкомсвязи) как головной УЦ:
- **Выпускает свои собственные CRL** для отзыва сертификатов, которые **оно само выдало**:
- Сертификатов других УЦ (включая "Контур")
- Возможно, сертификатов для своих систем
- **Эти CRL хранятся отдельно от TSL** на других серверах
- **Адреса этих CRL** указываются в самих сертификатах, выданных Минцифры (в поле CRL Distribution Points)
В вашем tsl.xml можно увидеть ссылки на CRL Минцифры в записях, где оно выступает издателем:
```
<Адрес>http://rostelecom.ru/cdp/guс.crl</Адрес>
<Адрес>http://reestr-pki.ru/cdp/guс.crl</Адрес>
```
## 2. Правильно ли я понимаю...
### 2.1. Если Минцифры отзовет сертификат у УЦ "Контур"
**Программа подписания:**
- При подписании **обычно не проверяет** отзыв сертификата УЦ (если не настроена специально)
- Она просто использует ваш закрытый ключ и сертификат
- **Подписать документ можно будет** даже если сертификат УЦ отозван
**Программа проверки:**
- При проверке **должна проверить отзыв** по цепочке доверия
- Если сертификат УЦ "Контур" отозван Минцифры, проверка должна показать:
- Технически подпись корректна (математически верна)
- Но **юридически недействительна**, так как цепочка доверия разорвана
**Аналогия:** Водитель с правами может физически вести машину даже после лишения прав, но юридически это нарушение.
### 2.2. Если УЦ "Контур" вообще нет в tsl.xml
**Да, это может означать две ситуации:**
**СИТУАЦИЯ A: УЦ никогда не был аккредитован**
- Он не имеет права выдавать **квалифицированные сертификаты**
- Может выдавать только **неквалифицированные сертификаты**
- Такие сертификаты можно использовать для:
- Авторизации в системах
- Защищённой переписки
- **НО НЕ** для юридически значимых действий
**СИТУАЦИЯ B: УЦ был аккредитован, но исключён из TSL**
- Например, за нарушения или по решению суда
- В этом случае все выданные им **квалифицированные сертификаты теряют статус квалифицированных**
- Технически они остаются рабочими, но юридически бесполезны
## Важный нюанс: TSL vs Полный реестр
**TSL ≠ Полный список всех УЦ в России**
TSL содержит **только аккредитованные УЦ**. Есть также:
1. **Корневые УЦ** (Минцифры) - не в TSL, они "над" TSL
2. **Неквалифицированные УЦ** - не в TSL, они не имеют права выдавать квалифицированные сертификаты
3. **Тестовые УЦ** - не в TSL
## Проверочный алгоритм для программы:
```python
def check_signature(signature):
# 1. Техническая проверка
if not signature.is_mathematically_correct():
return "Технически неверна"
# 2. Проверка цепочки до корня
if not signature.has_valid_chain_to_root():
return "Цепочка доверия нарушена"
# 3. Проверка отзыва (CRL/OCSP)
if signature.is_revoked():
return "Сертификат отозван"
# 4. Проверка в TSL (ТОЛЬКО для квалифицированной подписи!)
ucc = signature.get_issuing_ca()
if ucc not in tsl:
return "УЦ не аккредитован → подпись неквалифицированная"
if not tsl[ucc].was_accredited_at(signature.cert_issue_date):
return "УЦ не имел аккредитации на дату выдачи → подпись неквалифицированная"
return "Квалифицированная электронная подпись (полная юридическая сила)"
```
## Практический пример:
В вашем tsl.xml есть УЦ "Ижинформпроект":
- Статус: **Приостановлена** с 2022-07-04
- История: **Действовала** с 2012-07-19 по 2022-07-04
**Значит:**
- Сертификаты, выданные до 04.07.2022 — квалифицированные (если не отозваны)
- Сертификаты, выданные после 04.07.2022 — **неквалифицированные**, даже если:
- Технически корректны
- Не отозваны
- Имеют полную цепочку до Минцифры
**Вывод:** TSL — это не про "работает/не работает", а про "имеет право/не имеет право выдавать квалифицированные сертификаты".
## 5
*"Программа подписания:
При подписании обычно не проверяет отзыв сертификата УЦ (если не настроена специально)
Она просто использует ваш закрытый ключ и сертификат
Подписать документ можно будет даже если сертификат УЦ отозван"*
Мы говорим про CADES-XL. Там требуется OSCP ответ. Разве если ответ будет, что сертификат отозван, то все равно будет произведена подпись документа?
Второй вопрос: Программа разве проверяет сертификат от аккредитованного УЦ или нет? Ему не достаточно знать, что сертификат просто действующий?
Отличные уточняющие вопросы! Давайте разберем их детально.
## 1. CADES-XL и OCSP-ответ при подписании
**Вы совершенно правы!** В случае CADES-XL ситуация сложнее.
### Что происходит при подписании CADES-XL:
1. **Программа пытается получить OCSP-ответ ДО подписания** для включения его в подпись
2. **Если OCSP-сервер отвечает "отозван" (revoked):**
- **Теоретически:** программа должна отказаться от подписания
- **Практически:** зависит от реализации программы
**Сценарии:**
**СЦЕНАРИЙ A (корректная реализация):**
```
1. Программа: "Хочу подписать документ CADES-XL"
2. Программа: "Запрашиваю OCSP-статус для своего сертификата..."
3. OCSP-сервер: "Сертификат ОТОЗВАН"
4. Программа: "Отказ! Не могу подписать, т.к. мой сертификат недействителен"
```
**СЦЕНАРИЙ B (некорректная реализация или настройки):**
```
1. Программа: "Хочу подписать документ CADES-XL"
2. Программа: "Запрашиваю OCSP-статус..."
3. OCSP-сервер: "Сертификат ОТОЗВАН"
4. Программа: "ОК, подпишу без OCSP-ответа" или "Подпишу с флагом 'unknown'"
→ Получается невалидная подпись CADES-XL
```
**Важный нюанс:** OCSP-сервер может ответить тремя состояниями:
- `good` - не отозван
- `revoked` - отозван
- `unknown` - статус неизвестен
**Если OCSP-сервер недоступен**, программа может:
1. Отказаться от подписания CADES-XL
2. Подписать без OCSP (не будет настоящего CADES-XL)
3. Подписать с отметкой `unknown` (будет CADES-XL, но проверка может провалиться)
## 2. Проверка аккредитации УЦ программой
### Что проверяет программа **по умолчанию**:
1. **Техническую корректность:**
- Математическая правильность подписи
- Цепочка сертификатов до доверенного корня
- Сроки действия сертификатов
- Отсутствие отзыва (по OCSP/CRL)
2. **А вот аккредитацию УЦ программа НЕ проверяет автоматически!**
### Почему аккредитация - это отдельная проверка:
**Аналогия:** Представьте, что вы проверяете медицинский рецепт.
- **Техническая проверка:** Подпись врача реальная, печать настоящая, дата не просрочена
- **Проверка аккредитации:** А имеет ли этот врач право выписывать рецепты? Может, его лицензию отозвали?
### Как программа узнает об аккредитации:
**Только через TSL!** Программа должна:
1. Загрузить актуальный TSL от Минцифры
2. Найти в нем УЦ, выпустивший сертификат
3. Проверить:
- Был ли УЦ аккредитован на дату выдачи сертификата
- Совпадает ли отпечаток сертификата УЦ с указанным в TSL
### Конкретный пример из вашего tsl.xml:
Возьмем УЦ "Ижинформпроект":
```xml
<СтатусАккредитации>
<Статус>Приостановлена</Статус>
<ДействуетС>2022-07-04T21:00:00</ДействуетС>
</СтатусАккредитации>
<ИсторияСтатусовАккредитации>
<СтатусАккредитации>
<Статус>Действует</Статус>
<ДействуетС>2012-07-19T20:00:00</ДействуетС>
</СтатусАккредитации>
<СтатусАккредитации>
<Статус>Приостановлена</Статус>
<ДействуетС>2022-07-04T21:00:00</ДействуетС>
</СтатусАккредитации>
</ИсторияСтатусовАккредитации>
```
**Что должна сделать программа:**
```python
def check_accreditation(cert, tsl):
# 1. Найти УЦ в TSL
ca = find_ca_in_tsl(cert.issuer, tsl)
if not ca:
return "УЦ не найден в TSL → не аккредитован"
# 2. Проверить статус на дату выдачи сертификата
cert_issue_date = cert.not_before # Дата выдачи
ca_status_on_date = get_ca_status_on_date(ca, cert_issue_date)
if ca_status_on_date != "Действует":
return f"УЦ не имел действующей аккредитации на {cert_issue_date}"
# 3. Проверить соответствие сертификата УЦ
if cert.issuer_certificate != ca.certificate_in_tsl:
return "Сертификат УЦ не соответствует TSL"
return "Аккредитация подтверждена"
```
### Почему программам "недостаточно" просто действующего сертификата:
1. **Юридические требования:**
- ФЗ-63 четко разделяет квалифицированные и неквалифицированные подписи
- Квалификация зависит от аккредитации УЦ на момент выдачи
2. **Разные сценарии использования:**
- **Внутренние системы компании:** достаточно технической проверки
- **Электронная отчетность в госорганы:** обязательна проверка аккредитации
- **Электронные торги:** обязательна проверка аккредитации
3. **Настройки программы:**
- **КриптоПро CSP** может работать в разных режимах
- Плагины для браузеров/Office имеют разные настройки
- Специализированные программы (для отчетности, торгов) всегда проверяют аккредитацию
### Практический пример с вашим tsl.xml:
**Ситуация:** УЦ "Ижинформпроект" выдает сертификат **05.12.2024**
**Техническая проверка:**
- Сертификат действителен до 2027 года ✓
- Подпись математически верна ✓
- OCSP-ответ: не отозван ✓
- Цепочка до Минцифры: корректна ✓
**Проверка по TSL:**
- УЦ в TSL: найден ✓
- Статус на 05.12.2024: "Приостановлена" (с 04.07.2022) ✗
- **ВЫВОД:** Сертификат не является квалифицированным!
**Вывод для пользователя:** "Технически подпись корректна, но не имеет юридической силы квалифицированной подписи"
## Что происходит в реальных программах:
### 1. **КриптоПро PDF** (при подписании PDF):
- Если выбрать "Квалифицированная подпись" → проверяет наличие OCSP-ответа
- Если OCSP не отвечает → предупреждение
- **Но аккредитацию не проверяет при подписании!** Только при проверке.
### 2. **Контур.Крипто / Такском**:
- При подписании: запрашивают OCSP для CADES-XL
- При проверке: если указано "квалифицированная" → загружают TSL и проверяют
### 3. **Сайты госуслуг / ФНС**:
- Всегда проверяют и техническую часть, и аккредитацию через TSL
- Отказывают в приеме, если УЦ не аккредитован на дату выдачи
**Главный вывод:** TSL - это **юридический компонент** проверки, а не технический. Программа может технически подписать документ и без проверки TSL, но такая подпись не будет признана квалифицированной при юридической проверке.
## Вывод: КриптоПро PDF - Но аккредитацию не проверяет при подписании! Только при проверке.
## 6
Превосходные вопросы! Вы затрагиваете ключевые аспекты инфраструктуры PKI в РФ. Давайте разберём по порядку.
## 1. Если УЦ "Контур" имеет сертификат от Минцифры, он автоматически аккредитован?
**НЕТ, НЕ АВТОМАТИЧЕСКИ!** Это важнейшее различие.
### Аналогия:
- **Сертификат от Минцифры** = "Диплом о высшем образовании"
- **Аккредитация Минцифры** = "Лицензия на ведение медицинской деятельности"
У вас может быть диплом врача, но без лицензии вы **не имеете права** лечить пациентов официально.
### В PKI России:
| Критерий | Сертификат от Минцифры | Аккредитация Минцифры |
|----------|----------------------|---------------------|
| **Что это** | Техническое доверие | Юридическое право |
| **Кто выдает** | Минцифры как корневой УЦ | Минцифры как регулятор |
| **Для чего** | Построение цепочек доверия | Право выдавать квалифицированные сертификаты |
| **Где фиксируется** | В самом сертификате | В TSL.xml |
| **Пример из файла** | Все УЦ в tsl.xml имеют сертификаты от Минцифры | Но у "Ижинформпроект" статус "Приостановлена" |
**Конкретный пример из вашего tsl.xml:**
```xml
<УдостоверяющийЦентр>
<Название>Общество с ограниченной ответственностью Научно-производственное предприятие "Ижинформпроект"</Название>
<РеестровыйНомер>17</РеестровыйНомер>
<СтатусАккредитации>
<Статус>Приостановлена</Статус> ← АККРЕДИТАЦИЯ ПРИОСТАНОВЛЕНА!
</СтатусАккредитации>
</УдостоверяющийЦентр>
```
Но при этом у него есть действующие сертификаты, подписанные Минцифры.
## 2. Зачем Минцифры выпускает CRL для своих сертификатов?
### Для быстрого отзыва доверия в случаях:
1. **Компрометация закрытого ключа УЦ**
- Если УЦ "Контур" потерял контроль над своим закрытым ключом
- Минцифры немедленно отзывает его сертификат через CRL
- Все цепочки через этот УЦ становятся недействительными **технически**
2. **Выявление нарушений**
- УЦ нарушает правила (например, выдаёт сертификаты без проверки личности)
- Минцифры отзывает сертификат УЦ
- Все выданные им сертификаты становятся технически недействительными
3. **Добровольный отказ от деятельности**
- УЦ прекращает работу
- Минцифры отзывает его сертификат
### Разница между отзывом (CRL) и приостановкой аккредитации (TSL):
| Аспект | Отзыв через CRL | Приостановка через TSL |
|--------|----------------|-----------------------|
| **Механизм** | Технический (PKI) | Административный |
| **Скорость** | Мгновенно (после публикации CRL) | После административного решения |
| **Эффект** | Все цепочки разрываются | Только новые сертификаты неквалифицированные |
| **Восстановление** | Выпуск нового сертификата УЦ | Восстановление аккредитации |
| **Пример из файла** | Нет в файле (CRL отдельно) | Статус "Приостановлена" у "Ижинформпроект" |
## 3. Кроме аккредитованных УЦ, какие ещё могут быть?
### Иерархия УЦ в РФ:
```
Минцифры России (Корневой УЦ)
/ \
/ \
(выдает сертификаты) (аккредитует)
/ \
/ \
┌─────────────────────┐ ┌─────────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
Аккредитованные НЕаккредитованные Корпоративные
УЦ (в TSL) УЦ (не в TSL) УЦ (не в TSL)
│ │ │
├─ Контур ├─ Test-УЦ ├─ УЦ Сбербанка
├─ Такском ├─ Demo-УЦ ├─ УЦ Газпромбанка
└─ и др. └─ УНЭП-УЦ └─ и др.
```
### Типы УЦ в России:
1. **Корневой УЦ (Минцифры)**
- Самый верхний уровень
- Не нуждается в аккредитации
- Его сертификат предустановлен во всех программах
- **Не входит в TSL!** TSL — это список тех, кого он аккредитовал
2. **Аккредитованные УЦ** (в TSL)
- Имеют право выдавать **квалифицированные сертификаты**
- Пример: УЦ "КАЛУГА АСТРАЛ" в вашем файле
- Проверяются регулятором
3. **Неквалифицированные УЦ** (не в TSL)
- Сертификаты от Минцифры или от других УЦ
- **Не имеют права** выдавать квалифицированные сертификаты
- Могут выдавать:
- Неквалифицированные сертификаты (УНЭП)
- Сертификаты для аутентификации
- Сертификаты для шифрования
4. **Корпоративные УЦ**
- Выпускают сертификаты для внутреннего использования
- Часто не связаны с государственной PKI
- Пример: Active Directory Certificate Services в компании
5. **Тестовые/Демонстрационные УЦ**
- Для разработки и тестирования
- Сертификаты не должны использоваться в продуктивной среде
## 4. Если нет аккредитации, что может выдавать УЦ?
УЦ без аккредитации может выдавать:
### А. **Неквалифицированные сертификаты (УНЭП)**
- Для внутреннего документооборота компаний
- Для аутентификации в информационных системах
- Для защиты электронной почты
- **НО:** Не для отчетности в госорганы!
### Б. **Сертификаты специального назначения:**
1. **Сертификаты для СМЭВ** (системы межведомственного взаимодействия)
2. **Сертификаты для ЕСИА** (госуслуги) - только если специально уполномочен
3. **SSL/TLS-сертификаты** для сайтов
4. **Сертификаты для код-сайнинга** (подписание ПО)
### В. **Особенности неквалифицированных сертификатов:**
**Технически** они идентичны квалифицированным:
- Такая же криптография (ГОСТ 34.10-2012)
- Такая же структура X.509
- Такая же цепочка доверия
**Юридически** они отличаются:
```
┌─────────────────────────────────────────────────────────────┐
│ Квалифицированный сертификат │
│ │
│ Техническая корректность + │
│ Аккредитованный УЦ на дату выдачи + │
│ Соответствие требованиям ФЗ-63 │
│ │
│ = Полная юридическая сила (как собственноручная подпись) │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Неквалифицированный сертификат │
│ │
│ Техническая корректность + │
│ (возможно) Сертификат от Минцифры + │
│ (НО) УЦ не аккредитован │
│ │
│ = Ограниченная юридическая сила │
│ (только если стороны заранее договорились) │
└─────────────────────────────────────────────────────────────┘
```
### Практический пример:
**Сценарий:** Компания "Ромашка" хочет внедрить ЭДО с контрагентами.
**Вариант 1 (дешевле):**
- Покупает неквалифицированные сертификаты у неаккредитованного УЦ
- Заключает соглашение с контрагентами: "Принимаем такие подписи"
- **Работает, но:** нельзя сдавать отчетность в ФНС
**Вариант 2 (дороже, но полный функционал):**
- Покупает квалифицированные сертификаты у аккредитованного УЦ
- Все контрагенты обязаны их принимать (по закону)
- Можно сдавать отчетность в госорганы
- Можно участвовать в электронных торгах
## Вывод: В чём главное отличие?
```python
def validate_signature(signature):
# Все проверяют это:
if not check_technical_validity(signature):
return "Технически недействительна"
# Только для квалифицированных подписей проверяют это:
if not check_accreditation_in_tsl(signature.ca, signature.cert_issue_date):
# Подпись технически работает, но...
return "Неквалифицированная подпись (УЦ не имел аккредитации)"
return "Квалифицированная подпись (полная юридическая сила)"
```
**Ключевой момент:** Сертификат от Минцифры даёт **техническое доверие**, аккредитация в TSL даёт **юридическое право**. Это как водительское удостоверение (технически вы можете водить) и страховка ОСАГО (юридически вы можете нести ответственность).
## 6.1
**Нет, неверно!** Моя схема была упрощённой и ввела вас в заблуждение. Прошу прощения за эту неточность. Давайте исправим.
## Правильная иерархия:
```
┌─────────────────────────────────────┐
│ Минцифры России │
│ (Головной УЦ и Регулятор) │
└───────────┬─────────────────────────┘
│
┌────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
(выдает сертификаты) (аккредитует) (предъявляет
│ │ требования)
│ │ │
┌───────┴───────┐ ┌─────┴──────┐ ┌──────┴──────┐
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
Аккредитованные НЕаккредитованные │ УЦ, которые │
УЦ, которым УЦ, которым │ вообще НЕ │
Минцифры выдало Минцифры выдало │ связаны с │
сертификаты сертификаты │ Минцифры │
(есть в TSL) (нет в TSL) │ │
│ │ │ │
│ │ │ │
▼ ▼ ▼ ▼
Квалифици- Неквалифи- Корпоративные Тестовые
рованные цированные УЦ УЦ
сертификаты сертификаты (внутренние (для разработки)
PKI компаний)
```
## Уточнение: Минцифры НЕ аккредитует неквалифицированные и корпоративные УЦ!
### 1. **Что Минцифры действительно делает:**
**A. Выдаёт сертификаты** (как технический корневой УЦ):
- Аккредитованным УЦ (они в TSL)
- Некоторым неквалифицированным УЦ (они не в TSL)
- Возможно, другим организациям по специальным программам
**B. Аккредитует** (как регулятор):
- **Только УЦ, которые хотят выдавать квалифицированные сертификаты**
- Аккредитованные УЦ попадают в **TSL**
### 2. **Какие УЦ НЕ аккредитует Минцифры:**
**A. Неквалифицированные УЦ:**
- Могут получить сертификат от Минцифры (технически)
- Но **не проходят аккредитацию** или не подают на неё
- **Не попадают в TSL**
**B. Корпоративные УЦ:**
- Часто вообще **не связаны с государственной PKI**
- Используют свои корневые сертификаты
- Пример: УЦ на базе Microsoft AD CS в компании
- **Никакого отношения к Минцифры не имеют**
**C. Тестовые УЦ:**
- Для разработки ПО
- Часто самоподписанные
- **Не связаны с Минцифры**
## Примеры из вашего tsl.xml:
В файле есть только **аккредитованные** УЦ:
1. **"Ижинформпроект"** - аккредитация приостановлена, но был аккредитован
2. **"КАЛУГА АСТРАЛ"** - аккредитованный УЦ
**Где неквалифицированные УЦ?** Их **нет в tsl.xml**, потому что они не аккредитованы!
## Конкретный пример разделения полномочий Минцифры:
### Процесс для УЦ "Контур":
```
┌────────────────────────────┐
│ УЦ "Контур" подаёт │
│ заявление в Минцифры │
└─────────────┬──────────────┘
│
┌─────────────┴──────────────┐
│ Минцифры проверяет: │
│ 1. Технические средства │
│ 2. Процедуры │
│ 3. Персонал │
│ 4. Юридические документы │
└─────────────┬──────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│Отказ │ │Аккредитация │ │Сертификат │
│в аккредитации│ │одобрена │ │выдан │
│ │ │ │ │(технически) │
└─────────────┘ └──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│Внесён в TSL │ │Может строить│
│(юридически) │ │цепочки │
│ │ │(технически) │
└─────────────┘ └─────────────┘
```
## Почему это важно?
1. **УЦ может иметь сертификат от Минцифры, но не быть в TSL**
- Технически: может выдавать сертификаты
- Юридически: не может выдавать **квалифицированные** сертификаты
2. **УЦ может быть в TSL, но потерять аккредитацию**
- Как "Ижинформпроект" в вашем файле
- Старые сертификаты (выданные при действующей аккредитации) остаются квалифицированными
- Новые сертификаты (после приостановки) — неквалифицированные
3. **Корпоративные УЦ вообще вне этой системы**
- Не обращаются в Минцифры
- Не получают сертификатов от Минцифры
- Не попадают в TSL
## Итоговая таблица:
| Тип УЦ | Сертификат от Минцифры | В TSL | Может выдавать квалифицированные сертификаты |
|--------|------------------------|-------|---------------------------------------------|
| **Корневой (Минцифры)** | Самоподписан | Нет | Да (для УЦ) |
| **Аккредитованный УЦ** | Да | Да | Да |
| **Неквалифицированный УЦ** | Может быть | Нет | Нет |
| **Корпоративный УЦ** | Нет | Нет | Нет (только для внутреннего использования) |
| **Тестовый УЦ** | Нет | Нет | Нет |
**Вывод:** Минцифры как регулятор аккредитует **только тех, кто хочет и может выдавать квалифицированные сертификаты**. Выдача сертификата (техническая операция) и аккредитация (юридическая процедура) — это **разные процессы**, даже если оба осуществляются Минцифры.
Reference in a new issue View git blame Copy permalink