Создать запрос на сертификат windows server

Обновлено: 04.07.2024

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

Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (PKI) и службы сертификации Windows.

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

Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

Для создания центра сертификации нам понадобится сервер, работающий под управлением Windows Server, который может быть как выделенным, так и совмещать роль центра сертификации с другими ролями. Однако следует помнить, что после развертывания центра сертификации вы не сможете поменять имя компьютера и его принадлежность к домену (рабочей группе).

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

ЦС предприятия

  • Требует наличия ActiveDirectory
  • Автоматическое подтверждение сертификатов
  • Автоматическое развертывание сертификатов
  • Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

Изолированный (автономный) ЦС

  • Не требует наличия ActiveDirectory
  • Ручное подтверждение сертификатов
  • Отсутствие возможности автоматического развертывания
  • Запрос сертификатов только через Web-интерфейс

Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

Windows Server 2003

После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ - Установка компонентов Windows, где выбираем Службы сертификации.

certsrv-002.jpg

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

Windows Server 2008 R2

В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера - Роли - Добавить роли, в списке ролей выбираем Службы сертификации Active Directory.

certsrv-004.jpg

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

certsrv-005.jpg

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

Проверка работы ЦС

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

При попытке создать запрос сертификата вы можете получить следующее предупреждение:

certsrv-009.jpg

В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

certsrv-011.jpg

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

certsrv-012.jpg

Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.

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

Более ранние версии команды certreq могут не предоставлять все описанные здесь параметры. Чтобы просмотреть Поддерживаемые параметры на основе конкретных версий средства certreq, выполните команду справки командной строки, certreq -v -? .

Команда certreq не поддерживает создание нового запроса на сертификат на основе шаблона аттестации ключей в среде CEP/CES.

содержимое этого раздела основано на параметрах по умолчанию для Windows Server; например, можно задать длину ключа 2048, выбрать поставщик программных ключей майкрософт служба хранилища поставщика CSP и использовать алгоритм SHA-1 (SHA1). Оцените эти варианты в соответствии с требованиями политики безопасности вашей компании.

Синтаксис

Параметры

Примеры

certreq — отправка

Комментарии

Сведения о запросе сертификата путем указания атрибута SAN см. в разделе Использование служебной программы certreq.exe для создания и отправки запроса на сертификат в статье базы знаний Майкрософт 931351 Добавление альтернативного имени субъекта к защищенному сертификату LDAP.

certreq — получение

Чтобы получить сертификат с ИДЕНТИФИКАТОРом 20 и создать файл сертификата (CER) с именем мойсертификат:

Комментарии

Используйте certreq — получение RequestId для получения сертификата после его выдачи центром сертификации. Идентификатор RequestId ПКК может быть десятичным или шестнадцатеричным с префиксом 0x. он может быть серийным номером сертификата без префикса 0x. Его также можно использовать для получения сертификата, который когда-либо был выдан центром сертификации, включая отозванные или просроченные сертификаты, независимо от того, находится ли запрос сертификата в состоянии ожидания.

certreq — new

Создание нового запроса:

Ниже приведены некоторые из возможных разделов, которые можно добавить в INF-файл.

newRequest

Эта область INF-файла является обязательной для всех новых шаблонов запросов сертификатов и должна включать хотя бы один параметр со значением.

  • CERT_DIGITAL_SIGNATURE_KEY_USAGE -- 80 (128)
  • CERT_NON_REPUDIATION_KEY_USAGE -- 40 (64)
  • CERT_KEY_ENCIPHERMENT_KEY_USAGE -- 20 (32)
  • CERT_DATA_ENCIPHERMENT_KEY_USAGE -- 10 (16)
  • CERT_KEY_AGREEMENT_KEY_USAGE -- 8
  • CERT_KEY_CERT_SIGN_KEY_USAGE -- 4
  • CERT_OFFLINE_CRL_SIGN_KEY_USAGE -- 2
  • CERT_CRL_SIGN_KEY_USAGE -- 2
  • CERT_ENCIPHER_ONLY_KEY_USAGE -- 1
  • CERT_DECIPHER_ONLY_KEY_USAGE -- 8000 (32768)
  • NCRYPT_ALLOW_DECRYPT_FLAG -- 1
  • NCRYPT_ALLOW_SIGNING_FLAG -- 2
  • NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4
  • NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215)
  • PKCS10 -- 1
  • PKCS7 -- 2
  • CMC -- 3
  • Cert -- 4
  • SCEP -- fd00 (64768)
  • XCN_NCRYPT_UI_NO_PROTCTION_FLAG -- 0
  • XCN_NCRYPT_UI_PROTECT_KEY_FLAG -- 1
  • XCN_NCRYPT_UI_FORCE_HIGH_PROTECTION_FLAG -- 2

1 Параметр слева от знака равенства (=)

2 Параметр справа от знака равенства (=)

расширений

Этот раздел является необязательным.

  • AT_NONE -- 0
  • AT_SIGNATURE -- 2
  • AT_KEYEXCHANGE -- 1
  • PKCS10 -- 1
  • PKCS7 -- 2
  • CMC -- 3
  • Cert -- 4
  • SCEP -- fd00 (64768)
  • CERT_DIGITAL_SIGNATURE_KEY_USAGE -- 80 (128)
  • CERT_NON_REPUDIATION_KEY_USAGE -- 40 (64)
  • CERT_KEY_ENCIPHERMENT_KEY_USAGE -- 20 (32)
  • CERT_DATA_ENCIPHERMENT_KEY_USAGE -- 10 (16)
  • CERT_KEY_AGREEMENT_KEY_USAGE -- 8
  • CERT_KEY_CERT_SIGN_KEY_USAGE -- 4
  • CERT_OFFLINE_CRL_SIGN_KEY_USAGE -- 2
  • CERT_CRL_SIGN_KEY_USAGE -- 2
  • CERT_ENCIPHER_ONLY_KEY_USAGE -- 1
  • CERT_DECIPHER_ONLY_KEY_USAGE -- 8000 (32768)
  • NCRYPT_ALLOW_DECRYPT_FLAG -- 1
  • NCRYPT_ALLOW_SIGNING_FLAG -- 2
  • NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4
  • NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215)
  • NCRYPT_UI_NO_PROTECTION_FLAG -- 0
  • NCRYPT_UI_PROTECT_KEY_FLAG -- 1
  • NCRYPT_UI_FORCE_HIGH_PROTECTION_FLAG -- 2
  • CT_FLAG_SUBJECT_REQUIRE_COMMON_NAME -- 40000000 (1073741824)
  • CT_FLAG_SUBJECT_REQUIRE_DIRECTORY_PATH -- 80000000 (2147483648)
  • CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN -- 10000000 (268435456)
  • CT_FLAG_SUBJECT_REQUIRE_EMAIL -- 20000000 (536870912)
  • CT_FLAG_OLD_CERT_SUPPLIES_SUBJECT_AND_ALT_NAME -- 8
  • CT_FLAG_SUBJECT_ALT_REQUIRE_DIRECTORY_GUID -- 1000000 (16777216)
  • CT_FLAG_SUBJECT_ALT_REQUIRE_DNS -- 8000000 (134217728)
  • CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS -- 400000 (4194304)
  • CT_FLAG_SUBJECT_ALT_REQUIRE_EMAIL -- 4000000 (67108864)
  • CT_FLAG_SUBJECT_ALT_REQUIRE_SPN -- 800000 (8388608)
  • CT_FLAG_SUBJECT_ALT_REQUIRE_UPN -- 2000000 (33554432)
  • CERT_NAME_STR_NONE -- 0
  • CERT_OID_NAME_STR -- 2
  • CERT_X500_NAME_STR -- 3
  • CERT_NAME_STR_SEMICOLON_FLAG -- 40000000 (1073741824)
  • CERT_NAME_STR_NO_PLUS_FLAG -- 20000000 (536870912)
  • CERT_NAME_STR_NO_QUOTING_FLAG -- 10000000 (268435456)
  • CERT_NAME_STR_CRLF_FLAG -- 8000000 (134217728)
  • CERT_NAME_STR_COMMA_FLAG -- 4000000 (67108864)
  • CERT_NAME_STR_REVERSE_FLAG -- 2000000 (33554432)
  • CERT_NAME_STR_FORWARD_FLAG -- 1000000 (16777216)
  • CERT_NAME_STR_DISABLE_IE4_UTF8_FLAG -- 10000 (65536)
  • CERT_NAME_STR_ENABLE_T61_UNICODE_FLAG -- 20000 (131072)
  • CERT_NAME_STR_ENABLE_UTF8_UNICODE_FLAG -- 40000 (262144)
  • CERT_NAME_STR_FORCE_UTF8_DIR_STR_FLAG -- 80000 (524288)
  • CERT_NAME_STR_DISABLE_UTF8_DIR_STR_FLAG -- 100000 (1048576)
  • CERT_NAME_STR_ENABLE_PUNYCODE_FLAG -- 200000 (2097152)

SubjectNameFlags позволяет INF-файлу указать, какие поля SubjectNameFlags и расширения SubjectAltName должны автоматически заполняться программой Certreq на основе текущего пользователя или свойств текущего компьютера: DNS-имя, UPN и т. д. Использование шаблона Literal означает, что вместо них используются флаги имени шаблона. Это позволяет использовать один файл INF в нескольких контекстах для создания запросов с информацией о теме, зависящей от контекста.

X500NameFlags Задает флаги, передаваемые непосредственно в CertStrToName API при Subject INF keys преобразовании значения в различающееся X500NameFlags в кодировке ASN. 1.

Пример

чтобы создать файл политики (. inf) в Блокнот и сохранить его как рекуестконфиг. inf:

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

Использование синтаксиса раздела [Strings] для идентификаторов объектов и других сложностей для интерпретации данных. Новый пример синтаксиса для расширения EKU, в котором используется список идентификаторов объектов с разделителями-запятыми:

certreq — Accept

–accept Параметр связывает ранее созданный закрытый ключ с выданным сертификатом и удаляет ожидающий запрос сертификата из системы, в которой запрошен сертификат (при наличии соответствующего запроса).

Чтобы вручную принять сертификат, сделайте следующее:

С помощью -accept параметра с -user параметрами и –machine указывается, следует ли устанавливать сертификат установки в контексте -accept или -user . Если в любом контексте, соответствующем установленному открытому ключу, есть необработанный запрос, эти параметры не нужны. Если нет необработанных запросов, необходимо указать один из них.

certreq — политика

Файл Policy. INF — это файл конфигурации, определяющий ограничения, применяемые к сертификации ЦС при определении квалифицированного подчинения.

Чтобы создать перекрестный запрос сертификатов, выполните следующие действия.

certreq -policy При использовании без какого-либо дополнительного параметра открывается диалоговое окно, позволяющее выбрать запрошенный файл (. req,. CMC, .txt,. der,. cer или. CRT). После выбора требуемого файла и нажатия кнопки Открытьоткрывается другое диалоговое окно, в котором можно выбрать файл Policy. INF.

Примеры

Найдите пример файла Policy. INF в синтаксисе CAPolicy. INF.

certreq-Sign

Чтобы создать новый запрос на сертификат, подпишите его и отправьте.

Комментарии

certreq -sign При использовании без каких-либо дополнительных параметров откроется диалоговое окно, в котором можно выбрать запрошенный файл (req, CMC, txt, Der, CER или CRT).

для подписывания запроса на квалифицированное подчинение может потребоваться Enterprise учетные данные администратора . Это рекомендуемый способ выдачи сертификатов подписи для квалифицированного подчинения.

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

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

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

certreq — регистрация

Этот комментарий можно использовать для регистрации или обновления сертификатов.

Примеры

Чтобы зарегистрировать сертификат с помощью шаблона и выбрать сервер политики с помощью U/I:

Чтобы продлить сертификат с помощью серийного номера, сделайте следующее:

Можно обновить только действительные сертификаты. Сертификаты с истекшим сроком действия не могут быть обновлены. их необходимо заменить новым сертификатом.

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

Почти всякий, кто устанавливал некий веб- сайт имел дело с сертификатами SSL из общедоступного CA ( Certification Authority , Органа сертификации), но знаете ли вы, что вы можете быть собственным CA? Что вы можете выпускать сертификаты для машин в вашей сетевой среде прямо со своего собственного сервера CA? Следуя далее мы исследуем некоторые из возможностей Windows Server 2016, работающего в качестве сервера CAв вашей сети. Наша работа в данной главе охватит следующие темы:

Настройка самого первого сервера Certification Authority в сетевой среде

Построение Подчинённого сервера CA

Создание шаблона сертификата для подготовки выпуска сертификатов машин вашим клиентам

Публикация шаблона сертификата для возможности регистрации

Применение MMC для запроса нового сертификата

Применение веб- интерфейса для запроса нового сертификата

Настройка автоматической регистрации для выпуска сертификатов всем подключённым к домену системам

Обновление вашего корневого сертификата

Введение

Когда я получаю известие, что частью моего задания дня является новый пользователь или сеть, я обычно нахожу, что истиной будет одна из двух вещей. Либо у них нет никакого сервера CA, либо они имеют его, но совсем ни для чего не применяют. Большинство людей знают, что сертификаты понадобятся и востребованы, а также что постоянно выпускаются новые технологии, которые требуют довольно большого количества сертификатов. Такие технологии как Lync, SharePoint, System Center, DirectAccess или даже простое построение веб- сайта почти всегда требуют применения сертификата в сегодняшнем мире. Прыгнув в проект по размещению практически любой новой системы в эти дни быстро приводит вас к пониманию, что знание сертификатов становится обязательным. Даже места, в которых они не требуются, они обычно всё- таки рекомендуются чтобы иметь решение более безопасным или придерживающимся распространённой практики.

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

Настройка первого сервера Сертификационной авторизации в сети

Самый первый барьер, который необходимо преодолеть когда вы хотите начать работу с сертификатами, состоит в помещении такого сервера на место. Существует множество справедливых вопросов на которые необходимо ответить. Нужен ли вам выделенный сервер для этой задачи? Мог ли я совмещать эту роль на существующем сервере? Нужно ли мне устанавливать Корпоративный (Enterprise) или автономного (stand-alone) CA (Органа сертификации)? Я слышал термин отключённого (offline) корня, но что он означает? Давайте начнём с основ и предположим, что вам нужно построить самый первый сервер CA в вашем окружении.

В сетевой среде домена AD наиболее полезными серверами CA является разновидность Корпоративных (Enterprise). Серверы корпоративного CA интегрированы с AD, что делает их видимыми для машин в такой сетевой среде и автоматически заслуживают доверие (trusted) у компьютеров, которые присоединены к данному домену. Существуют различные мнения по природе наилучшего использования при установке последовательностей серверов CA. Например, существует хорошее руководство тестовой лаборатории (ссылка на который приводится в конце данного рецепта), опубликованное Microsoft, которое проводит вас через настройку автономного (stand-alone) Корневого (Root) CA, Подчинённого Корпоративного (Subordinate Enterprise) CA, с последующим изъятием в выключенное состояние автономного корня (stand-alone root offline). Преимущество этого состоит в том, что сертификаты выпускаются из подчинённого CA, а не напрямую из корня и, тем самым, если ключи сертификата каким- то образом скомпрометированы в данном окружении, Корневой CA полностью отключён и недоступен с тем, чтобы быть скомпрометированным. В подобной ситуации вы можете вычистить Подчинённого и опубликованные им сертификаты, поднять отключённый Корень, построить нового Подчинённого и вернуться к делу публикации сертификатов без какой- бы то ни было повторной генерации нового сервера Корня CA.

С учётом предыдущего практического опыта, или как это определено тем или иным образом, удивительно, что я крайне редко вижу Корневой CA отключённым на практике. На самом деле, практически никогда. А в некоторых имевшихся у меня случаях наличие отключённого Корня CA вызывало проблемы. Просто для примера, при размещении инфраструктуры DirectAccess с возможностями одноразового пароля (OTP, one-time-password) в среде заказчика, было обнаружено, что чтобы заставить такие OTP работать правильно, отключённый Корень CA должен быть приведён назад в рабочее состояние. Это не было самым насущным интересом нашего варианта для создания PKI, и поэтому взамен мы реализовали вторую среду сертификата с автономным корнем и и двумя промежуточными чтобы поддерживать отключённым Корень CA для данной цели сертификатов OTP. Это вызвало большие задержки в нашем проекте, так как мы должны были построить три новых сервера, необходимых просто для получения публикации сертификатов правильным образом, что впоследствии привело к намного более сложной инфраструктуре сертификации.

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

Другое практическое наблюдение состоит в том, что большая часть компаний малого и среднего размера не выбирают подход с отключённым Корнем CA. На самом деле я обнаруживаю, что многие малые компании вынуждены совмещать серверы чтобы сберегать ресурсы и имеют свои CA роли установленными на серверы, которые также выполняют некоторые прочие задачи. Зачастую роль CA устанавливается в Контроллере домена. Хотя на поверхностном уровне рассмотрения это кажется не лишённым смысла, так как службы Корпоративного CA настолько тесно интегрируются с AD, в действительности это плохая мысль. Microsoft рекомендует чтобы вы никогда не совмещали роль CA в Контроллере домена, поэтому удерживайтесь в стороне от такого сценария по мере возможности. Как уже было сказано, я наблюдал десятки компаний, которые в точности делали это и никогда не имели с этим проблем, поэтому я предполагаю, что это просто ваш выбор насколько близко вы хотите придерживаться Пути Microsoft . Не забудьте ознакомиться со ссылками, приводимыми в конце данного рецепта, так как они снабдят вас информацией, которая будет полезна чтобы принять верное решение по поводу того какая настройка сервера сертификата наилучшим образом удовлетворяет вашей сетевой среде.

Подготовка

Я создал новый Windows Server 2016 с именем CA1 , причём он является участником домена, на котором мы будем включать нашу новую инфраструктуру сертификации.

Для начало открыть консоль управления InetMgr.exe > Сервер > вкладку сертификаты.



  • Далее копируем наш запрос на сервер сертификатов. Начинаем процесс подписи нашего запроса. Для этого запускаем cmd.exe и вводим certreq -submit -attrib "CertificateTemplate: WebServer" request.txt. Выбираем центр сертификации который будет подписывать наш сертификат.



  • Копируем наш сертификат на IIS и завершаем процесс запроса сертификата.




  • Далее переходим на сайт для которого нужно установить этот сертификат. Действия > Bindings. Выбираем из списка наш сертификат.


4 комментариев

Евгений Сообщает:

18.12.2013 на 13:42 (UTC 6 )

Плюсую. Отличная инструкция

sss Сообщает:

23.12.2013 на 23:15 (UTC 6 )

certreq -submit -attrib "CertificateTemplate: WebServer" request.txt

ошибка файл не найден

ealnye-otzyvy.info Сообщает:

26.11.2016 на 14:26 (UTC 6 )

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

homeprorab.info Сообщает:

17.12.2016 на 15:08 (UTC 6 )

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

Читайте также: