- Remove From My Forums
-
Вопрос
Ответы
-
Победил публикацию через инет, никаких хитростей в TMG настраивать не пришлось, работает от любого имени.
Что было сделано
- Для компа с CA Web Enroll включено делегирование на все протоколы аутентификации, сервисы prcss и HOST на комп c CA
- Создан в IIS AppPool, работающий от имени NetworkService, этот пул был назначен для приложения CertSrv
- В разделе CertSrv > Authentication была включен пункт Basic Auth, а в свойcтвах Windows Auth был отключен Kernel-mode auth
- В advanced свойствах приложения CertSrv свойтсов LogonType было переключено с Network на ClearText
- Перезапуск IIS через команду iisreset, релогин на комп с CA Web Enroll
Так как basic auth посылает логин/пароль в виде открытого текста, естественно, используется SSL.
MCITP: Enterprise Administrator, MCSA
-
Помечено в качестве ответа
19 апреля 2010 г. 6:56
-
Почитал приведённые вами ссылки и понял откуда ростут ноги у этой ошибки — при попытке скачать корневой сертификат/цепочку/CRL. Верно:)?
В общем, в учётной записи вашего Web-сервера настройте ограниченное делегирование на SPN’ы HOST и rpcss, вашего CA/контроллера домена. На самом Web-сервере в настройках пула, в котором работает приложение CertSrv выберите NetworkService, а в настройках аутентификации приложения включите интегрированную аутентификацию и выключите ядерную аутентификацию. Перезапустите IIS, перезайдите на рабочей станции, чтоб настройка делегирования заработала и всё должно получиться…
-
Помечено в качестве ответа
Argon.proMicrosoft employee
16 апреля 2010 г. 21:39
-
Помечено в качестве ответа
- Remove From My Forums
-
Question
-
Hi everyone:
I have two tier-PKI with server-1 as sub-ordinate enterprise/issuing CA. I have installed ‘Certificte Authority Web Enrollment’ on Server-2. when I open Server-2.domain.com/certsrv and go to »Download a CA certificate, certificate chain or CRL’ it returns
‘Error: An unexpected error has occurred: The Certification Authority Service has not been started.’ However it works fine from https://localhost/certsrv on server-2.My problem is same as in the following thread and I have tried the solution advised but it hasn’t worked for me:
https://social.technet.microsoft.com/Forums/en-US/4c7f41a5-21b0-470d-8c78-0fc237eb1da0/web-enrollemet-page-giving-error-quot-an-unexpected-error-has-occurred-the-certification?forum=winserversecurity
I have tried the following but nothing has changed:
https://support.microsoft.com/en-gb/help/300867/error-message-the-certification-authority-service-has-not-been-started
https://blogs.technet.microsoft.com/askds/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy/
Please advise if I am missing something. Many thanks
- Remove From My Forums
-
Вопрос
Ответы
-
Победил публикацию через инет, никаких хитростей в TMG настраивать не пришлось, работает от любого имени.
Что было сделано
- Для компа с CA Web Enroll включено делегирование на все протоколы аутентификации, сервисы prcss и HOST на комп c CA
- Создан в IIS AppPool, работающий от имени NetworkService, этот пул был назначен для приложения CertSrv
- В разделе CertSrv > Authentication была включен пункт Basic Auth, а в свойcтвах Windows Auth был отключен Kernel-mode auth
- В advanced свойствах приложения CertSrv свойтсов LogonType было переключено с Network на ClearText
- Перезапуск IIS через команду iisreset, релогин на комп с CA Web Enroll
Так как basic auth посылает логин/пароль в виде открытого текста, естественно, используется SSL.
MCITP: Enterprise Administrator, MCSA
- Помечено в качестве ответа
19 апреля 2010 г. 6:56
-
Почитал приведённые вами ссылки и понял откуда ростут ноги у этой ошибки — при попытке скачать корневой сертификат/цепочку/CRL. Верно:)?
В общем, в учётной записи вашего Web-сервера настройте ограниченное делегирование на SPN’ы HOST и rpcss, вашего CA/контроллера домена. На самом Web-сервере в настройках пула, в котором работает приложение CertSrv выберите NetworkService, а в настройках аутентификации приложения включите интегрированную аутентификацию и выключите ядерную аутентификацию. Перезапустите IIS, перезайдите на рабочей станции, чтоб настройка делегирования заработала и всё должно получиться…
- Помечено в качестве ответа
Argon.proMicrosoft employee
16 апреля 2010 г. 21:39
- Помечено в качестве ответа
В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации 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 будет выдаваться такая ошибка:
Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов «server.argon.com.ru». Подключаться к серверам без удостоверений небезопасно.
This computer can’t verify the identity of the RD «server.argon.com.ru». It’s not safe to connect to servers that can’t be identified.
Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Через 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, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат.
A revocation check could not be perfomed for the certificate.
Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:
- 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, иначе служба не будет работать, выдавая следующую ошибку:
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена.
An unexpected error has occurred: The Certification Authority Service has not been started.
- та же ошибка будет выдаваться, если 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 запроса сертификата со следующим содержанием.
[Version]
Signature=»$Windows NT$»
[NewRequest]
Subject = «CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU»
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
FriendlyName = «server.argon.local with SAN»
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer
[Extensions]
2.5.29.17 = «{text}»
_continue_ = «DNS=*.argon.com.ru&»
_continue_ = «DNS=argon.com.ru&»
_continue_ = «DNS=server.argon.local&»
_continue_ = «DNS=server&»
_continue_ = «DNS=localhost»
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
Hello
I have two Windows Server 2008 R2 Servers. One is a domain controller and also hosts the certification authority and the other is a member server.
I have the web enrollment on the domain controller and this works fine.
I then tried to install the web enrollment onto the other server so that it would be avilable over the internet (mainly in order to be able to provide instructions on how to download the CA root cert.
However while I can access it internally using http://server/certsrv I cannot get it to work if I access it externally or internally if I use the FQDN.
While I can still login and access the page I cannot download a CA certificate or request a certificate.
I can however use the FQDN of the server hosting the CA and that will still work.
No firewalls are enabled between the servers and port 80 and 443 are forwarded to the server where I am trying to get the web enrolment to work.
I can install a whole new subordinate CA onto the secondary server and this works externally and using the FQDN as well but this defeats the purpose as I want to use it for people to download the CA certificate but all they can get is the subordinate CA certificate which still doesn’t enable trust.
This makes me think that delegation isn’t working properly or I am missing something obvious!
Clicking on «Download a CA certificate, certificate chain, or CRL» results in:Trying to request a user certificate results in:What I have tried:
I have tried re-installing the web enrollment but it didn’t help.
I have tried giving delegation permissions to the server (right-click in ADUC and click properties and the delegation tab and choose «Trust this computer to delegation to any service»).
I have looked at the permissions for CertSrv Request and tried changing a few (giving everyone rights to lauch and activation etc)
Neither of these made any difference though.
I’m not sure what to try.
Both servers are relatively new installs (few weeks).
I have found a few similar problems on the internet which go back as far as Windows 2000 Server but I just can’t seem to get this working.
Thanks for any help.
Robin
An unexpected error has occurred: The Certification Authority Service has not been started.
Your request failed. An error occurred while the server was processing your request. Contact your administrator for further assistance. Request Mode: newreq - New Request Disposition: (never set) Disposition message: (none) Result: The RPC server is unavailable. 0x800706ba (WIN32: 1722) COM Error Info: CCertRequest::Submit: The RPC server is unavailable. 0x800706ba (WIN32: 1722) LastStatus: The operation completed successfully. 0x0 (WIN32: 0) Suggested Cause: This error can occur if the Certification Authority Service has not been started.
Robin Wilson
Hello
I have two Windows Server 2008 R2 Servers. One is a domain controller and also hosts the certification authority and the other is a member server.
I have the web enrollment on the domain controller and this works fine.
I then tried to install the web enrollment onto the other server so that it would be avilable over the internet (mainly in order to be able to provide instructions on how to download the CA root cert.
However while I can access it internally using http://server/certsrv I cannot get it to work if I access it externally or internally if I use the FQDN.
While I can still login and access the page I cannot download a CA certificate or request a certificate.
I can however use the FQDN of the server hosting the CA and that will still work.
No firewalls are enabled between the servers and port 80 and 443 are forwarded to the server where I am trying to get the web enrolment to work.
I can install a whole new subordinate CA onto the secondary server and this works externally and using the FQDN as well but this defeats the purpose as I want to use it for people to download the CA certificate but all they can get is the subordinate CA certificate which still doesn’t enable trust.
This makes me think that delegation isn’t working properly or I am missing something obvious!
Clicking on «Download a CA certificate, certificate chain, or CRL» results in:Trying to request a user certificate results in:What I have tried:
I have tried re-installing the web enrollment but it didn’t help.
I have tried giving delegation permissions to the server (right-click in ADUC and click properties and the delegation tab and choose «Trust this computer to delegation to any service»).
I have looked at the permissions for CertSrv Request and tried changing a few (giving everyone rights to lauch and activation etc)
Neither of these made any difference though.
I’m not sure what to try.
Both servers are relatively new installs (few weeks).
I have found a few similar problems on the internet which go back as far as Windows 2000 Server but I just can’t seem to get this working.
Thanks for any help.
Robin
An unexpected error has occurred: The Certification Authority Service has not been started.
Your request failed. An error occurred while the server was processing your request. Contact your administrator for further assistance. Request Mode: newreq - New Request Disposition: (never set) Disposition message: (none) Result: The RPC server is unavailable. 0x800706ba (WIN32: 1722) COM Error Info: CCertRequest::Submit: The RPC server is unavailable. 0x800706ba (WIN32: 1722) LastStatus: The operation completed successfully. 0x0 (WIN32: 0) Suggested Cause: This error can occur if the Certification Authority Service has not been started.
Robin Wilson
- Remove From My Forums
-
Question
-
Hi everyone:
I have two tier-PKI with server-1 as sub-ordinate enterprise/issuing CA. I have installed ‘Certificte Authority Web Enrollment’ on Server-2. when I open Server-2.domain.com/certsrv and go to »Download a CA certificate, certificate chain or CRL’ it returns
‘Error: An unexpected error has occurred: The Certification Authority Service has not been started.’ However it works fine from https://localhost/certsrv on server-2.My problem is same as in the following thread and I have tried the solution advised but it hasn’t worked for me:
https://social.technet.microsoft.com/Forums/en-US/4c7f41a5-21b0-470d-8c78-0fc237eb1da0/web-enrollemet-page-giving-error-quot-an-unexpected-error-has-occurred-the-certification?forum=winserversecurity
I have tried the following but nothing has changed:
https://support.microsoft.com/en-gb/help/300867/error-message-the-certification-authority-service-has-not-been-started
https://blogs.technet.microsoft.com/askds/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy/
Please advise if I am missing something. Many thanks
- Remove From My Forums
-
Question
-
Hi everyone:
I have two tier-PKI with server-1 as sub-ordinate enterprise/issuing CA. I have installed ‘Certificte Authority Web Enrollment’ on Server-2. when I open Server-2.domain.com/certsrv and go to »Download a CA certificate, certificate chain or CRL’ it returns
‘Error: An unexpected error has occurred: The Certification Authority Service has not been started.’ However it works fine from https://localhost/certsrv on server-2.My problem is same as in the following thread and I have tried the solution advised but it hasn’t worked for me:
https://social.technet.microsoft.com/Forums/en-US/4c7f41a5-21b0-470d-8c78-0fc237eb1da0/web-enrollemet-page-giving-error-quot-an-unexpected-error-has-occurred-the-certification?forum=winserversecurity
I have tried the following but nothing has changed:
https://support.microsoft.com/en-gb/help/300867/error-message-the-certification-authority-service-has-not-been-started
https://blogs.technet.microsoft.com/askds/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy/
Please advise if I am missing something. Many thanks
Форум КриптоПро
»
КриптоПро УЦ
»
КриптоПро УЦ 2.0
»
Ошибка Службы сертификатов (не загружается ключ администратора ЦС)
 VIT04 |
|
|
Статус: Активный участник Группы: Участники
Зарегистрирован: 30.09.2013(UTC) Сказал(а) «Спасибо»: 6 раз |
Добрый день! |
 |
|
|
Станислав Королёв |
|
|
Статус: Сотрудник Группы: Участники Зарегистрирован: 06.11.2014(UTC) Поблагодарили: 27 раз в 27 постах |
Добрый день, На ЦС выполните команду certutil.exe -verify «путь к файлу вашего сертификата» |
|
|
|
|
VIT04 |
|
|
Статус: Активный участник Группы: Участники
Зарегистрирован: 30.09.2013(UTC) Сказал(а) «Спасибо»: 6 раз |
Проверка прошла успешно. |
|
|
|
2223.txt |
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники
Зарегистрирован: 17.08.2015(UTC) Сказал «Спасибо»: 35 раз |
Установите сертификаты минкомсвязи и свой + все CRL в локальную машину. После попробуйте загрузить ключи. |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
VIT04 |
|
|
Статус: Активный участник Группы: Участники Зарегистрирован: 30.09.2013(UTC) Сказал(а) «Спасибо»: 6 раз |
Установил 2 корневых Минкомсвязи, 2 списка отозванных. Цепочка сертификатов строится, certutil.exe -verify ошибок не находит. Пробую установить через командную строку согласно руководству, выходит сообщение certutil2: Неверное число аргументов, ожидаемое число аргументов: не более 3. Получено 4 |
|
|
|
|
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники
Зарегистрирован: 17.08.2015(UTC) Сказал «Спасибо»: 35 раз |
из 2х сертификатов минкомсвязи — один корневой, один промежуточный, а также ваш промежуточный. CRL установлены в локальную машину, все 3? |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
VIT04 |
|
|
Статус: Активный участник Группы: Участники Зарегистрирован: 30.09.2013(UTC) Сказал(а) «Спасибо»: 6 раз |
Да, сертификаты так установили, а вот CRL установлены только 2 Минкомсвязи, какой третий? Через powershell удалось выполнить команду загрузки ключей, после чего сообщение службы сертификатов сменилось на «Недоступен центр сертификации», ошибка при обновлении. |
|
|
|
|
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники Зарегистрирован: 17.08.2015(UTC) Сказал «Спасибо»: 35 раз |
3тий crl от вашего УЦ. «Недоступен центр сертификации», запустите агент от имени администратора. |
|
Техническую поддержку оказываем тут. |
|
|
|
|
|
VIT04 |
|
|
Статус: Активный участник Группы: Участники Зарегистрирован: 30.09.2013(UTC) Сказал(а) «Спасибо»: 6 раз |
Агента запускаю от имени администратора, ситуация не меняется. CRL нашего УЦ еще не выпускались, УЦ только разворачиваем, в журнале Сервера ЦС списков отзыва нет. Попытка выпустить принудительно заканчивается ошибкой, т.к. не загружен ключ администратора ЦС. |
|
|
|
|
Захар Тихонов |
|
|
Статус: Сотрудник Группы: Участники Зарегистрирован: 17.08.2015(UTC) Сказал «Спасибо»: 35 раз |
авторизуйтесь под пользователем, кому принадлежит Ключ ЦС. и под ним запустите Агент управления ключами. |
|
Техническую поддержку оказываем тут. |
|
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Форум КриптоПро
»
КриптоПро УЦ
»
КриптоПро УЦ 2.0
»
Ошибка Службы сертификатов (не загружается ключ администратора ЦС)
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации 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 будет выдаваться такая ошибка:
Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов «server.argon.com.ru». Подключаться к серверам без удостоверений небезопасно.
This computer can’t verify the identity of the RD «server.argon.com.ru». It’s not safe to connect to servers that can’t be identified.
Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Через 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, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат.
A revocation check could not be perfomed for the certificate.
Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:
- 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, иначе служба не будет работать, выдавая следующую ошибку:
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена.
An unexpected error has occurred: The Certification Authority Service has not been started.
- та же ошибка будет выдаваться, если 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 запроса сертификата со следующим содержанием.
[Version]
Signature=»$Windows NT$»
[NewRequest]
Subject = «CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU»
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
FriendlyName = «server.argon.local with SAN»
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer
[Extensions]
2.5.29.17 = «{text}»
_continue_ = «DNS=*.argon.com.ru&»
_continue_ = «DNS=argon.com.ru&»
_continue_ = «DNS=server.argon.local&»
_continue_ = «DNS=server&»
_continue_ = «DNS=localhost»
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
В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации 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 будет выдаваться такая ошибка:
Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов «server.argon.com.ru». Подключаться к серверам без удостоверений небезопасно.
This computer can’t verify the identity of the RD «server.argon.com.ru». It’s not safe to connect to servers that can’t be identified.
Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Через 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, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат.
A revocation check could not be perfomed for the certificate.
Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:
- 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, иначе служба не будет работать, выдавая следующую ошибку:
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена.
An unexpected error has occurred: The Certification Authority Service has not been started.
- та же ошибка будет выдаваться, если 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 запроса сертификата со следующим содержанием.
[Version]
Signature=»$Windows NT$»
[NewRequest]
Subject = «CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU»
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
FriendlyName = «server.argon.local with SAN»
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer
[Extensions]
2.5.29.17 = «{text}»
_continue_ = «DNS=*.argon.com.ru&»
_continue_ = «DNS=argon.com.ru&»
_continue_ = «DNS=server.argon.local&»
_continue_ = «DNS=server&»
_continue_ = «DNS=localhost»
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
Содержание
- «Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов»
- Active Directory Certificate Services. Компьютеру не удается проверить удостоверение шлюза рабочих столов
- Active Directory Certificate Services / Argon / Blog
- Общие представления о PKI
- Автоматический запрос сертификатов
- Ручная установка сертификата корневого ЦС
- Через MMC
- Через свойства сертификата
- Через командную строку
- Проверка отзыва сертификатов
- Веб-службы регистрации сертификатов
- Запрос сертификата с альтернативным именем
- Запрос через консоль MMC
- Запрос через утилиту certreq
- Обобщенные лучшие практики
- Полезные ссылки
- Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
- Подключения старой версии rdp client 2.1.1 к Windows Server 2012
- Решение проблемы подключения RDP клиента к Server 2012
- Смотрите также
«Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов»
Первый раз столкнулась с подключением к удаленному рабочему столу,сертификат установила но вот только при подключении возникает ошибка с таким текстом:
«Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов «server_name». Подключатся к серверам без удостоверений не безопасно. Обратитесь за помощью к администратору сети»
Подскажите что можно сделать, что бы решить эту ситуацию
Не удается подключиться через службу удаленных рабочих столов к серверу
Суть проблемы: Рабочая станция: Win 7 Enterprise, ip-адрес статический(192.168.1.167), подключен к.
Службы удаленных рабочих столов
Службы удаленных рабочих столов- коллекции (можно несколько создать коллекция и как?)
Служба удаленных рабочих столов
Здравствуйте, вопрос состоит в следующем стоит Windows server 2008 r2 как активировать службу.
Ip виртуализация удаленных рабочих столов
Добрый день! После настройки ip виртуализации удаленных рабочих столов для сеансов в Windows.
Выбрано — «Подключатся без предупреждения».
У того сертификата что мне дали, закончился строк действия. Нажав на кнопку «Просмотреть сертификат», открывается новый сертификат, я его сохранила с помощью кнопки «Копировать в файл» и потом установила этот новый сертификат. Возможно причина в этом, и мне нужно попросить что бы мне сбросили новый сертификат и потом все получится? Хотя почему не выходит если я сама его скачала и установила.
Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь или здесь.
Сервер удаленных рабочих столов
Здравствуйте. На работе установили новый сервер под управлением Windows Server 2012, настроил.
Заглючила служба удаленных рабочих столов
Здравствуйте. История такова. Мне потребовалось организовать поддержку нескольких одновременных.
Сервер лицензирования удалённых рабочих столов
Здравствуйте, Win 2008R2, 64x, SuperMicro Столкнулся с такой проблемой: Поднял терминальный.
Установка роли удаленных рабочих столов
Здравствуйте! При установки роли удаленных рабочих столов появляется ошибка (вложения). Как это.
Active Directory Certificate Services. Компьютеру не удается проверить удостоверение шлюза рабочих столов
Active Directory Certificate Services / Argon / Blog
В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации PKI от Microsoft — Active Directory Certificate Services:
Общие представления о 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 будет выдаваться такая ошибка:
Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов «server.argon.com.ru». Подключаться к серверам без удостоверений небезопасно. This computer can’t verify the identity of the RD «server.argon.com.ru». It’s not safe to connect to servers that can’t be identified. Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Через 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, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат. A revocation check could not be perfomed for the certificate.
Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:
- CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
- Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)
Для работы обоих вариантов необходимо, чтобы в центре сертификации были заблаговременно настроены доступные из интернета адреса этих служб, так как эти адреса жестко прописываются в каждом выдаваемом сертификате.
Настройка и публикация 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 проста и тривиальна за исключением следующих моментов
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена. An unexpected error has occurred: The Certification Authority Service has not been started.
- та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
Запрос сертификата с альтернативным именем
Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен 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 запроса сертификата со следующим содержанием.
[Version] Signature=»$Windows NT$»
[NewRequest] Subject = «CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU» KeySpec = 1 KeyLength = 2048 HashAlgorithm = SHA256 Exportable = TRUE MachineKeySet = TRUE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE RequestType = PKCS10 KeyUsage = 0xa0 ProviderName = «Microsoft RSA SChannel Cryptographic Provider» FriendlyName = «server.argon.local with SAN»
[EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes] CertificateTemplate = WebServer
[Extensions] 2.5.29.17 = «» _continue_ = «DNS=*.argon.com.ru&» _continue_ = «DNS=argon.com.ru&» _continue_ = «DNS=server.argon.local&» _continue_ = «DNS=server&» _continue_ = «DNS=localhost»
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
Полезные ссылки
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
В связи с недавними обновлениями безопасности Windows, закрывающее уязвимости в протоколе CredSSP, парочка маков (mac mini середины 2007 года) потеряли доступ к терминальному серверу на базе Windows Server 2008R2.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
Дело в том, что старая версия маковского rdp client 2.1.1 от Microsoft, ставшая последней доступной для Mac OS X 10.7 (Lion), не работает не только с Windows Server 2012, но после вышеупомянутого обновления перестала подключаться и к WinServer 2008R2. В природе существует и неофициальная версия rdp-клиента 2.1.2, однако разыскивать её, нет особого резона — результат будет аналогичным.
Установка галки «Подключаться даже если проверка подлинности завершается с ошибкой» в настройках RDP клиента (Свойства -> Безопасность) тоже никак не влияет на результат подключения.
Актуальные, на данный момент, клиенты Microsoft Remote Desktop 8.0 (совместима с OS X 10.9 и выше) и Microsoft Remote Desktop 10.0 (macOS 10.10 и выше) поставить на старую систему OS X не представляется возможным. Из вменяемых альтернатив, можно выделить, пожалуй, только Parallels Client. и вроде вот оно счастье, ведь в минимальных требованиях значится Mac OS X 10.7.3, однако не стоит верить всему что пишут. Хоть программа и благополучно устанавливается, позволяет внести данные о вашем подключении, однако вылетает на попытке соединения с сервером вываливая кучу ошибок.
От безысходности можно пойти от обратного, изменив работу службы удаленных рабочих столов на сервере (метод работает и на Windows Server 2012), однако лучшим вариантом станет замена клиентской машины.
Подключения старой версии rdp client 2.1.1 к Windows Server 2012
Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:
Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Безопасность
Здесь следует поменять значение двух параметров:
- Требовать использования специального уровня безопасности для удаленных подключений по методу RDP (ставим «Включить», а уровень безопасности выбираем «RDP»)
- Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (ставим «Отключить»)
Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.
Если считаете статью полезной,не ленитесь ставить лайки и делиться с друзьями.
Решение проблемы подключения RDP клиента к Server 2012
Делал терминальный доступ на Windows Server 2012 R2 и решил извратиться, сменив порты доступа с дефолтных на пятизначные, для затруднения обнаружения оных в результате сканирования портов.
И тут возникла проблема, что люди не могут залогиниться с Mac OS, при этом к имевшимся уже в наличии Server 2008 логинятся нормально. А в случае 2012 винды, сторонние RDP клиенты просто не видят сервера, а родной RDP клиент для Mac OS говорит, что “Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение” либо еще какие нить ошибки.
С родного виндового RDP клиента, из под 7ки, вообще никаких проблем.
Сначала решил было, что это проблема работы на измененных портах, но дефолтные RDP также не оживили ситуацию.
черный экран RDP клиента при подключении к Windows Server 2012
Погуглив, выяснил, что старые версии макаковского RDP клиента не поддеррживаются в Server 2012 и поэтому надо ставить 8.X+. В данный момент актуальная версия MS RDP for Mac 8.0.14, которая в свою очередь просто стала виснуть на установлении сессии. Не помогла и галка в настройках RDP клиента Свойства -> Безопасность -> Подключаться даже если проверка подлинности завершается с ошибкой. Причем на мелкомягком сайте народ в основном матерился на последние версии клиента 8.013 и 8.0.14.
В связи с чем решил идти от обратного и вместо того, чтобы закручивать гайки для RDP соединения с Server 2012 немного их ослабить.
Вызываем обшиву групповых политик Ctrl+R -> gpedit где проходим в раздел настроек безопасности RDP: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Dekstop Session Host
после чего меняем значения двух параметров:
Require use of specific security layer for remote desktop (RDP) connection = EnableRequire user authentication for remote connections by using Network Level Authentication = Disable
В таком варианте Microsoft Remote Desktop app, даже старой версии, начинает подключаться к RDP Server 2012, но только по дефолтному порту 3389, т.к в случае его изменения на нестандартный, не проходит пароль.
Для того чтобы заработал RDP клиент и на нестандартном порту, пришлось изменить еще несколько значений, как на изображении.
Настройки безопасности RDP на Windows Server 2012 для корректной работы MaC OS клиентов
Rating: 10.0/10 (5 votes cast)
Rating: +3 (from 3 votes)
Проблема подключения Mac- клиента RDP к Server 2012, 10.0 out of 10 based on 5 ratings
Смотрите также
Koto-Fot | Все права защищены © 2018 | Карта сайта