Ошибка не установлено соединение с центром сертификации

Вячеслав 125	#1 Оставлено : 25 июня 2020 г. 4:47:48(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.06.2020(UTC) Сообщений: 1 Откуда: Уссурийск	Здравствуйте. Бтюсь с данной проблемой уже 4 день: 1. Установил чистую систему Windows Server 2016 2. Установил IIS 3. Установил SQL Server 2017 4. Установил КриптоПро CSP 5. Установил КриптоПро УЦ 2.0 Далее… Создаю запрос в ЦР Добавляю роль ЦС Формируется корневой сертификат, сохраняю на рабочем столе Добавляю роль ЦР и подставляю сертификат который был сформирован в ЦС и тут начинается… Если выбираю Установить сертификат из файла — то: ОШИБКА Не удалось установить соединение с ЦС, используя адрес https://localhost/ca/ и сертификат C:UsersАдминистратор.WIN-MV5EI577EPEDesktopСертификат аутентификации ЦР .p7b. Дополнительная информация об ошибке: В хранилищах не найден сертификат по открытому ключу. Возможно ответ не предназначался для данной системы или сертификат уже был успешно установлен. Если выбираю Использовать сертификат из хранилища — то: ОШИБКА Не удалось установить соединение с ЦС, используя адрес https://localhost/ca/ и сертификат cert://LocalMachine/My/(куча цифр и букв). Дополнительная информация об ошибке: Не удается установить доверительные отношения для защищенного канала SSL/TSL с полномочиями «localhost». Базовое соединение закрыто: Не удается установить доверительные отношения для защищенного канала SSL/TSL. Удаленный сертификат недействителен согласно результатам проверки подлинности. Настройкой УЦ занимаюсь в первые, многого не знаю. Подскажите в чем проблема. Спасибо
	WWW

Захар Тихонов	#2 Оставлено : 22 июля 2020 г. 11:57:53(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 17.08.2015(UTC) Сообщений: 3,083 Откуда: Калининград Сказал «Спасибо»: 38 раз Поблагодарили: 553 раз в 530 постах	Здравствуйте. Если актуально, то я бы порекомендовал поверить dns имя в веб сертификате.
Техническую поддержку оказываем тут. Наша база знаний.

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

В режиме Online программа WM Keeper WinPro устанавливает соединение с сервером сертификации системы через порт 2802 TCP. Сообщение «Не удалось установить соединение с центром сертификации» означает, что этот порт у Вас закрыт, и Вам необходимо его открыть.

Проверьте наличие доступа к серверам сертификации через TCP порт 2802:

Для этого в меню Windows Пуск-Выполнить наберите cmd, нажмите ОК, затем в открывшемся окне введите

telnet (IP-адрес сервера сертификации) 2802 и нажмите «Enter».

Откроется окно с пустым экраном.

При нажатии клавиши Enter в окне должно быть сообщение об утрате соединения.

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

Если при проверке наличия доступа к серверам сертификации через TCP порт 2802 вы получаете ошибку, как показано на скриншоте:

«telnet не является внутренней или внешней командой», это означает, что у вас в windows отключена служба сервера telnet.

Для включения службы сервера telnet в windows выполните следующие действия:

Пуск (Start) -> Панель управления(Control Panel) -> Программы и компоненты (Programs and Features) -> Включение или отключение компонентов Windows (Turn Windows features on or off) -> Выбрать пункт «Клиент Telnet» (Telnet Client) -> ОК

Подробнее о включении службы сервера telnet вы можете ознакомиться здесь

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

В настоящий момент сервера сертификации имеют доменные имена

wmsc1.webmoney.ru, IP адреса:

212.118.48.13, 212.118.48.133, 212.118.48.6, 212.118.48.5, 212.118.48.138,
212.118.48.132, 212.118.48.131, 212.118.48.129, 212.118.48.7, 212.118.48.136,
212.118.48.130, 212.118.48.137, 212.118.48.139, 212.118.48.135

wmsc2.webmoney.ru, IP адреса:

212.118.48.178, 91.227.52.146, 91.200.28.146, 91.227.52.145, 212.118.48.179,
91.200.28.145, 212.118.48.180, 91.200.28.147, 212.118.48.177, 91.200.28.148,
91.227.52.148, 91.227.52.144, 91.200.28.144, 91.227.52.147, 212.118.48.176

wmsc3.webmoney.ru, IP адреса:

91.227.52.142, 91.227.52.133, 91.227.52.137, 91.227.52.135, 91.227.52.134,
91.227.52.131, 91.227.52.138, 91.227.52.143, 91.227.52.129, 91.227.52.130,
91.227.52.141, 91.227.52.139, 91.227.52.132, 91.227.52.140, 91.227.52.136

wmsc4.webmoney.ru, IP адреса:

91.200.28.138, 91.200.28.130, 91.200.28.142, 91.200.28.129, 91.200.28.136,
91.200.28.139, 91.200.28.134, 91.200.28.131, 91.200.28.132, 91.200.28.137,
91.200.28.133, 91.200.28.140, 91.200.28.135, 91.200.28.143, 91.200.28.141

Программа WM Keeper WinPro не имеет встроенного прокси-клиента, поэтому при работе через прокси-сервер необходимо использовать отдельную программу прокси-клиента. Такие программы поставляются как в составе прокси-сервера, так и отдельно.

В зависимости от типа и версии прокси-сервер может требовать различной настройки. Кроме того, в некоторых случаях настройка прокси-сервера бывает невозможна (например, из-за отсутствия доступа к нему). Здесь решением проблемы может стать использование программ, позволяющих «обходить» прокси-серверы:WinGate, UserGate 3.0.

Ниже приведены рекомендации по работе с различными прокси-серверами и программами.

• Настройка прокси сервера WinGate
• Настройка прокси сервера UserGate

Если же проверка дала положительный результат (открылось пустое чёрное окно и после нажатия любой клавиши на экране появилось сообщение о том что соединение утрачено), а Кипер не подключается, попробуйте также сделать следующее: найдите файл под названием «hosts» ( без расширения). Для этого, в WindowsNT/2000 он размещается в каталоге System32/drivers/etc, в Windows9x — в корневом каталоге системы. В Windows9x вместо файла hosts может находиться только файл hosts.sam. В этом случае создайте файл hosts и скопируйте в него содержимое файла hosts.sam.

Добавьте в конец файла такую запись —

212.118.48.178 wmsc2.webmoney.ru
92.227.52.132 wmsc3.webmoney.ru
91.200.28.138 wmsc4.webmoney.ru
212.118.48.136 wmsc1.webmoney.ru
92.227.52.133 wmsc3.webmoney.ru
212.118.48.132 wmsc1.webmoney.ru
212.118.48.139 wmsc1.webmoney.ru

если файла «hosts» нет, создайте его, и поместите в него вышеприведённые строки.

Если это не изменит ситуацию с Кипером:

• попробуйте переустановить программу;
• проверьте Ваши брандмауэры и прокси-сервера (если таковые есть) на предмет блокировок по порту;
• обратитесь к Вашему провайдеру (или системному администратору) на предмет ограничений по прохождению пакетов по TCP порту 2802. (ограничений в обе стороны, по длине пакетов и.т.д.).

DamnCliffracers	#1 Оставлено : 5 мая 2022 г. 10:55:10(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 10.02.2017(UTC) Сообщений: 22	Добрый день. Столкнулись с проблемой — в Консоли ЦР в разделе «Центры сертификации» при проверке связи с ЦС возникает ошибка: Цитата: С центром сертификации нет связи, либо служба центра регистрации не может в анстоящее время обрабатывать запросы. Результат выполнения команды Ping-CA: Цитата: Ping-CA : Ошибка соединения с центром сертификации ООО <ИЖТЕНДЕР>. Запрос HTTP не разрешен для схемы аутентификации клиента «Anonymous». От сервер а получен заголовок аутентификации «». Удаленный сервер возвратил ошибку: (401) Несанкционированный. строка:1 знак:1 + Ping-CA ‘ООО <ИЖТЕНДЕР>’ + ~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Ping-CA], InvalidOperatio nException + FullyQualifiedErrorId : UnhandledError,RegistrationService.Commands.Ping CACommand Нашли рекомендуемое решение этой ошибки, но есть вопрос: обязательно ли нужно создавать новый клиентский сертификат или можно заново настроить соединение с тем сертификатом, который используется в данный момент?

Захар Тихонов	#2 Оставлено : 5 мая 2022 г. 12:20:40(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 17.08.2015(UTC) Сообщений: 3,083 Откуда: Калининград Сказал «Спасибо»: 38 раз Поблагодарили: 553 раз в 530 постах	Здравствуйте. Проверьте что права у учетной записи windows, которая закреплена под ЦР, имеет права в Безопасность и Аудит в свойствах ЦС. Да, если ключ действующий, то можно не перевыпускать. Протестируйте контейнер и убедитесь что он действующий.
Техническую поддержку оказываем тут. Наша база знаний.

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации PKI от Microsoft — Active Directory Certificate Services:

• Общие представления о PKI
• Автоматический запрос сертификатов
• Ручная установка сертификата корневого ЦС
• Проверка отзыва сертификатов
• Веб-службы регистрации сертификатов
• Запрос сертификата с альтернативным именем
• Обобщенные лучшие практики
• Полезные ссылки

Общие представления о PKI

Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:

• Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
• отношения всеобщего доверия к ЦС
• выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
• различные службы поддержки PKI
  • списки отзывов сертификатов (CRL)
  • сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
  • Web Enrollment (средство запроса сертификатов через Web)

Автоматический запрос сертификатов

От центра сертификации нет толку, если клиентские компьютеры в вашей сети не имеют к нему доверия и/или не получают сертификаты. При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС и автоматический запрос сертификатов компьютера у него. Однако, при некоторых сценариях эти политики необходимо настраивать вручную и в этом поможет статья TechNet Configure Computer Certificate Autoenrollment.

Ручная установка сертификата корневого ЦС

Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации. Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:

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

Через MMC

Открыть MMC с правами администратора » добавить оснастку Сертификаты » выбрать в качестве области Локальный компьютер » импортировать нужный сертификат в хранилище Доверенные корневые центры сертификации. Более подробно в статье TechNet Manage Trusted Root Certificates.

Через свойства сертификата

Запустить командную строку с правами админа » вызвать в ней с:pathtocert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.

Через командную строку

Потребуется утилита CertMgr, с помощью нее нужно выполнить следующую команду:

certmgr.exe -add -c «с:pathtocert.crt» -s -r localMachine root

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

Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:

Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:

• CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
• Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)

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

За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation. От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.

Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network. Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.

Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:

certutil -url name.cer

где name.cer — имя выданного сертификата.

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

Веб-службы регистрации сертификатов

Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:

• запрашивать сертификаты пользователями без участия администратора
• предоставлять по требованию сертификат корневого ЦС
• выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
• делать это все через интернет
• сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС

Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов

• в случае установки Web Enrollment на отличный от ЦС компьютер, необходимо обязательно выполнить шаги, описанные в статье TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account, иначе служба не будет работать, выдавая следующую ошибку:

• та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
• при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS

Запрос сертификата с альтернативным именем

Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).

По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:

certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Запрос через консоль MMC

Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…

• В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
• Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
• Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.

Запрос через утилиту certreq

Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq. Чтобы создать сертификат нужно действовать по следующему алгоритму:

1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.

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

certreq -new request.inf

Нам предложат сохранить подготовленный файл запроса в формате .req. Одновременно с этим в хранилище сертификатов компьютера будет сохранен закрытый ключ для будущего сертификата.

3. Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).

4. Выполнить установку полученного сертификата на целевой компьютер следующей командой

certreq -accept request.cer

5. PROFIT. В результате описанных действий в хранилище сертификатов компьютера будет создан сертификат с закрытым ключом, пригодный для авторизации сервера по нескольким именами, прописанным .inf файле.

Обобщенные лучшие практики

Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2

• На контроллере домена развернут корневой центр сертификации
• Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
• В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
• На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
  • Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
  • Online Responder для проверки отзыва сертификатов по протоколу OCSP
• Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
  • Remote Desktop Gateway
  • Outlook Web Access
  • DirectAccess
  • SharePoint

Полезные ссылки

• PKI предприятия
• How to configure the Windows Server 2008 CA Web Enrollment Proxy
• How to add a Subject Alternative Name to a secure LDAP certificate
• How to Request a Certificate With a Custom Subject Alternative Name
• Устанавливаем Certification Authority — Vadims Podans’s blog
• OCSP (часть 1), OCSP (часть 2) — Vadims Podans’s blog