SSTP и IKEv2 използват различни контроли на сертификати в RRAS

Ако замените „VPN сертификата“, може да промените грешната услуга. RRAS поддържа поне три контрола на сертификати, всяка от които принадлежи на различен протокол и различна роля на връзката. Ако първо назовете протокола, рискованото предположение се превръща в една обратима промяна на връзката. Всичко по-долу зависи от това едно изречение.

Назовете протокола преди сертификата

Слушателят SSTP представя TLS сертификат на клиент, който се държи като HTTPS. Входяща връзка IKEv2 между сайтове обявява идентичност на сървъра и проверява сертификатите на партньорите спрямо доверен корен. Дефиниция между сайтове за интерфейс носи собствена идентичност на машината.

Това са три контрола с три обхвата. Объркването им създава промяна, която изглежда работи на единия протокол и няма ефект на другия, което е по-лошо от очевиден отказ. Запишете кой протокол е отказал, коя страна е представила сертификата и коя го е отхвърлила, преди да докоснете нещо.

SSTP е връзка HTTPS

За поддържани внедрявания на Remote Access Set-RemoteAccess предоставя параметър SslCertificate, който се използва за SSTP свързаност и за ролята DirectAccess, свързана с HTTPS.

Обхватът му на проверка и внедряване следва конфигурацията на Remote Access, така че една промяна на връзката може да достигне до повече от една връзка или възел. При внедряване с балансиране на натоварването този обхват включва всеки възел, който конфигурацията покрива. Промяна на един възел и тестване на един клиент оставя останалите да представят стария краен сертификат, а това е точно онази половинчата промяна, която преживява сервизен прозорец.

Преди актуализацията проверете очакваното име на услугата, веригата, валидността, предназначението и наличността на частния ключ. Сертификатът трябва да съвпада с името, което клиентът ще провери, а етикетът на адаптера не е това име.

Входящият IKEv2 има собствен параметър

Set-VpnAuthProtocol конфигурира удостоверяването на входящия IKEv2 между сайтове, а CertificateAdvertised доставя сертификат, когато режимът за удостоверяване на тунела ги използва. Това не е обща команда за избор на който и да е сървърен сертификат на хоста.

Дръжте разделени два обекта: крайния сертификат, който сървърът представя като собствена идентичност, и корена, който използва, за да приема сертификати на партньори. Изборът на издател, на когото вярвате, не казва нищо за това кой краен сертификат представя сървърът.

Идентичността на отделен интерфейс между сайтове се задава чрез Set-VpnS2SInterface. Това не е автоматично SSTP сертификатът, дори когато и двата лежат в едно и също хранилище на една и съща машина.

Първо прегледайте кандидата

Фокусиран изглед на хранилището на локалната машина показва публични метаданни, без да експортира нищо частно:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Този списък е отправна точка, а не тест за пригодност. Прегледайте SAN записите, разширените употреби на ключа, веригата и достъпа на сервизния акаунт до частния ключ за протокола, който конфигурирате.

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

Запишете текущата връзка и потвърдете, че все още можете да достигнете до хоста по друг начин, преди да я промените. Пътят за възстановяване е част от промяната, а не от инцидента, който следва.

Подновяването не е активиране

Повторното издаване на сертификат е различно действие от избирането му за работещата услуга. Новият краен сертификат може да запази предвидената DNS идентичност и въпреки това да носи различен отпечатък, така че нищо не сочи към него, докато връзката не се актуализира. Подновяването променя обекта; активирането променя препратката към него. Объркването на двете е причината правилно подновен сертификат да може да стои неизползван със седмици.

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

Изведете предишния сертификат от употреба по обичайния процес само след като тази проверка премине. Справката за Set-RemoteAccess документира обхвата на SSL параметъра, включително ефекта му при внедрявания с балансиране на натоварването, а това е частта, която си струва да се прочете преди промяна на връзката.