Сертификаты для IKEv2/SSTP на Windows Server через встроенный CA

MAATRIX

IKEv2 и SSTP не работают на предустановленных сертификатах — обоим протоколам нужен полноценный сертификат сервера с корректным именем, а клиентам, если вы хотите аутентификацию без пароля, ещё и клиентские сертификаты. Покупать сертификат у публичного центра ради внутреннего VPN избыточно и неудобно для повторяющихся клиентских сертификатов, поэтому проще поднять собственный CA прямо на Windows Server через роль Active Directory Certificate Services. Ниже — весь путь: установка роли, шаблоны, выпуск серверного и клиентских сертификатов, привязка к RRAS и типичные грабли.

Зачем свой CA, а не Let's Encrypt

Let's Encrypt отлично закрывает SSTP, если у вас есть публичное доменное имя и сервер видно снаружи по 443 порту — SSTP работает поверх HTTPS, и сертификат от публичного CA там подходит без вопросов. Проблема начинается там, где нужен ещё и IKEv2 с клиентскими сертификатами: Let's Encrypt не выпускает сертификаты для аутентификации клиентов, только для доменных имён серверов. Второй момент — если сервер стоит без публичного DNS-имени (только по IP) или в закрытом контуре офиса, ACME-валидация Let's Encrypt вообще не пройдёт.

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

Для одного сервера и десятка клиентов это оправдано почти всегда. Если у вас уже настроен туннель на Windows Server для семьи или офиса на WireGuard, здесь логика похожая — только вместо пар ключей WireGuard вы штампуете сертификаты X.509, и Windows делает это через встроенный мастер шаблонов.

Устанавливаем роль AD CS

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

Через PowerShell от администратора:

Install-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "MAATRIX-VPN-CA" `
  -KeyLength 2048 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 10

StandaloneRootCA подходит, если сервер не в домене Active Directory — большинство VPN-серверов на выделенных хостах именно так и стоят. Если у вас развёрнут домен и все клиенты в него включены, логичнее EnterpriseRootCA — тогда шаблоны сертификатов и автовыдача через групповые политики работают без ручного экспорта, но для одиночного сервера это избыточная сложность.

После установки проверьте, что служба поднялась:

Get-Service CertSvc
certutil -CAInfo

Веб-интерфейс для запроса сертификатов (certsrv) по умолчанию не установлен — для standalone CA он не обязателен, весь выпуск можно делать через оснастку certsrv.msc и certreq локально на сервере.

Шаблоны сертификатов: сервер и клиент

Для полноценного Enterprise CA шаблоны настраиваются через certtmpl.msc — там дублируются встроенные шаблоны "Компьютер" (Server Authentication) и "Проверка подлинности клиента" под свои имена, задаётся EKU (Extended Key Usage) и права выдачи. Для Standalone CA консоль шаблонов недоступна — вместо шаблонов вы формируете INF-файлы запроса вручную, и это на самом деле не сложнее, а даже нагляднее.

INF-файл для серверного сертификата (server-request.inf):

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=vpn.example-office.local"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1

OID 1.3.6.1.5.5.7.3.1 — это Server Authentication, обязательный EKU для IKEv2 и SSTP. Subject CN должен точно совпадать с тем именем или IP, которое клиенты используют для подключения — это самая частая причина, по которой сертификат выпускается, но VPN всё равно не соединяется.

Для клиентских сертификатов EKU другой — Client Authentication (1.3.6.1.5.5.7.3.2), и Subject уникален для каждого пользователя, например CN=ivanov-notebook.

Выпуск и привязка сертификата сервера к RRAS

Генерируем запрос и отправляем его на локальный CA:

certreq -new server-request.inf server-request.req
certreq -submit -config "SERVERNAME\MAATRIX-VPN-CA" server-request.req server-cert.cer
certreq -accept server-cert.cer

Команда -accept кладёт выпущенный сертификат вместе с закрытым ключом в хранилище LocalMachine\My — именно там его ищет RRAS при настройке IKEv2. Проверить, что сертификат на месте и с закрытым ключом:

Get-ChildItem Cert:\LocalMachine\My | Format-List Subject, Thumbprint, HasPrivateKey

Дальше сертификат привязывается к RRAS. Если RRAS уже настроен и работает на самоподписанном или предыдущем сертификате, проще пересоздать привязку через оснастку Маршрутизация и удалённый доступ → правая кнопка на сервере → Свойства → вкладка "Безопасность" → выбрать нужный сертификат в выпадающем списке для SSL-сертификата. Через PowerShell то же самое:

$thumb = (Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*vpn.example-office.local*").Thumbprint
Set-VpnServerConfiguration -CustomPolicy -SslCertificate $thumb
Restart-Service RemoteAccess

После перезапуска службы IKEv2 и SSTP уже используют новый сертификат — проверьте это в логах подключения на клиенте или командой netsh ras show client на сервере после тестового подключения. Если сервер стоит за NAT или у него несколько сетевых интерфейсов, дополнительно проверьте настройку файрвола для VPN-туннеля — сертификат не поможет, если 443 или 500/4500 порты закрыты снаружи.

Выпуск и экспорт клиентских сертификатов

Клиентский сертификат нужен только тогда, когда вы хотите аутентификацию по сертификату вместо (или вместе с) логина и пароля EAP-MSCHAPv2 — для SSTP это не обязательно, а для IKEv2 машинная сертификатная аутентификация даёт заметно более надёжное соединение, чем PSK на несколько человек.

Генерация клиентского сертификата аналогична серверному, только с EKU Client Authentication и Exportable = TRUE, чтобы можно было экспортировать вместе с закрытым ключом:

[NewRequest]
Subject = "CN=ivanov-notebook"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.2

certreq -new client-ivanov.inf client-ivanov.req
certreq -submit -config "SERVERNAME\MAATRIX-VPN-CA" client-ivanov.req client-ivanov.cer
certreq -accept client-ivanov.cer

Дальше сертификат экспортируется в PFX (PKCS#12) с закрытым ключом для передачи пользователю:

$cert = Get-ChildItem Cert:\CurrentUser\My | Where-Object Subject -eq "CN=ivanov-notebook"
$pwd = ConvertTo-SecureString -String "TempPass123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\certs\ivanov.pfx" -Password $pwd

Пользователю нужны два файла: сам .pfx (импортируется двойным кликом в Windows, или через настройки VPN-профиля в iOS/Android) и корневой сертификат CA в формате .cer без закрытого ключа — его нужно установить в "Доверенные корневые центры сертификации", иначе клиент не будет доверять сертификату сервера:

certutil -ca.cert root-ca.cer

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

Проверка, типичные ошибки и продление

Самая частая ошибка при подключении IKEv2 — "не удалось проверить учётные данные" при том, что и сервер, и клиент настроены вроде бы правильно. В 90% случаев причина в CN сертификата: он должен буквально совпадать со строкой, которую вводит клиент при подключении (доменное имя или IP), а не с внутренним hostname сервера. Проверить CN уже выпущенного сертификата:

certutil -dump server-cert.cer | Select-String "Subject"

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

Список отзыва (CRL) для standalone CA по умолчанию не публикуется автоматически по расписанию — если вы отзываете клиентский сертификат через certsrv.msc → Отозванные сертификаты, не забудьте опубликовать новый CRL, иначе отозванный сертификат продолжит проходить проверку:

certutil -crl

Сравнение подходов к аутентификации VPN на Windows Server:

Срок действия сертификатов, которые вы задали при генерации (ValidityPeriod), стоит держать в календаре отдельно — у RRAS нет автоматического напоминания об истечении, и просроченный серверный сертификат останавливает все подключения разом. Логика продления такая же, как в проблемах с автообновлением Let's Encrypt — только здесь обновление ручное: перевыпуск INF-запроса с тем же CN и повторная привязка к RRAS через Set-VpnServerConfiguration.

Частые вопросы