Как на сервере сделать сертификат: Как создать SSL сертификат самостоятельно?

Содержание

Как создать SSL сертификат самостоятельно?

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

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

Создать сертификат самому можно средствами свободно распространяемого пакета IIS6 Resource Kit Tools.

Может потребоваться установка служб. Для этого в Панели управления необходимо выбрать раздел «Программы и компоненты» и в открывшемся окне в меню слева нажать на ссылку «Включение или отключение компонентов Windows». Далее в открывшемся окне нужно включить компонент «Службы IIS».

Что следует учесть перед созданием сертификата?

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

Использование доверенного сертификата гарантирует безопасность и исключает риски клиента.

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

Создать сертификат: пошаговая инструкция

Самостоятельно создать сертификат можно, выполнив 4 простых шага:

В Панели управления войдите в раздел «Администрирование» и выберите там пункт «Диспетчер служб IIS»
.
В Диспетчере служб нужно перейти в раздел «Сертификаты сервера».
Справа расположен столбец «Действия». В нем выберите пункт «Создать самозаверенный сертификат…»
В открывшемся диалоговом окне понадобится ввести название сертификата.

Привязать сертификат к серверу

После того, как Вы создали SSL сертификат, следует привязать его к IIS-серверу. Для этого вернитесь в раздел «Сертификаты сервера» и в разделе «Подключения» слева выберите сайт, к которому планируете привязать созданный.

В столбце «Действия» нажмите на «Привязки…».

В открывшемся диалоговом окне «Добавление привязки сайта» введите сведения о привязке (не забудьте выбрать созданный сертификат в соответствующем поле) и нажмите «ОК».

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

как его создать и найти?

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

Сохранность приватного ключа SSL

Организации, выдающие SSL сертификаты безопасности, не имеют доступа к вашему закрытому (или приватному) ключу шифрования – и не должны иметь – поскольку закрытые ключи создаются на уровне пользователя, то есть на вашем сервере или компьютере. Даже если Вы генерируете CSR запрос и приватный ключ на нашем сайте, Вы должны сохранить его у себя, так как на нашем сервере информация о ключе не сохраняется. Два главных фактора, от которых зависит криптографическая безопасность закрытого ключа, – это количество и случайная последовательность простых чисел, используемых при его создании.

По сути, закрытый ключ — это файл с набором чисел, сгенерированных случайным образом. Конфиденциальность этой информации является гарантией безопасности вашего ключа на протяжении всего периода использования SSL-сертификата. Чтобы обеспечить сохранность вашего закрытого ключа, доступ к нему следует разрешать только тем членам вашей организации, кому он действительно необходим, например, системному администратору, который занимается установкой SSL сертификата. Кроме того, рекомендуется изменять закрытый ключ (и перевыпускать соответствующий SSL сертификат) всякий раз, когда сотрудник, располагавший доступом к нему, покидает вашу организацию.

Как найти приватный ключ SSL?

Ваш приватный ключ создается, как правило, в тот момент, когда Вы генерируете CSR запрос, или же непосредственно перед этим. Если для управления вашими приватными ключами вы используете OpenSSL (например, вы пользуетесь дистрибутивами Linux на основе Debian или Red Hat), то при выполнении команды OpenSSL req приватный ключ обычно сохраняется в том же каталоге, где была инициирована команда. Если вы используете веб-сервер Microsoft IIS, то ваш закрытый ключ SSL хранится в скрытой папке на сервере-отправителе запроса на выпуск SSL сертификата (который еще называется Certificate Signing Request или сокращенно CSR-запрос). При правильной установке, сертификат сервера будет совпадать с приватным ключом. Если приватный ключ отсутствует, это может означать:

Сертификат не был установлен на сервере, использовавшемся для генерации CSR-запроса (актуально для серверов Microsoft IIS и некоторых других).
Ожидающий обработку CSR запрос был сброшен веб-сервером IIS.
Сертификат был установлен с помощью мастера импорта сертификатов, а не средствами IIS.

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

Как создать закрытый ключ?

Если вы не смогли найти ваш закрытый ключ SSL или еще не создали его, вам нужно будет это сделать, если вы хотите получить SSL сертификат. Как правило закрытый ключ нужно создавать на сервере, на котором вы планируете установить сертификат. При этом его нужно создать перед тем, как генерировать CSR-запрос или же вместе с ним, если ваше устройство это позволяет. Некоторые программы автоматизируют эти задачи, что значительно ускоряет весь процесс. Чтобы выпустить SSL сертификат, сертификационный центр «подписывает» ваш CSR-запрос, именно поэтому при оформлении сертификата, с Вами будут говорить именно о генерации CSR запроса на получение SSL сертификата, а не о создании приватного ключа.

Здесь вам важно понимать, что создание CSR запроса подразумевает и создание приватного ключа. Определенному CSR запросу соответствует только один приватный ключ. Поэтому, если вы утеряли закрытый ключ (не сохранили его или случайно удалили), необходимо инициировать перевыпуск SSL сертификата с новым приватным ключом. Для этого, соответственно, необходимо создать новый CSR запрос. Поставщики SSL-сертификатов, должны предоставлять информацию о генерации приватного ключа и CSR-запроса. Инструкции, по созданию CSR-запроса и приватного ключа вы можете найти на нашем сайте. Вы также можете использовать сервис для создания приватного ключа и CSR-запроса на нашем сайте. Для этого необходимо заполнить соответствующие поля в формуляре на латинице по примеру, как показано на изображении:

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

Если вы заказываете OV SSL сертификат с проверкой компании или еще более надежный EV SSL сертификат с расширенной проверкой, важно, чтобы заполненные данные совпадали с информацией в регистрационных документах вашей фирмы. Если заказываете простой сертификат, это не настолько важно, главное — не оставлять пустых полей. Также при заполнении формы лучше не использовать специальных символов, так как не все центры сертификации принимают содержащие их CSR запросы.

В поле «Доменное имя» введите домен, для которого вы оформляете SSL сертификат. Если вы заказали Wildcard SSL сертификат с поддержкой поддоменов, в этом поле следует указать домен со звездочкой вначале, например, *.emaro-ssl.ru. После заполнения всех полей создается CSR запрос и ваш приватный ключ, которые выглядят следующим образом:

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

Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему

Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2016 года.

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

Чтобы выпустить сертификат для вашего локального домена, понадобится корневой сертификат. На его основе будут выпускаться все остальные сертификаты. Да, для каждого нового top level домена нужно выпускать свой сертификат. Получить корневой сертификат достаточно просто.
Сначала сформируем закрытый ключ:

openssl genrsa -out rootCA.key 2048

Затем сам сертификат:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Нужно будет ввести страну, город, компанию и т.д. В результате получаем два файла: rootCA.key и rootCA.pem

Переходим к главному, выпуск самоподписанного сертификата. Так же как и в случае с корневым, это две команды. Но параметров у команд будет значительно больше. И нам понадобится вспомогательный конфигурационный файл. Поэтому оформим все это в виде bash скрипта create_certificate_for_domain.sh

Первый параметр обязателен, выведем небольшую инструкцию для пользователя.

if [ -z "$1" ]
then
  echo "Please supply a subdomain to create a certificate for";
  echo "e.g. mysite.localhost"
  exit;
fi

Создадим новый приватный ключ, если он не существует или будем использовать существующий:

if [ -f device.key ]; then
  KEY_OPT="-key"
else
  KEY_OPT="-keyout"
fi

Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):

DOMAIN=$1
COMMON_NAME=${2:-$1}

Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:

SUBJECT="/C=CA/ST=None/L=NB/O=None/CN=$COMMON_NAME"
NUM_OF_DAYS=999

В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (страна, город, компания и т.д). Все значение, кроме CN можно поменять на свое усмотрение.

Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.

openssl req -new -newkey rsa:2048 -sha256 -nodes $KEY_OPT device.key -subj "$SUBJECT" -out device.csr

Формируем файл сертификата. Для этого нам понадобится вспомогательный файл с настройками. В этот файл мы запишем домены, для которых будет валиден сертификат и некоторые другие настройки. Назовем его v3.ext. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = %%DOMAIN%%
DNS.2 = *.%%DOMAIN%%

Да, верно, наш сертификат будет валидным для основного домена, а также для всех поддоменов. Сохраняем указанные выше строки в файл v3.ext

Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:

cat v3. ext | sed s/%%DOMAIN%%/$COMMON_NAME/g > /tmp/__v3.ext

Выпускаем сертификат:

openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days $NUM_OF_DAYS -sha256 -extfile /tmp/__v3.ext

Переименовываем сертификат и удаляем временный файл:

mv device.csr $DOMAIN.csr
cp device.crt $DOMAIN.crt

# remove temp file
rm -f device.crt;

Скрипт готов. Запускаем его:

./create_certificate_for_domain.sh mysite.localhost

Получаем два файла: mysite.localhost.crt и device.key

Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:

Запускаем браузер, открываем https://mysite.localhost и видим:

Браузер не доверяет этому сертификату. Как быть?

Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:

Обновляем страницу в браузере и:

Успех! Браузер доверяет нашему сертификату.

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

Делитесь в комментариях, используете ли вы https для локальной разработки?

Максим Ковтун,
Руководитель отдела разработки

Установка сертификата на HTTP сервер Apache / Блог компании GlobalSign / Хабр

Данная статья предлагает пошаговую инструкцию по установке сертификата на HTTP сервер Apache. Обратите внимание, что с версии 2.4.8 Apache параметры конфигурации сервера были изменены.

1. Скопируйте файлы сертификатов на ваш сервер.
Вам нужно скопировать на сервер следующие файлы: сертификат сервера, закрытый (приватный) ключ и промежуточный сертификат, соответствующий типу Вашего сертификата сервера.

Сертификат сервера направлялся Вам по электронной почте после его выпуска в GlobalSign. Также Вы можете получить его в своей учётной записи GlobalSign, нажав на кнопку
«Edit» слева от номера заказа и скопировав сертификат в формате PEM.

Закрытый ключ для сертификата создаётся вместе с запросом на сертификат (CSR), поэтому файл закрытого ключа уже может находиться на Вашем сервере. Если приватный ключ утерян, то сертификат нужно перевыпустить.

Промежуточный (intermediate) сертификат, который потребуется установить на сервер, зависит от типа Вашего сертификата. Именно наличие промежуточного сертификата в цепочке позволяет связать Ваш сертификат с корневым (root) сертификатом GlobalSign и сделать цепочку доверенной. Загрузите один или несколько промежуточных сертификатов, соответственно типа Вашего сертификата, по ссылке ниже:
support.globalsign.com/customer/portal/topics/538410-root-certificates/articles

2. Откройте для редактирования конфигурационный файл Apache.
В зависимости от типа операционной системы путь директории конфигурационного
файла может быть разным:

CentOS/RedHat:

/etc/httpd/httpd.conf
/etc/httpd/sites-enabled/name-of-virtualhost.conf

Debian/Ubuntu:

/etc/apache2/apache2.conf
/etc/apache2/sites-enabled/name-of-virtualhost.conf

Более подробную информацию о пути нахождения конфигурационного файла можно найти по ссылке ниже:
https://wiki.apache.org/httpd/DistrosDefaultLayout

3. Настройте виртуальный хост для работы сертификата.

Найдите раздел VirtualHost и добавьте (или отредактируйте, если они уже имеются) следующие директивы, указав актуальные пути к файлам сертификатов и ключа:

<VirtualHost  xxx.xxx.x.x:443>

                     DocumentRoot  /var/www/examplesite

                     ServerName  example.com  www.example.com
                                       
                     SSLEngine  on

                     SSLCertificateFile   /path/to/examplesite. crt

                     SSLCertificateKeyFile    /path/to/privatekey.key

                     SSLCertificateChainFile    /path/to/intermediate.crt

</VirtualHost>

Убедитесь в правильности путей SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile, каждый из них должен указывать на соответствующий файл.

Примечание: Начиная с версии Apache 2.4.8, вместо директивы SSLCertificateChainFile следует использовать директиву SSLCertificateFile, которая была расширена для поддержки промежуточных сертификатов. Добавление промежуточного сертификата в конец файла сертификата сервера создаст необходимую доверенную цепочку.

4. Протестируйте созданную конфигурацию сервера.
В зависимости от операционной системы, выполните команду:

apachectl  configtest

или

apache2ctl   configtest

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

5. Перезапустите сервер Apache.
Для более старых версий дистрибутива Red Hat Enterprise Linux используйте скрипты:

CentOS/RedHat:

service    httpd  restart

Debian/Ubuntu:

service   apache2 restart

Для дистрибутивов Red Hat Linux 7 или CentOS 7.0 используйте следующие команды:

CentOS/RedHat:

systemctl   restart    httpd.service

Debian/Ubuntu:

systemctl   restart   apache2.service

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

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

Если у вас остались вопросы по установке сертификата GlobalSign на HTTP сервер Apache, пожалуйста, свяжитесь со службой поддержки GlobalSign Russia: support@globalsign. com, тел.: +7 (499) 678 2210

Глава 4. Работа с сертификатами

Когда я получаю известие, что частью моего задания дня является новый пользователь или сеть, я обычно нахожу, что истиной будет одна из двух вещей. Либо у них нет никакого сервера 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, причём он является участником домена, на котором мы будем включать нашу новую инфраструктуру сертификации.

Как это сделать…

Чтобы установить Службы сертификации AD (Active Directory Certificate Services) на вашем Server 2016, воспользуйтесь следующим набором инструкций:

Откройте Диспетчер сервера и кликните ссылку Add roles and features.
Пройдите шаги, выбрав настройки по умолчанию. Когда вы дойдёте до экрана Server Roles, выберите Active Directory Certificate Services.
В процессе выбора этой роли вы будете запрошены подтвердить установку дополнительных функций. Пройдите далее и кликните Add Features.
Пару раз кликните Next пока не достигните экрана Role Services. В нём вы увидите несколько различных вариантов которые могут быть применены для вашего сервера CA. Так как мы хотели бы иметь возможность запрашивать сертификаты через веб- интерфейс в этом CA, я собираюсь отметить дополнительный блок для Certification Authority Web Enrollment. После выбора этого блока, вы получите дополнительный всплывающий блок, запрашивающий вас добавить свойства. Проверьте что разрешили эти свойства для установки.
Кликните Next по оставшимся экранам пока не достигните смой последней страницы, в которой кликните кнопку Install для начала установки этой роли.

Когда она завершится, вы увидите ссылку внутри итогового окна установки, которое сообщит Configure Active Directory Certificate Services on the destination server (Настройте Службы сертификации AD на сервере назначения). Вы можете кликнуть либо на эту ссылку, либо на уведомление маркера жёлтого восклицания Диспетчера сервера рядом с верхней частью экрана самого Диспетчера сервера чтобы продолжить настройку роли CA. На первом экране настроек, мастер вероятно вставит автоматически имя пользователя зарегистрированного в настоящее время пользователя. Как следует из текста на этом экране, убедитесь что пользователь, с которым вы зарегистрировались, имеет права администратора Корпорации (Enterprise Admin) для данного домена, так как мы планируем установить этот сервер CA в качестве Корпоративного Корня CA.

Совет

Вы можете кликнуть по More about AD CS Server Roles в любое время для того, чтобы прочитать дополнительную информацию о различных типах ролей CA и доступных свойствах. Для целей данного рецепта мы не обсуждаем их все, а только сосредоточимся на создании своего Enterprise Root CA (Корпоративного Корня CA).

Для раскрутки служб сертификации на нашем сервере пройдите далее и пометьте два верхних параметра для настройки Certification Authority and Certification Authority Web Enrollment.
Выберите Enterprise CA.
Выберите Root CA; так как это наш первый сервер CA, нам нужно реализовать корень до того, как мы сможем думать об субординации.
Выберите Create a new private key (Создать новый частный ключ).
В экране Cryptography вы имеете возможность выбрать вариант криптографии, который вы можете предоставить вашему серверу CA. Обычно, если вы не уверены в этих параметрах, опции по умолчанию являются наилучшим выбором. Только убедитесь, что ваше поле Key length установлено, как минимум, в значение 2048. Это новый стандарт отрасли для минимальной длины ключа. Аналогично, стандарт хэширования должен соответственно измениться на SHA256, на самом деле, вы не должны более применять SHA1 ни для каких своих сертификатов, поскольку в настоящее время существует оценка, что SHA1 может быть скомпрометирован в следующие пару лет.
Если пожелаете, вы можете изменить свои Common name for this CA. Имейте в виду, что оно не должно соответствовать каким либо образом имени хоста. Это имя вашего CA, кторое будет показываться внутри Active Directory, а также внутри сертификатов, которые вы выпускаете из этого CA. Обычно я вижу, что администраторы оставляют только Distinguished name suffix (Суффикс отличительного имени).
Измените Validity Period (период действия) вашего сертификата корня, если пожелаете. Часто администраторы проскакивают через это окно и оставляют значение по умолчанию пять лет, однако это означает, что всего через пять коротких лет у вас внезапно станут несостоятельными все отдельные сертификаты которые только были выпущены из этого сервера CA. Я рекомендую это значение до 10, или даже до 20 лет, с тем, чтобы вы не беспокоились об этом истечении этого уровня сертификации длительное время. Период действия определяет как часто должен обновляться сертификат корня.
Продолжите идти по оставшимся окнам, оставляя на месте установленные значения по умолчанию. Когда этот мастер завершится, ваш сервер CA теперь оживёт.
обычно хорошей мыслью является перезагрузка данного сервера после установки столь значительной роли. Пройдите далее и перезагрузитесь как только позволит время.

Как это работает. ..

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

Существует пара моментов, которые не были охвачены в данном рецепте и которые следует отметить. Следование приведённым шагам приведёт ваш сервер CA в запущенное и рабочее состояние, которое будет готово к выпуску сертификатов, это несомненно так. Остальные рецепты в данной главе отражают построение CA в точности как показано здесь. Однако, существуют дополнительные шаги, которые могут быть предприняты чтобы и далее персонализировать ваши настройки CA если вам это нужно. Если вы планируете выпускать сертификат SSL для вебсайтов, в особенности, если вы планируете устанавливать эти сертификаты на веб серверы, повёрнутые в сторону всемирного Интернета, тогда вам необходимо ознакомиться с настройками CRL (Certificate Revocation List, Списка отозванных сертификатов). При каждом доступе к сертификату компьютер клиента проверяется в CRL чтобы гарантировать, что данный сертификат всё ещё действует. Если сертификат не действительный, или мошеннический в каком- либо виде, проверка CRL определит эту скомпрометированность и запретит такое соединение. В частности, при публикации вебсайтов в Интернет, которые применяют сертификаты, выпускаемые вашим внутренним PKI, вам придётся планировать публикацию вашего CRL с тем, чтобы компьютеры внешних клиентов могли осуществлять к нему доступ свободным, безопасным образом. Вот прекрасная ссылка, с которой вы можете начать изучать информацию CRL: http://technet.microsoft.com/en-us/library/cc771079.aspx.

Второй фрагмент информации, которую я бы хотел отметить это файл CAPolicy.inf. Именно этот файл можно заполнять различными персональными настройками для вашего сервера CA, такими как период действия вашего корневого сертификата, информация об CRL, а также хотите вы или нет чтобы шаблоны сертификатов по умолчанию загружались в процессе установки роли CA. Если какие- либо из этих настроек представляют для вас интерес, вы просто создаёте файл CAPolicy.inf с соответствующими настройками и помещаете вовнутрь C:\Windows в вашем сервере CA перед установкой роли. Мастер установки роли затем применит эти настройки внутри данного файла в процессе установки роли и присоединит ваши персональные установки. Если вы не применяете один из этих файлов, это неплохо, и ваша роль будет установлена с некоторыми настройками по умолчанию на своих местах, в точности как это имело место в данном рецепте. Однако, если вы заинтересованы в изменении некоторых из них, ознакомьтесь с данной ссылкой для получения дополнительной информации по файлу CAPolicy.inf: http://technet.microsoft.com/en-us/library/jj125373.aspx.

Никакие из этих элементов, ни настройка CRL, ни использование файла CAPolicy.inf не являются обязательными для того чтобы среда сертификации поднялась и заработала. Таким образом, они не не включены в пошаговую настройку самого данного рецепта. Однако я всегда счастлив иметь все доступные мне знания по определённому предмету и поэтому я настоятельно рекомендую вам прочитать эти дополнительные ссылки, предоставляющие совершенство вашему пониманию возможной функциональности.

Также ознакомьтесь…

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

Построение подчинённого сервера Сертификационной авторизации

В действительности мы строим Подчинённый (Subordinate) CA не с целью избыточности, как это имеет место для многих прочих видов серверов, а потому что существует множество особенных задач, которые вы можете пожелать выполнить в Подчинённом CA, в отличие от Корня (Root) CA. Если вы выпускаете большое число сертификатов или различные виды сертификатов, вы можете захотеть установить различие между серверами CA при выпуске. Возможно, вы пожелаете, чтобы машины, которые применяются для сертификатов IPsec выпускались из IPSEC-CA, в то время как выпускаемые вами SSL сертификаты вебсайта должны быть представляться с WEB-CA. Вместо того, чтобы строить два независимых Корня CA, которые оба имели бы права верхнего уровня, вы должны рассмотреть создание отдельного Корня CA, возможно, с именем ROOT-CA и поместить эти два сервера CA в подчинённую роль под такой Корень CA в цепочку. Это может быть также полезно для географически распределённых сетевых сред, имеющих Подчинённые серверы CA, выделенные для назначения сертификатов различным офисам или регионам.

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

Мы находимся внутри сетевого домена и имеем поднятым и работающим отдельный Корпоративный Корень (Enterprise Root) CA. Теперь нам требуется некий дополнительный сервер, который будет присоединён к нашей среде CA в качестве нового Подчинённого (Subordinate) CA.

Как это сделать…

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

Зарегистрируйтесь на вашем новом сервере, который уже подключён к домену.
Следуйте шагам для добавления роли Служб Сертификации AD (AD CS) к этому серверу.
Когда мы реализовали свой сервер Корня CA, мы также выбрали установку веб служб. Это позволит нам запрашивать и выпускать сертификаты через какой- либо браузер внутри нашей сетевой среды {Прим. пер.: или применяя RESTfull службы}. У вас имеются опции установки этих веб служб в вашем новом Подчинённом CA, которые вы определённо должны бы выполнить, если планируете применение отключения Корня CA, однако для нашего случая мы не собираемся делать этого. Мы оставим только Certification Authority в нашем перечне доступных роли служб.
После завершения установки выбранной роли, пройдите далее и кликните Configure Active Directory Certificate Services on the destination server (Настройка Служб сертификации AD на сервере назначения).
В случае необходимости введите полномочия и выберите только единственную опцию, которую мы должны перечислить для настройки, Certificate Authority.
Это именно то место, с которого мы должны начать сворачивать с пути, который мы выбирали при создания Корня CA. Мы всё ещё выбираем настройку Enterprise CA, так как мы всё ещё желаем его интеграции с доменом.
Однако, вместо выбора установки нового Корня CA мы собираемся выбрать опции для Subordinate CA (Подчинённого CA). На самом деле, он уже был выбран для нас по умолчанию, так как он распознал что Корень CA уже присутствует в нашей сетевой среде. Мы можем установить другой Корень CA, однако это не является нашей целью в данном рецепте.
Выберите Create a new private key. Единственный раз, в который мы обычно захотим воспользоваться существующим частным ключом это когда мы перестраиваем некий сервер CA.
Выберите настройки криптографии. Они обычно выбираются теми же самыми, что и настроенные вами для Корня CA.
Присвойте имя своему новый Подчинённый CA. Если у вас имеется некая определённая функция на уме для этого CA, вам на будущее определить имя в соответствии с нею. Например, я собираюсь использовать данный Подчинённый CA для выпуска всех своих SSL сертификатов, которые мне понадобятся для внутренних вебстраниц, таким образом, я должен включить в состав имени SSL.
Теперь мы переходим к новому экрану. Нам необходимо получить некий сертификат от нашего родительского сервера CA чтобы выпускать сертификаты из этого нового. Выберите параметр Send a certificate request to a parent CA, (Отправить запрос на сертификат родительскому CA), а затем воспользуйтесь кнопкой Select… для выбора вашего Корня CA.
На вашем следующем экране отрегулируйте местоположение его файлов сертификационной базы данных, если это необходимо; в противном случае кликните Next, а затем Configure.

Как это работает…

Установка Подчинённого (Subordinate) сервера CA в сетевой среде очень похожа на реализацию нашего первого сервера Корня CA. В нашем случае, мы упростили свою установку, не выбрав требований для веб служб для работы в таком Подчинённом CA, мы будем выполнять все такие запросы из Корня CA. Теперь у нас имеется работающий Корень CA и Подчинённый CA, работающий под ним. Для нашей другой установки мы собираемся оставить оба включёнными и работающими, поскольку мы собираемся выпускать сертификаты с обоих. Мы легко можем пройти через тот же самый процесс снова с другим новым сервером чтобы создать другой Подчинённый CA, возможно, для выпуска другого вида сертификата или для использования другим подразделением вашей компании.

Также ознакомьтесь…

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

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

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

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

Имеется среда домена Server 2016 с новым работающим сервером CA. Мы воспользуемся консолью CA в своём сервере CA чтобы сейчас выполнить эту работу. Новый шаблон, который мы создадим, будет автоматически реплицироваться для других серверов CA в нашем домене.

Как это сделать…

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

Запустите инструментарий управления Certification Authority изнутри Диспетчера сервера.
Раскройте имя вашего CA и кликните Certificate Templates. Вы увидите список доступных вам встроенных сертификатов.
Кликните правой кнопкой по Certificate Templates и выберите Manage.
Кликните правой кнопкой по имеющемуся шаблону Computer и выберите Duplicate Template.
Теперь мы отрегулируем параметры внутри этого шаблона сертификата. Вы устанавливаете здесь в данных свойствах шаблона все атрибуты, которые должен иметь ваш сертификат. В качестве примера, давайте настроим в качестве действующих несколько элементов, которые должны содержать наши новые сертификаты IPsec.
Перейдите в закладку General и установите Template display name (Отображаемое имя шаблона) с тем, чтобы вы могли определять такой новый выстраиваемый нами шаблон.
В той же самой закладке отрегулируйте поле Validity period (Период действия) на 2 года.
Проследуйте в закладку Subject Name и установите Common name для поля Subject name format. Это вызовет то, что имя предмета сертификата будет отображать имя хоста того компьютера, который запрашивает данный сертификат. Использование имени DNS в качестве альтернативного имени предмета является другим требованием, которое мы предоставим своему новому сертификату. Вы можете увидеть его отмеченным в нашем снимке экрана внизу. Так как мы применяем встроенный шаблон Computer в качестве нашей отправной точки, этот флаговый блок, а также прочие требования, которые необходимо охватывать, уже предоставлены нам.
Кликните OK. Теперь в нашем перечне имеется новый именованный сертификат с названием IPsec Certificate (или какое- либо иное предпочитаемое вами имя).

w3.org/1999/xhtml»> Как это работает…

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

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

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

Мы собираемся воспользоваться нашей машиной Windows Server 2016, которая является нашим Корпоративным Корнем (Enterprise Root) CA.

Как это сделать…

Чтобы выпускать сертификаты на основе некоторого определённого шаблона, нам необходимо выполнить шаги для публикации и отрегулировать свойства безопасности этого шаблона:

Из Диспетчера сервера запустите инструментарий Certification Authority.
Раскройте имя своего сервера CA в дереве с левой стороны.
Кликните правой кнопкой по Certificate Templates и переместитесь в New | Certificate Template to Issue.
Выберите ваш новый шаблон из данного перечня и кликните на OK.
Теперь кликните правой кнопкой по Certificate Templates и выберите Manage.
Найдите тот шаблон, который вы хотите изменять. В нашем рецепте мы модифицируем свой новый шаблон с названием IPsec Certificate.
Кликните правой кнопкой по этому шаблону и выберите Properties.
Перейдите к закладке Security.
Теперь нам нужно настроить полномочия в соответствии с вашими требованиями. Для нашего конкретного примера мы желаем выпускать сертификаты IPsec для всех подключённых к домену компьютеров, с тем, чтобы они позже могли применяться в процессе переговоров (negotiations) об IPsec внутри нашей сети. По этой причине мы добавили Domain Computers и пометили соответствующий блок для включения полномочий Enroll (регистрации).

Как это работает…

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

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

Наиболее распространённый способ, который я наблюдаю в качестве взаимодействия администраторов со всеми сертификатами в их системах состоит в инструменте оснастки MMC. MMC является сокращением (Microsoft Management Console, Консоль управления Microsoft), а применяя MMC вы можете выполнять администрирование практически всем в своей операционной системе. Хотя возможно это чрезвычайно незаслуженно обходимый вниманием инструмент, я обычно вижу его открытым для некоторых избранных задач. Запрос сертификатов является одной из таких задач.

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

Сервер Корпоративного Корня (Enterprise Root) CA, Server 2016, запущен и работает в нашей сетевой среде. На нём мы должны настроить новый шаблон сертификата с названием IPsec Certificate. Необходимо выполнить шаги для публикации этого шаблона с тем, чтобы его можно было запрашивать с компьютеров в нашей сетевой среде. Теперь мы работаем с нового именованного веб сервера, который также исполняется под Server 2016 и присоединён к нашему домену, где мы собираемся выполнить необходимую работу запроса вручную некоторого сертификата со своего сервера CA.

Как это сделать. ..

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

Откройте приглашение командной строки в нашем новом веб сервере и наберите mmc. Затем нажмите Enter. В качестве альтернативы вы можете открыть MMC извашего экрана Start.
Теперь внутри консоли MMC кликните по меню File, затем по Add/Remove Snap-in… (Добавить/ удалить оснастку).
Выберите Certificates из перечня доступных оснасток и кликните по кнопке Add. Это приведёт вас к новому окну с некоторыми дополнительными выборами для оснастки ваших сертификатов.
Вначале нам необходимо определить будем ли мы открывать свой репозиторий сертификатов пользователей, либо наш репозиторий сертификатов компьютеров. Обычно я не наблюдаю используемых учётных записей служб в данном поле. Выбор здесь будет полагаться на тип запрашиваемого вами сертификата. Для нашего примера мы ищем сертификат IPsec, за которым необходимо перейти в наш контейнер Computer. Выберите Computer account и кликните Finish.
Оставьте следующий параметр установленным в значение Local computer и снова кликните Finish.
Кликните OK.
Существуют также запускающие модули MMC, которые можно применять для переноса вас в хранилище сертификатов даже ещё быстрее. Сделайте это переместившись в Start | Run или приглашение командной строки и наберите следующие команды:
Теперь вернитесь назад в главную консоль MMC, раскройте Certificates (Local Computer) и выберите папку Personal. Вы можете заметить, что в настоящий момент нет установленных здесь сертификатов.
Кликните правой кнопкой по папке Personal и переместитесь в All Tasks | Request New Certificate….
Кликните Next.
В вашем экране Select Certificate Enrollment Policy автоматически выбирается Active Directory Enrollment Policy. Просто кликните Next снова чтобы перейти к следующему экрану.
Теперь мы видим перечень доступных нам шаблонов сертификатов. Отметьте блок того сертификата который вы хотите запросить и кликните Enroll (зарегистрировать).

Совет

Если вы ожидаете увидеть здесь определённый шаблон, однако он не отображается в данном перечне, кликните по Show all templates. Это позволит отобразить все шаблоны данного сервера CA и выдать объяснение для каждого по поводу причины, по которой он в настоящий момент не доступен. Это может оказаться полезным для вас при поиске неисправностей.

Как это работает…

Применение консоли MMC является быстрым и простым способом запроса нового сертификата, выпускаемого вручную. В любой среде Active Directory будет доступен для просмотра и регистрации любой шаблон сертификата на вашем сервере CA, на который у вас имеются полномочия для регистрации (enroll). Наш сегодняшний пример отображает процесс регистрации для сертификата машины, который мы планируем применять в будущем для аутентификации IPsec. Однако, существует множество вариантов использования, при которых вы можете пожелать выпуск сертификатов уровня пользователя вместо сертификатов компьютера. В этих случаях вам понадобится оснастка сертификатов учётных записей Пользователя в том месте нашего примера, где мы определяем сертификаты учётных записей компьютера.

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

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

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

Нашим Корпоративным Корнем (Enterprise Root) CA является Windows Server 2016, который имеет установленную роль Служб Сертификации AD (Active Directory Certificate Services). Когда мы установили и настроили эту роль, мы проверили, что выбрали опцию для веб служб с тем, чтобы применять её для запроса нового сертификата.

Как это сделать…

Мы не обязаны быть зарегистрированы напрямую в сервере CA для выполнения данной работы. Вместо этого мы регистрируемся в некотором новом веб сервере в нашей среде. Находясь в таком веб сервере мы выполняем следующие шаги:

Откройте Internet Explorer и перейдите на https://<CAServerName>/CertSrv/. В нашем случае это https://CA1/CertSrv/.

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

Кликните Request a certificate.
Вы увидите предварительное построение запроса здесь для получения некоторого сертификата пользователя. Если всё дело только в нём, вы просто кликните на эту ссылку, а затем кликните Submit в следующем экране. Однако, чтобы погрузиться слегка больше в наш рецепт, мы собираемся запросить некий сертификат SSL, а не простой сертификат пользователя. Для начала этого процесса кликните на advanced certificate request.
Выберите Create and submit a request to this CA (Выбрать и представить запрос к данному CA).
Кликните Yes если получите следующее сообщение:
Выберите Certificate Template, котрый вы хотите применить чтобы осуществить свой запрос сертификата. В моём Корне CA, в котором установлены соответствующие веб службы, я настроил новый шаблон, который я продублировал из шаблона Web Server с моими специфическими требования к сертификату. Я назвал этот шаблон Custom Web Server и опубликовал его для доступа в своём окружении.
Так как это сертификат SSL, я обязан заполнить обычно запрашиваемую информацию. Здесь вводятся имя моего веб сайта и контакты компании.
Оставшиеся доступные для изменения опции уже настроены так, как мне нужно. Это происходит по той причине, что когда я настраивал свой шаблон Custom Web Server, я уже определил все эти элементы значениями по умолчанию. Вот мой запрос:
Кликните Submit.
Ваш браузер покрутится минутку, пока ваш сервер CA создаст соответствующий новый сертификат основанный на введённой вами информации. Когда он завершит свою работу, вы должны будете иметь некую ссылку для нажатия Install this certificate. Пройдите далее и нажмите на эту ссылку.

Как это работает…

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

Так как наш веб сервер находится внутри корпоративной сетевой среды, мы могли бы также выполнить этот запрос напрямую из консоли Сертификатов MMC. Однако, если наш веб сайт находился в другом здании, отделённом сетевым оборудованием и межсетевыми экранами, это могло бы не оказаться приемлемым вариантом для нас. Или, если бы мы попытались получить некий сертификат из другой машины, которая не обладает доступом MMC по той или иной причине, такая веб служба является прекрасным способом для выполнения той же самой задачи.

Настройка Autoenrollment для выдачи сертификатов всем доменам, объединённым в систему

Множество новых технологий требуют применения сертификатов для аутентификации, запрашивая такие сертификаты для распространения в больших масштабах. Например, если мы хотим применять подобную сертификацию Компьютеров для аутентификации DirectAccess, нам необходимо выпускать некий сертификат для каждого клиентского компьютера DirectAccess. Это могут быть тысячи ноутбуком в нашей сетевой среде. Если мы желаем начать шифровать обмен внутри своей сетевой среды при помощи IPsec и требовать распространения сертификатов для этой цели, вам потенциально понадобится выпустить некий вид сертификационной машины для каждого компьютера внутри вашей сетевой среды. Хотя вы, несомненно, можете выдавать каждый сертификат вручную с применением консоли MMC или через веб интерфейс CA, это не звучит как нечто, доставляющее удовольствие.

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

Мы работаем внутри некоего Windows Server 2016 на основе домена Active Directory. У нас также имеется Корпоративный Корень (Enterprise Root) CA Server 2016, работающий в данной сети. Работа, которую мы будем выполнять состоит в комбинации работы с вашим сервером CA и работой внутри Групповой политики в Контроллере Домена.

Как это сделать…

Чтобы включить в вашем домене Autoenrollment (Автоматическую регистрацию), просмотрите следующие инструкции:

Зарегистрируйтесь на своём сервере CA и откройте Certification Authority. Раскройте имя вашего CA, затем кликните правой кнопкой по Certificate Templates и выберите Manage.
Теперь выберите какой шаблон сертификата вы хотите настроить для Автоматической регистрации. У меня имеется шаблон с названием DA Cert., который я хочу выпускать для каждого компьютера в своей сетевой среде. Кликните правой кнопкой по DA Cert и пройдите в Properties.
Кликните закладку Security. В ней вы должны настроить некие пользователей, компьютеры, или прочие объекты, для которых вы хотите иметь полномочия Autoenroll в данном шаблоне. Я собираюсь Allow Autoenroll полномочия для всех Domain Computers в своей сетевой среде, как это показано на следующем снимке экрана:
Кликните OK, и теперь вам необходимо проследоватиь к Групповой политике (Group Policy). Зарегистрируйтесь в Контроллере домена и откройте Group Policy Management Console.
Я создал новую GPO для задач с названием Certificate Autoenrollment Policy. Эта новая GPO присоединена к вершине моего домена с тем, чтобы она применялась ко всем машинам, которые подключены к домену. Если вам не нужна настолько широкая политика, конечно, вы могли бы урезать доступ сюда ограничив эту ссылку или выполняя фильтрацию связанную с вашей GPO. {Прим. пер.: советуем также вспомнить про Предварительная подготовка учётной записи компьютера в Active Directory, позволяющую заблаговременно устранять создаваемый объект от применения такой Групповой политики. }
Кликните правой кнопкой по GPO Certificate Autoenrollment Policy и выберите Edit….
Переместитесь в Computer Configuration | Policies | Windows Settings | Security Settings |Public Key Policies.
Кликните дважды по Certificate Services Client — Auto-Enrollment.
Установите его в Enabled и выберите оба флаговых блока в данном экране.
Как только вы кликните OK, данная новая GPO вступит в действие . Машины будут проверяться на данную Групповую политику и осознавать, что им необходимы новые настройки от этой GPO. После ввода этого нового параметра на его место, все компьютеры будут затем регистрироваться в сервере CA и запрашивать его для копии некоторого сертификата для которого у них имеются полномочия Автоматической регистрации. Поскольку мы выполнили настройки таким образом, что все Компьютеры в домене должны выполнять Автоматическую регистрацию с нашим шаблоном DA Cert, наши рабочие станции и сервера должны немедленно начать получать копии таких новых сертификатов. Вот снимок экрана из моего сервера CA всего лишь через несколько минут после настройки данной GPO. Вы можете увидеть что она начала выпускать сертификаты для моих подключённых к домену систем:

Как это работает…

Мы применили Групповую политику чтобы перебросить свою Автоматическую регистрацию во включённое состояние и немедленно запустили Автоматическую регистрацию сертификатов для своих подключённых к домену систем. Существует пара различных способов, которыми может регулироваться Автоматическая регистрация. Вы можете решать кто получает политику Автоматической регистрации применяя к ним Групповую политику с привязыванием и фильтрацией в том смысле, что вы можете определять в самих свойствах GPO какие пользователи или компьютеры предполагаются быть объектами для Автоматической регистрации в этом первом месте. В качестве альтернативы, либо же в дополнение, вы можете также определять полномочия внутри каждого шаблона сертификата в своём сервере CA с тем, чтобы вы могли лучше определять какие пользователи или компьютеры в вашей среде будут получать копии каждого шаблона, после того как Автоматическая регистрация включена.

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

После настройки этих установок, если вы перезагрузите несколько подключённых к домену машинв своей сетевой среде, вы заметите, что когда они вернутся назад в рабочее состояние, будут присутствовать новые сертификаты, расположенные в хранилище персональных сертификатов компьютеров. Присядьте и подождите несколько часов, и они накатятся на всех автоматически. Если вам не нравится ожидать обновления Групповой политики, вы можете открыть приглашение командной строки в одном из этих компьютеров и выполнить команду gpupdate /force для обновления политик вручную и установки на место данного сертификата.

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

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

Мы только что построили такой новый сервер CA, поэтому мы не беспокоимся об истечении срока действия нашего сертификата корня, во всяком случае, в скором времени. Однако, важно понимать как выполняется данная задача, поэтому мы пройдём процесс обновления нашего сертификата корня. Мы выполним эту задачу прямо на самом нашем сервере CA.

Как это сделать…

Чтобы обновить сертификат корня CA выполните следующие шаги:

Зарегистрируйтесь на своём сервере Корпоративного Корня (Enterprise Root) CA и откройте консоль управления Certification Authority.

Кликните правой кнопкой по имени вашего CA, переместитесь во All Tasks, а затем выберите Renew CA Certificate. ...

	Совет
	Если вы не остановили ADCS в течение этого процесса, система запросит вас об этом. Пройдите далее и кликните Yes чтобы временно остановить процесс сертификации.

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

Как это работает…

Ваш сертификат корня верхнего уровня критически важен для жизнеспособности всей вашей инфраструктуры PKI. Если у этого сертификата истекает срок действия, все отдельные сертификаты, которые были выпущены этим сервером CA немедленно становятся не действующими. К счастью, обновление такого сертификата обычно достаточно лёгкое. Просто следуйте приведённым нами шагам и вы вернётесь в дело на следующие 5 или 10 лет. После того, как вы обновите свой сертификат авторизации корня, он помещает новую копию такого сертификата в местоположение Групповой политики Доверенных Авторизаций Корня. Все подключённые к домену системы хранят этот список автоматически обновляемым через Групповую политику с тем, чтобы всякий раз когда добавляется новый сервер CA или обновляется существующий сертификат корня, новые доверительные отношения, связанные с таким новым сертификатом, автоматически распространялись на все ваши клиентские машины и серверы. По этой причине, обычно, всё что вам нужно сделать — это обновить сам сертификат, а потом присесть и расслабиться, так как Групповая политика начнёт размещать такой новый сертификат на место по все вашей сетевой среде.

Однако — и это является ЗНАЧИТЕЛЬНЫМ однако — если вы позволите вашему сертификату авторизации корня превысить срок действия, а вы выпустили сертификаты, которые применяются клиентами и серверами для сетевой аутентификации, истечение срока действия сертификата корня будет означать, что такие системы больше на смогут подключаться в вашу сетевую среду. Вы можете легко обновить свой сертификат корня и привести сервер во включённое и работающее состояние, однако, не имея действующего метода аутентификации в вашей сетевой среде, ваши системы, которые полагаются на действующий сертификат для соединения с такой сетью сядут на мель. Вам придётся искать альтернативный способ присоединения их в свою сетевую среду и обновления их Групповой политики прежде чем они изучат как доверять вновь обновлённому сертификату авторизации корня. Это предостережение приходит мне на ум, поскольку я только что помогал некоей компании воевать в точности с этой проблемой. Срок действия их сертификата корня истёк, и они имели целые офисы, полные персонала, который был подключён к их центру обработки данных и их домену исключительно через технологию удалённого соединения DirectAccess. DirectAccess полагается на сертификаты как на часть своего процесса аутентификации, поэтому такие удалённые системы полностью утратили возможность подключения к своей сетевой среде, раз уж срок действия их сертификата корня истёк. нам пришлось подключать их к сети различными путями чтобы поместить установки GPO и новую копию нового сертификата корня на место прежде чем начать удалённое соединение вновь.

Мораль этой истории: не забывайте отмечать в календарях необходимость обновления сертификатов ДО истечения их срока действия!

Настройте шаблон сертификата сервера

000Z» data-article-date-source=»ms.date»> 07.08.2020
2 минуты на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016

Эту процедуру можно использовать для настройки шаблона сертификата, который службы сертификации Active Directory® (AD CS) используют в качестве основы для сертификатов серверов, которые регистрируются на серверах в вашей сети.

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

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

Серверы, на которых запущена служба удаленного доступа, включая серверы шлюза RAS, которые являются членами группы RAS и IAS-серверы .
Серверы, на которых работает служба сервера политики сети (NPS), которые являются членами группы RAS и IAS-серверов .

Членство как в группе Enterprise Admins , так и в группе Domain Admins корневого домена является минимумом, необходимым для выполнения этой процедуры.

Для настройки шаблона сертификата

На CA1 в диспетчере сервера щелкните Tools , а затем щелкните Certification Authority . Откроется консоль управления Microsoft Management Console (MMC) центра сертификации.
В MMC дважды щелкните имя CA, щелкните правой кнопкой мыши Шаблоны сертификатов , а затем щелкните Управление .
Откроется консоль шаблонов сертификатов. Все шаблоны сертификатов отображаются на панели сведений.
На панели сведений щелкните шаблон RAS и IAS Server .
Щелкните меню Действие , а затем щелкните Дублировать шаблон . Откроется диалоговое окно «Свойства шаблона » .
Щелкните вкладку Безопасность .
На вкладке Безопасность в разделе Группа или имена пользователей щелкните Серверы RAS и IAS .
В Разрешения для серверов RAS и IAS в разделе Разрешить убедитесь, что выбран Регистрация , а затем установите флажок Автоматическая регистрация . Щелкните OK и закройте MMC шаблонов сертификатов.
В центре сертификации MMC щелкните Шаблоны сертификатов . В меню Action укажите на New , а затем щелкните Certificate Template to Issue .Откроется диалоговое окно Включить шаблоны сертификатов .
В Включить шаблоны сертификатов щелкните имя шаблона сертификата, который вы только что настроили, а затем щелкните ОК . Например, если вы не меняли имя шаблона сертификата по умолчанию, щелкните Копия RAS и IAS Server , а затем щелкните ОК .

Marvelous Guide to All Things Webhook

В настоящее время мы поддерживаем два способа обработки обновлений ботов: getUpdates и setWebhook . getUpdates — тянущий механизм, setwebhook — нажимной. Хотя концепция веб-перехватчика довольно проста, настройка отдельных компонентов оказалась сложной для многих. Это руководство предоставляет дополнительную информацию для тех из вас, кто достаточно храбр, чтобы отважиться погрузиться в искусство веб-перехватчика.

У использования веб-перехватчика есть некоторые преимущества перед getUpdates. Как только появится обновление, мы передадим его вашему боту для обработки.

Это:

  1.Избегает того, что ваш бот часто запрашивает обновления. 
2. Избегает необходимости в каком-либо механизме опроса в вашем коде.

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

Установка веб-перехватчика означает, что вы предоставляете Telegram местоположение в виде URL-адреса, по которому ваш бот прослушивает обновления. Нам нужно иметь возможность подключаться и публиковать обновления по этому URL-адресу.

Чтобы мы могли это сделать, есть несколько основных требований:

Укороченная версия

Вам понадобится сервер:

Поддерживает IPv4, IPv6 в настоящее время не поддерживается для веб-перехватчиков.
Принимает входящие POST-сообщения из подсетей 149.154.160.0/20 и 91.108.4.0/22 через порт 443, 80, 88 или 8443.
Умеет обрабатывать TLS1.2 (+) HTTPS-трафик.
Предоставляет поддерживаемый, проверенный или самоподписанный сертификат без подстановочных знаков.
Использует CN или SAN, соответствующий домену, который вы указали при настройке.
Предоставляет все промежуточные сертификаты для завершения цепочки проверки.

Это почти все.
Если вы решите ограничить трафик определенным диапазоном адресов, следите за этим документом всякий раз, когда вам кажется, что у вас возникнут проблемы. Наш IP-диапазон может измениться в будущем.

Более длинная версия

Доменное имя
Для настройки веб-перехватчика нужен URL-адрес, на который мы будем отправлять сообщения.Для этого вам понадобится сервер с доменным именем. Если у вас его нет, вам нужно сначала получить его. Telegram в настоящее время не предлагает услуги хостинга или доменного имени. В Интернете существует довольно много провайдеров VPS / веб-хостинга, не стесняйтесь выбирать одного по своему вкусу.
Если вы используете самозаверяющий сертификат, вы можете использовать IP в качестве CN вместо имени домена.
Как мне получить сервер с доменным именем?
Открытый порт
Веб-перехватчику нужен открытый порт на вашем сервере.В настоящее время мы поддерживаем следующие порты: 443, 80, 88 и 8443 . Другие порты не поддерживаются и работать не будут. Убедитесь, что ваш бот работает на одном из поддерживаемых портов и доступен по общедоступному адресу.
```
  Если вы хотите ограничить доступ только к Telegram, разрешите трафик с 149.154.167.197-233 (начиная с июля 2019 года используйте: 149.154.160.0/20 и 91.108.4.0/22).
Когда что-то перестанет работать в будущем, проверьте этот документ еще раз, как
диапазон может расширяться или изменяться. 
```
Как проверить наличие открытых портов или ограничить доступ к моему боту?
Всегда SSL / TLS
Веб-перехватчик требует шифрования SSL / TLS независимо от того, какой порт используется. Невозможно использовать простой текстовый HTTP-перехватчик. Вы тоже не должны хотеть этого ради своего бота и пользователей.
SSL / TLS, почему я должен обрабатывать это для веб-перехватчика?
Не все SSL / TLS одинаковы
Мы поддерживаем любую версию SSL / TLS TLS1.2 и выше для вашего вебхука. Это означает, что SSLV2 / 3 / TLS1.0 / TSL1.1 НЕ поддерживаются из-за проблем безопасности, связанных с этими более ранними версиями.
Как проверить, что я использую правильную версию?
SSL требуется сертификат
Общее имя (CN) вашего сертификата (самоподписанного или проверенного) должно совпадать с доменным именем, на котором размещен ваш бот. Вы также можете использовать альтернативное имя субъекта (SAN), которое соответствует домену вашего веб-перехватчика.Поддерживается маршрутизация с указанием имени сервера (SNI). Если вы используете самозаверяющий сертификат, вы можете использовать IP как CN вместо имени домена.
Сертификат, где мне его получить и как?
Подтверждено или самоподписано
Сертификат может быть проверенным или самозаверяющим. Установка веб-перехватчика с самозаверяющим сертификатом немного отличается от установки веб-перехватчика с проверенным сертификатом. Убедитесь, что вы используете правильную настройку для типа сертификата, который вы выбрали для своего веб-перехватчика.
Как установить перехватчик для любого типа?
Поддерживаемые сертификаты
Поддерживаются не все проверенные сертификаты. Сертификаты основаны на сети доверия и входят в цепочку. Доверие вашему проверенному сертификату означает, что мы должны доверять провайдеру этого сертификата, Центру сертификации (и, следовательно, его корневому сертификату). Прежде чем выбрать поставщика сертификата, проверьте этот список, чтобы убедиться, что мы действительно доверяем его корневому сертификату.
Что делать, если моего корневого сертификата нет в этом списке?
Недоверенный корень
Хорошо, значит, у вас уже был установлен сертификат, но вы только что обнаружили, что его нет в нашем списке.
Начните с его игнорирования и просто попробуйте установить. Мы время от времени добавляем дополнительные корневые сертификаты, чтобы удовлетворить спрос, поэтому список не всегда исчерпывающий. В конце концов, не повезло? Мы разрешим вам предоставить неподдерживаемый корневой сертификат при настройке веб-перехватчика. Этот метод почти идентичен настройке веб-перехватчика самозаверяющего сертификата. Вместо самозаверяющего сертификата вы отправите нам корневой сертификат как inputFile.
Установка проверенного веб-перехватчика с ненадежным корнем
Промежуточные сертификаты
Для некоторых проверенных сертификатов требуется промежуточный сертификат.В этой конструкции провайдер вашего проверенного сертификата использовал свой корневой сертификат для подписи промежуточного сертификата. Этот промежуточный сертификат затем используется для подписи вашего проверенного сертификата. Вам потребуется предоставить промежуточный сертификат, чтобы мы могли проверить цепочку доверия. Центры сертификации, использующие этот тип цепочки, предоставляют промежуточный сертификат.
Поставка промежуточного сертификата
Дополнительная информация
Поскольку мы знаем, что веб-перехватчики могут быть немного подавляющими, мы работаем над маленьким цифровым помощником, который попытается помочь вам с наиболее распространенными проблемами, это не совсем идеально, но вы можете попробовать использовать @CanOfWormsBot, чтобы проверить, есть ли ваша цепочка сертификатов установлен правильно до обращения в службу поддержки.
Тестирование бота
Мы взяли на себя смелость добавить набор примеров обновлений. Они пригодятся при тестировании вашего бота, независимо от того, какой метод получения обновлений вы используете.
Не паникуйте.
Если вы к настоящему времени ищете свои рыболовные снасти, потому что мы упомянули порты и крючки, или вы собираетесь узнать в Google, что именно такое URL-адрес приманки и TLS, это руководство может быть не полностью для вас. Скорее всего, вы все еще блестящий бот-программист, не волнуйтесь.Возможно, вся эта штука с веб-перехватчиком нова для вас, не все потеряно. Если в настоящее время у вас есть рабочая ситуация с getUpdates, неплохо было бы снова взять это руководство в дождливое воскресенье днем и не торопиться, чтобы почитать некоторые темы в Интернете. В конце концов, это руководство может содержать лишь ограниченное количество информации.

Подробная версия

Как мне получить сервер с доменным именем?

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

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

Если вы здесь застряли, сделайте выбор:

В настоящий момент вы используете getUpdates, и он работает, так и оставьте.Особенно, если вы запускаете своего бота с хорошей машины, которая хорошо себя чувствует. Нет ничего плохого в использовании getUpdates.
Воспользуйтесь размещенной службой и позвольте группе профессионалов позаботиться о таких вещах, как регистрация домена, настройка DNS, веб-сервера, его безопасность и т. Д.

  Если вы выбираете хостинговую услугу, обязательно ищите хостинг-провайдера, который
не только поддерживает потребности вашего кода, например: поддержка вашей версии PHP,
но тот, который также обрабатывает SSL и позволяет создавать / развертывать сертификаты.

Сойди с ума, нырни в интернет и начни читать. Как только вы убедитесь, что у вас есть все основные теории, найдите себе хороший хостинг VPS или разверните свою собственную машину дома и возвращайтесь к нам здесь.

Как проверить открытые порты или ограничить доступ к моему боту?

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

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

Убедитесь, что ваш бот-процесс действительно настроен на прослушивание порта, который вы используете.
netstat –ln | grep portnumber
Показывает, действительно ли ваш бот прослушивает входящие запросы на ожидаемом вами порту.
sudo lsof -i | grep имя процесса
Это простой способ проверить, действительно ли он прослушивается процессом, который использует ваш бот.

Убедитесь, что он правильно слушает.
Ваш бот должен прослушивать адрес, который вы открыли извне (ваш общедоступный IP) , он также может прослушивать все адреса (*: или 0.0.0.0) .
netstat и lsof -команды, упомянутые выше, помогают проверить это. Если ничего не появляется, пора проверить вашу конфигурацию и исправить ее. Установите правильный IP-адрес, убедитесь, что он прослушивает поддерживаемый порт, и запускайте! Просто используйте веб-браузер, чтобы проверить, доступны ли вы.Проблема может быть в конфигурации вашего бота, конфигурации виртуального хоста вашего веб-сервера или конфигурации привязки серверов.

Если вы по-прежнему не можете связаться со своим адресом, проверьте брандмауэр.
sudo iptables –L
OR
sudo ufw status verbose (Ubuntu)
Дает вам некоторое представление о текущих настройках межсетевого экрана.
Если похоже, что вы блокируете входящий трафик, давайте это исправим.
sudo iptables –A INPUT –p tcp –m tcp –dport portnumber -j ACCEPT
OR
sudo ufw allow portnumber / tcp
Разрешает входящий трафик на всех интерфейсах на указанный порт TCP.
sudo iptables –A INPUT –i interfacename –p tcp –m tcp –dport portnumber -j ACCEPT
OR
sudo ufw разрешить имя интерфейса для любого порта номер порта proto tcp
Разрешает входящий трафик на определенный интерфейс и конкретный порт отовсюду.
sudo ifconfig
Помогает найти интерфейс с общедоступным адресом, который вы собираетесь использовать.

  Если вы используете iptables, обязательно СОХРАНИТЕ после изменения конфигурации.
В системе на основе Debian хорошим вариантом будет пакет iptables-persistent.
RHEL / CentOS предлагает сервис iptables save -command.
Также помогает быстрый поиск в Интернете по запросу «YOUROPERATINGSYSTEM save iptables».

Если вам просто нужны советы по ограничению входящего трафика:
sudo iptables –A INPUT –i interfacename –p tcp –m iprange –src-range 149.154.167.197-149.154.167.233 –dport номер порта -j ACCEPT
OR
sudo ufw разрешить по имени интерфейса на любой порт номер порта proto tcp из 149.154.167.192/26
Разрешить входящий трафик на определенный интерфейс и конкретный порт из определенного диапазона адресов. (ufw в примере использует маску подсети в диапазоне от 192 до 255)

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

SSL / TLS, что это такое и почему я должен обрабатывать это для веб-перехватчика?

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

Основное различие между getUpdates и веб-перехватчиком заключается в способе соединения.getUpdates означает, что вы подключитесь к нашему серверу, веб-перехватчик означает, что вместо этого мы подключимся к вашему серверу. Подключение к вашему серверу должно быть безопасным, мы должны знать наверняка, что говорим именно с вами. Это означает, что вам придется заниматься всем этим шифрованием на стороне сервера, фактически представляя нам зеленый замок. Если вы используете веб-сервер для отправки сообщений, вам необходимо поддерживать обработку SSL / TLS на выбранном вами порту / виртуальном хосте. Поиск в Интернете по запросу «YOURWEBSERVER enable HTTPS» поможет вам.

Не используете обычный веб-сервер? Взгляните на нашу страницу с примерами, большинство примеров включают код для обработки SSL / TLS в настройке веб-перехватчика.

Как проверить, что я использую правильную версию?

Вы только что ознакомились со всем, что связано с SSL / TLS, поняли, что это не так уж и плохо в настройке, и мы добавляем еще несколько требований. Вот несколько советов, которые помогут проверить, действительно ли вы поддерживаете TLS1.2.

Существует несколько онлайн-сервисов, которые позволяют проверить установку сертификата,
Они предоставляют обзор поддерживаемых версий TLS / комплектов шифров и других деталей.Найдите в Интернете Symantec crypto report или Qualys ssl . Оба предоставляют инструменты для проверки вашей настройки.
Проверка на месте также может быть выполнена несколькими способами, вот три варианта,
- Проще:
  Используете Chrome в качестве браузера? Откройте URL-адрес своего бота и проверьте данные сертификата. Если вы поддерживаете TLS, Chrome сообщает об этом на вкладке обзора безопасности. Другие браузеры, вероятно, могут предоставить вам аналогичную базовую информацию.
- Использование curl:
  curl --tlsv1.2 -v -k https: // yourbotdomain: yourbotport /
  Вы можете добавить --tlsv1.2 для принудительного использования curl TLS1.2 при попытке подключения. -k является необязательным и используется для проверки самоподписанного сертификата. yourbotdomain — это общедоступное имя хоста, на котором работает ваш веб-перехватчик. Для локального тестирования вы также можете использовать IP. yourbotport — это порт, который вы используете.
- Использование OpenSSL
  openssl s_client -tls1_2 -connect yourbotdomain: yourbotport -servername yourbotdomain
  Вы можете добавить -tls1_2 , чтобы заставить OpenSSL использовать TLS1.2 при попытке подключения. yourbotdomain — это общедоступное имя хоста, на котором работает ваш веб-перехватчик. Для локального тестирования вы также можете использовать IP. yourbotport — это порт, который вы используете. Обратите внимание, что https: // не используется для OpenSSL. -servername является необязательным и включен здесь для некоторых общих хостеров, которые используют SNI для маршрутизации трафика в правильный домен. При использовании SNI вы заметите, что ваш сервер, похоже, возвращает сертификат для домена, отличного от вашего.Добавление -servername yourbotdomain гарантирует, что согласование SNI будет выполнено и будет возвращен правильный сертификат.
Некоторые дополнительные указатели конфигурации
- Принудительное использование TLS на виртуальном хосте на Apache:
  SSLProtocol -all + TLSv1.2
- Принудительное использование TLS на виртуальном хосте на Nginx:
  ssl_protocols TLSv1.2;
- Принудительно использовать TLS для виртуальной машины Java через свойства системы:
  -Dhttps.протоколы = TLSv1.2 -Djdk.tls.client.protocols = TLSv1.2
- Включение отладки ssl для JVM:
  -Djavax.net.debug = ssl, handshake, record
Другие инструменты, которые могут помочь в устранении неполадок:
- Wireshark : отличный захват пакетов
- Tcpdump : одинаково хорошо и не требует графического интерфейса
- Charles : прокси-сервер веб-отладки
- Fiddler : прокси для веб-отладки

Сертификат, где и как его получить?

Вам нужен сертификат, выберите один из этих типов;

Подтвержденный поддерживаемый сертификат
Самоподписанный сертификат
Подтвержденный поддерживаемый сертификат
Использование проверенного сертификата означает, что у вас уже есть или вы получите сертификат, подтвержденный доверенным центром сертификации (CA).Есть много способов получить проверенный сертификат, платный или бесплатный. Двумя популярными примерами бесплатных поставщиков являются StartSSL и Let’s Encrypt . Можете выбрать другой. Просто сначала убедитесь, что поставщик, скорее всего, получит поддержку.
Проверьте этот список перед выбором центра сертификации.
После того, как вы выбрали центр сертификации и подтвердили с ним свою личность, вы можете создать свой сертификат. Это часто начинается с создания CSR (запроса на подпись сертификата). Создание CSR выполняется либо через ваш хост-компьютер, либо онлайн с помощью инструментов, предоставляемых центром сертификации.
Вот пример (вывод в формате PEM).
- Использование OpenSSL:
  openssl req -newkey rsa: 2048 -keyout yourprivatekey.key -out yoursigningrequest.csr

  ----
Создание 2048-битного закрытого ключа RSA для записи нового закрытого ключа в yourprivatekey.key
Введите парольную фразу PEM: введите здесь пароль для вашего ключа
Проверка - введите парольную фразу PEM: подтвердите введенный пароль
-----
Вас сейчас попросят ввести информацию, которая будет включена
в ваш запрос на сертификат.То, что вы собираетесь ввести, называется отличительным именем или DN.
Поля довольно много, но можно оставить пустыми
Для некоторых полей будет значение по умолчанию, если вы введете '.',
поле останется пустым .-----
Название страны (двухбуквенный код) [AU]:
Название штата или провинции (полное название) [Some-State]:
Название населенного пункта (например, город) []:
Название организации (например, компания) [Internet Widgits Pty Ltd]:
Название организационной единицы (например, раздел) []:
Общее имя (например, полное доменное имя сервера или ВАШЕ имя) []: yourbotdomainname
Адрес электронной почты []:
Пожалуйста, введите следующие "дополнительные" атрибуты
для отправки с запросом на сертификат
Пароль вызова []:
Необязательное название компании []:
---

Другой пример:
- Использование Java keytool:
  keytool -genkey -alias yourbotdomainname -keyalg RSA -keystore yourkeystore.jks -размер ключа 2048

  ---
Введите пароль хранилища ключей:
Повторно введите новый пароль:
Ваше имя и фамилия? [Неизвестно]: yourbotdomainname
Как называется ваше организационное подразделение? [Неизвестно]:
Как называется ваша организация? [Неизвестно]:
Как называется ваш город или населенный пункт? [Неизвестно]:
Как называется ваш штат или провинция? [Неизвестно]:
Какой двухбуквенный код страны у этого устройства? [Неизвестно]:
Правильно ли CN = test.telegram.org, OU = Unknown, O = Unknown, L = Unknown, ST = Unknown, C = Unknown?
[нет да
Введите ключевой пароль для вашего бот-домена
(ВОЗВРАТ, если такой же, как пароль хранилища ключей):
---

Это создает начальное хранилище ключей, из которого затем можно создать CSR следующим образом:

keytool -certreq -alias yourbotdomainname -keystore yourkeystore.jks -файл yourbotdomainname.csr

  ---
Введите пароль хранилища ключей:
---

Для проверки сертификата общее имя (CN) должно соответствовать вашему домену веб-перехватчика. Например, если вы используете https://www.example.com/example.php в качестве адреса веб-перехватчика, CN сертификата должен быть www.example.com.
Итак, вам нужно , точное совпадение с полным доменным именем, которое вы устанавливаете для веб-перехватчика

Существует исключение, если вы используете SAN (альтернативное имя субъекта), адрес веб-перехватчика может совпадать с номером CN вашего сертификата, ИЛИ с одним из SAN, указанным в сертификате.В большинстве случаев вы будете использовать CN.

Создайте CSR и передайте содержимое файла в CA. Большинство CA достаточно любезны, чтобы дать вам пример команды формата ввода, который они ожидают.

cat yoursigningrequest.csr или cat yourbotdomainname.csr
Позволяет вам взглянуть на только что сгенерированный CSR:

Это не кажется информативным, но мы можем сделать вывод, что файл имеет формат PEM (в кодировке ASCII base64) и содержит запрос на подпись сертификата.К счастью, можно посмотреть на удобочитаемое содержимое CSR. Используйте следующие команды, чтобы дважды проверить правильность установки всех полей.

Подтвердите свой CSR и предоставьте его в центр сертификации, чтобы получить сертификат. В качестве примера мы будем использовать StartSSL. StartSSL позволяет вам установить до 5 имен (SAN). Их промежуточный сертификат также необходим для работы веб-перехватчика, что является хорошим полным примером.

Перейдите к мастеру сертификатов, введите требуемые имена хостов для вашего сертификата SSL (это CN, который вы также установили в CSR и необязательном SAN).

В приведенном выше примере мы выбрали для установки CN (test.telegram.org) , но также и SAN (sanexample.telegram.org) . Указанный CN должен соответствовать CN, используемому для генерации CSR.
Установите свой CN (и дополнительный SAN) и скопируйте содержимое файла yoursigningrequest.csr.

Вставьте содержимое, отправьте и все готово.

Теперь вы можете напрямую загрузить созданный сертификат. В приведенном выше примере вы получите zip-файл с несколькими сертификатами PEM.Корневой, промежуточный и сертификат вашего домена.
Вам нужны промежуточные и yourdomain , чтобы установить веб-перехватчик с сертификатом StartSSL.

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

Теперь, когда у вас есть свежие сертификаты, вы можете продолжить настройку веб-перехватчика.

Самоподписанный сертификат
Использование самозаверяющего сертификата означает, что вы потеряете цепочку доверия, поддерживаемую центром сертификации.Вместо этого вы СА. Чтобы это работало, требуется небольшая разница в настройке. Поскольку Telegram не будет иметь цепочки доверия для проверки вашего сертификата, вы должны использовать сгенерированный общедоступный сертификат в качестве входного файла при настройке веб-перехватчика. Имейте в виду, что файл сертификата должен быть загружен как данные multipart / form в кодированном формате PEM (ASCII BASE64) .
Сначала сгенерируем сертификаты:
- Использование OpenSSL:
  openssl req -newkey rsa: 2048 -sha256 -nodes -keyout ВАШ ЧАСТНЫЙ.key -x509 -days 365 -out YOURPUBLIC.pem -subj "/ C = US / ST = New York / L = Brooklyn / O = Example Brooklyn Company / CN = YOURDOMAIN.EXAMPLE"
  У вас будет 2 файла , закрытый ключ и файл открытого сертификата. Используйте YOURPUBLIC.PEM в качестве входного файла для настройки веб-перехватчика.
- Использование Java keytool:
  keytool -genkey -keyalg RSA -alias YOURDOMAIN.EXAMPLE -keystore YOURJKS.jks -storepass YOURPASSWORD -validity 360 -keysize 2048
```
  Как ваше имя и фамилия?
[контрольная работа.telegram.org]:
Как называется ваше организационное подразделение?
[Неизвестно]:
Как называется ваша организация?
[Неизвестно]:
Как называется ваш город или населенный пункт?
[Неизвестно]:
Как называется ваш штат или провинция?
[Неизвестно]:
Какой двухбуквенный код страны у этого устройства?
[Неизвестно]:
Правильно ли CN = test.telegram.org, OU = Unknown, O = Unknown, L = Unknown, ST = Unknown, C = Unknown?
[нет]: да  
```
  После этого вам понадобятся еще 2 команды для экспорта файла общедоступного сертификата из созданного хранилища (вы будете использовать хранилище для вашей JVM и PEM для настройки веб-перехватчика)
- Преобразование JKS в pkcs12 (промежуточный шаг для преобразования в PEM):
  keytool -importkeystore -srckeystore YOURJKS.jks -destkeystore YOURPKCS.p12 -srcstoretype jks -deststoretype pkcs12
- Конвертировать PKCS12 в PEM (требуется OpenSSL)
  openssl pkcs12 -in YOURPKCS.p12 -out YOURPEM.pem -nokeys
- Использование Windows:
  Создание самозаверяющего сертификата с использованием собственных утилит Windows также возможно, хотя двоичные файлы OpenSSL для Windows доступны в Интернете.
  certreq -new TEMPLATE.txt RequestFileOut создает CSR.
- ШАБЛОН.txt, пример файла:
```
  [NewRequest]
; В этом разделе должно быть установлено хотя бы одно значение
Subject = "CN = DOMAIN.EXAMPLE"
KeyLength = 2048
KeyAlgorithm = RSA
HashAlgorithm = sha256
; MachineKeySet = true
RequestType = Cert
UseExistingKeySet = false; генерирует новый закрытый ключ (для экспорта)
Exportable = true; делает закрытый ключ экспортируемым с помощью PFX  
```

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

Окна продолжение:
- Вы можете посмотреть сертификаты в своем магазине с помощью:
  certutil -store -user my
- Чтобы экспортировать установленный сертификат в формате DER (промежуточный шаг для преобразования в PEM):
  certutil -user -store -split my SERIALNUMBER YOURDER.der
- Теперь вы можете преобразовать сертификат в PEM:
  certutil -encode YOURDER.der YOURPEM.pem
  Помните, что в качестве входных данных для параметра самозаверяющего сертификата веб-перехватчика требуется только общедоступный сертификат.
  certmgr.msc также можно использовать как графический интерфейс для экспорта общедоступной части самозаверяющего сертификата в PEM.

После выполнения вышеизложенного вы получите красивый самоподписанный сертификат. Вам все равно придется настроить веб-перехватчик и правильно обрабатывать SSL.

Как установить перехватчик для любого типа?

Метод setWebhook необходим для обоих типов.Для подтвержденного сертификата с доверенным корневым ЦС достаточно использовать метод setWebhook только с параметром URL.

Пример curl для подтвержденного сертификата:
curl -F "url = https: // / " https://api.telegram.org/bot/setWebhook

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

Пример curl для самоподписанного сертификата:
curl -F "url = https: // / "-F" certificate = @ .pem "https://api.telegram.org/bot/setWebhook

-F означает, что мы используем multipart / form-data -type для предоставления сертификата, тип параметра сертификата — inputFile. Убедитесь, что вы используете правильный тип.

Оба параметра для метода setWebhook классифицируются как необязательные. Вызов метода с пустым параметром URL-адреса можно использовать для очистки ранее установленного веб-перехватчика.

Пример curl для очистки предыдущего веб-перехватчика:
curl -F "url =" https://api.telegram.org/bot/setWebhook

Имейте в виду, что параметр URL начинается с https: // при настройке веб-перехватчика. По умолчанию это означает, что мы стучимся к вам через порт 443. Если вы хотите использовать другой порт (80,88 или 8443), вам необходимо указать порт в параметре URL.

Пример:
url = https: // : 88 /

Установка проверенного веб-перехватчика с ненадежным корнем

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

Пример curl для предоставления ненадежного корневого сертификата:
curl -F "url = https: // " -F "certificate = @ .pem" https: //api.telegram. org / bot / setWebhook
Прежде чем вы сможете это сделать, вам понадобится корневой сертификат центра сертификации вашего сертификата. Большинство центров сертификации предоставляют свои корневые сертификаты в нескольких различных форматах (PEM / DER и т. Д.). Посетите веб-сайт вашего центра сертификации и загрузите корневой сертификат, указанный для вашего подтвержденного сертификата.

Эти команды можно использовать для быстрого преобразования корневого сертификата в формате DER в PEM:

Использование OpenSSL:
openssl x509 -inform der -in root.cer -out root.pem
Использование Java keytool:
keytool -import -alias Root -keystore YOURKEYSTORE.JKS -trustcacerts -file ROOTCERT.CER
Сначала в хранилище ключей необходимо импортировать корневой сертификат:
keytool-Roexportcert -fileias <ВАШ РОУТПЕМФАЙЛ.PEM> -rfc -keystore YOURKEYSTORE.JKS

После этого настройте веб-перехватчик с помощью root-pem-файла, и все будет хорошо. Если вам нужно больше указателей, взгляните на самозаверяющую часть этого руководства.

Поставка промежуточного сертификата

После того, как вы создали свой сертификат, ваш центр сертификации может предоставить вам красивый комплект. Большинство пакетов содержат корневой сертификат, ваш публичный сертификат, а иногда и промежуточный сертификат .StartSSL — один из многих центров сертификации, предлагающих такого промежуточного звена. Этот сертификат должен быть включен в цепочку сертификатов, которые вы предоставляете нам, когда мы подключаемся к вашему серверу. Если для подписи вашего сертификата использовалось промежуточное звено, но оно не отправлено на наши серверы, мы не сможем проверить цепочку доверия, и ваш веб-перехватчик не будет работать.

Если ваш веб-перехватчик не работает и вам интересно, завершена ли цепочка:

Вот пример полной цепочки, обратите внимание, что в этом случае было предоставлено 2 промежуточных сертификата.

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

Apache:
Добавьте промежуточный сертификат в конец файла, настроенного в директиве SSLCertificateFile конфигурации вашего виртуального хоста. Если вы используете более старую версию, чем Apache 2.4.8, вы можете использовать вместо нее директиву SSLCertificateChainFile .
Nginx:
Добавьте промежуточный сертификат в конец файла, настроенного в директиве ssl_certificate_key конфигурации вашего виртуального хоста.
Быстрая команда для правильного выполнения этого действия:
cat your_domain_name.pem intermediate.pem >> bundle.pem
Убедитесь, что порядок правильный, иначе ожидайте неудачи.
Java keytool:
keytool -import -trustcacerts -alias промежуточный -файл промежуточный.pem -keystore YOURKEYSTORE.jks

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

Тестирование бота с обновлениями

Страница не найдена

Документы Моя библиотека
раз
Моя библиотека
«» Настройки файлов cookie
Как установить сертификат SSL на ваш сайт
← Документы ServerPilot
Наличие SSL-сертификата на вашем сайте — один из лучших способов создания доверяйте своим посетителям, особенно если ваш сайт является интернет-магазином.SSL создает частное зашифрованное соединение от вашего сервера к вашему браузеры посетителей и позволяет передавать личную информацию без подслушивание, фальсификация или подлог.
ServerPilot предлагает два способа развертывания SSL на вашем сайте: с помощью одного из Бесплатные сертификаты AutoSSL ServerPilot или развернув сертификат, который вы куплен в центре сертификации (CA).
После того, как вы развернули SSL, вы можете включить перенаправление на HTTPS.
Метод первый: использование AutoSSL
ServerPilot AutoSSL выдает, развертывает и обновляет доверенные сертификаты SSL в ваши приложения автоматически.
Прежде чем AutoSSL станет доступным для приложения, вы должны сначала добавить домены приложения в ServerPilot.
После добавления доменов приложения у вас будет опция AutoSSL. доступно на вкладке SSL вашего приложения.
Нажмите Включить AutoSSL , и ServerPilot включит SSL для вашего приложения. с использованием сертификата AutoSSL.
Этот сертификат будет автоматически продлен ServerPilot перед истекает.
Метод второй: предоставление собственного сертификата SSL
Этот метод проведет вас через весь процесс покупки собственного SSL-сертификат и установка его через ServerPilot.
Шаг первый: создание ключа SSL и CSR
Создание ключа SSL и запроса на подпись сертификата (CSR) является первым Шаг к обеспечению безопасного доступа к вашему сайту через HTTPS.
Использование ServerPilot — самый простой способ создать свой ключ и CSR.
Сначала перейдите на вкладку SSL вашего приложения в ServerPilot.
Вы увидите, что SSL не включен.
Теперь введите домен вашего приложения, а затем ваше местоположение и название организации. Щелкните Generate Key и CSR .
SSL теперь будет отображаться как включенный в вашем приложении, а ServerPilot отобразит ваш SSL-ключ приложения и CSR.
Шаг второй: приобретение подписанного сертификата SSL
После создания ключа SSL и CSR вам нужно будет купить подписанный SSL. сертификат от CA. ЦС выдает цифровой сертификат, подтверждающий, что вы являетесь владельцем открытый ключ вашего приложения.
Одним из вариантов недорогого SSL-сертификата является PositiveSSL сертификат от Namecheap.ServerPilot не имеет отношения к Namecheap, PositiveSSL или Комодо. Мы упоминаем этот вариант только потому, что он недорогой, и мы считаем, что они будет выдавать сертификаты, которые работают, когда ваш домен доступен как с и без www.
При покупке сертификата выберите Nginx в качестве типа сервера. Если Nginx недоступен в качестве опции в вашем ЦС, выберите либо Apache или Apache + OpenSSL.
Вы получите файл YOUR_DOMAIN.crt. (Этот файл может содержаться в архиве с другими файлами.)
Откройте файл .crt. Его содержимое — это ваш SSL-сертификат. Скопируйте содержимое файла .crt и вернитесь к SSL вашего приложения. вкладка в ServerPilot.
Вставьте содержимое файла .crt в это поле и нажмите Обновите ключ SSL и сертификаты .
Теперь посетите свой сайт, используя HTTPS, чтобы убедиться, что ваш сертификат работает. Он должен загружаться через HTTPS и отображать небольшую блокировку в адресной строке.
Принудительное перенаправление HTTP на HTTPS
Если вы хотите, чтобы пользователи видели HTTPS-версию вашего сайта при их посещении вы можете принудительно использовать SSL, перенаправив все HTTP-запросы на HTTPS.
Просто нажмите Перенаправить HTTP на HTTPS .
.

*Narcosis* by STORM

Как на сервере сделать сертификат: Как создать SSL сертификат самостоятельно?

Как создать SSL сертификат самостоятельно?

Что следует учесть перед созданием сертификата?

Создать сертификат: пошаговая инструкция

Привязать сертификат к серверу

как его создать и найти?

Сохранность приватного ключа SSL

Как найти приватный ключ SSL?

Как создать закрытый ключ?

Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему

Установка сертификата на HTTP сервер Apache / Блог компании GlobalSign / Хабр

Глава 4. Работа с сертификатами

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

Как это сделать…

Как это работает.<img src='/800/600/https/www.pvsm.ru/images/2017/05/17/draiver-podmeny-sertifikatov-3.png' /> ..

Также ознакомьтесь…

Построение подчинённого сервера Сертификационной авторизации

Как это сделать…

Как это работает…

Также ознакомьтесь…

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

Как это сделать…

<img src='/800/600/https/windows-school.ru/images/winfaq/win10/sertifikat-upravlenie-dispet.png' /> w3.org/1999/xhtml»> Как это работает…

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

Как это сделать…

Как это работает…

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

Как это сделать.<img src='/800/600/https/cdn.freelance.ru/img/portfolio/pics/00/3A/75/3831040.jpg?mt=21d33c06' /> ..

Как это работает…

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

Как это сделать…

Как это работает…

Настройка Autoenrollment для выдачи сертификатов всем доменам, объединённым в систему

Как это сделать…

Как это работает…

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

Как это сделать…

Как это работает…

Настройте шаблон сертификата сервера

В этой статье

Для настройки шаблона сертификата

Marvelous Guide to All Things Webhook

Укороченная версия

Более длинная версия

Доменное имя

Открытый порт

Всегда SSL / TLS

Не все SSL / TLS одинаковы

SSL требуется сертификат

Подтверждено или самоподписано

Поддерживаемые сертификаты

Недоверенный корень

Промежуточные сертификаты

Дополнительная информация

Тестирование бота

Не паникуйте.

Подробная версия

Как мне получить сервер с доменным именем?

Как проверить открытые порты или ограничить доступ к моему боту?

SSL / TLS, что это такое и почему я должен обрабатывать это для веб-перехватчика?

Как проверить, что я использую правильную версию?

Сертификат, где и как его получить?

Подтвержденный поддерживаемый сертификат

Самоподписанный сертификат

Как установить перехватчик для любого типа?

Установка проверенного веб-перехватчика с ненадежным корнем

Поставка промежуточного сертификата

Тестирование бота с обновлениями

Страница не найдена

Моя библиотека «» Настройки файлов cookie

Как установить сертификат SSL на ваш сайт

Метод первый: использование AutoSSL

Метод второй: предоставление собственного сертификата SSL

Шаг первый: создание ключа SSL и CSR

Шаг второй: приобретение подписанного сертификата SSL

Принудительное перенаправление HTTP на HTTPS

Добавить комментарий Отменить ответ

Narcosis by STORM

Как это работает. ..

w3.org/1999/xhtml»> Как это работает…

Как это сделать. ..

Моя библиотека
«» Настройки файлов cookie