SSTP and IKEv2 use different RRAS certificate controls

Replace "the VPN certificate" and you may change the wrong service. RRAS keeps at least three certificate controls, each belonging to a different protocol and connection role. Naming the protocol first turns a risky guess into a single, reversible binding change. Everything below depends on that one sentence.

Name the protocol before the certificate

An SSTP listener presents a TLS certificate to a client that behaves like HTTPS. An incoming site-to-site IKEv2 connection advertises a server identity and validates peer certificates against a trusted root. A per-interface site-to-site definition carries a machine identity of its own.

Those are three controls with three scopes. Confusing them produces a change that seems to work on one protocol and has no effect on the other, which is worse than an obvious failure. Write down which protocol failed, which side presented the certificate and which side rejected it before touching anything.

SSTP is an HTTPS binding

For supported Remote Access deployments, Set-RemoteAccess exposes an SslCertificate parameter used for SSTP connectivity and for the HTTPS-related DirectAccess role.

Its validation and deployment scope follow the Remote Access configuration, so one binding change can reach more than one connection or node. In a load-balanced deployment that scope includes every node the configuration covers. Changing one node and testing one client leaves the rest presenting the old leaf, which is the kind of half-change that survives a maintenance window.

Verify the expected service name, chain, validity, intended usage and private-key availability before the update. The certificate has to match the name the client will check, and an adapter label is not that name.

Incoming IKEv2 has its own parameter

Set-VpnAuthProtocol configures incoming site-to-site IKEv2 authentication, and CertificateAdvertised supplies a certificate when the tunnel authentication mode uses them. It is not a general command for choosing any server certificate on the host.

Keep two objects apart: the leaf the server presents as its own identity, and the root it uses to accept peer certificates. Picking which issuer you trust says nothing about which leaf the server presents.

An individual site-to-site interface's identity is set through Set-VpnS2SInterface. It is not automatically the SSTP certificate, even when both sit in the same store on the same machine.

Inspect the candidate first

A focused view of the local machine store shows public metadata without exporting anything private:

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

That listing is a starting point rather than a suitability test. Inspect the SAN entries, the enhanced key usages, the chain and the service account's private-key access for the protocol you are configuring.

A certificate installed for an unrelated cloud client identity is not suitable just because it appears in the same store. Visibility is not eligibility, and a thumbprint in a screenshot proves nothing about whether the service account can read the key. Check that access explicitly, because a missing key permission fails only when the service restarts and tries to use the certificate.

Record the current binding and confirm you can still reach the host another way before changing it. The recovery path belongs to the change, not to the incident that follows.

Renewal is not activation

Reissuing a certificate is a different action from selecting it for the running service. The new leaf can keep the intended DNS identity and still carry a different thumbprint, so nothing points at it until the binding is updated. Renewal changes the object; activation changes the reference to it. Confusing the two is why a correctly renewed certificate can sit unused for weeks.

Apply the supported change in an appropriate window, including any documented restart, then inspect the certificate from a fresh connection of the intended protocol. A cached client session may still show the old leaf and make a correct change look broken.

Retire the previous certificate through the normal process only after that check passes. The Set-RemoteAccess reference documents the SSL parameter's scope, including its effect in load-balanced deployments, which is the part worth reading before a binding change.