RRAS: To use SSTP behind a NAT router, the certificate subject name must match the NAT address
Applies To: Windows Server 2008 R2, Windows Server 2012, Windows Storage Server 2012
This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the Network Policy and Access Service (NPAS) Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer.
Windows Server 2012, Windows Server 2008 R2
Routing and Remote Access Service (RRAS)
RRAS cannot determine if a certificate valid for SSTP is present on the RRAS server. If your server is behind a NAT router, then the subject name of the certificate must match the DNS name or IP address of the external interface of the router.
If you do not have a correctly configured and accessible SSTP certificate, then remote access clients cannot communicate with the RRAS server by using an SSTP tunnel.
Your Routing and Remote Access server must be configured with a certificate that it can present to client computers upon connection for authentication. The subject name of the certificate must match the DNS name or IP address to which the client is attempting to connect.
If your Routing and Remote Access server is not located behind a network address translating (NAT) device and is directly accessible to your client computers, then this rule indicates a non-compliance condition because the BPA could not find a certificate suitable for use by SSTP.
If your Routing and Remote Access server is located behind a network address translating (NAT) device, then the subject name on the certificate must have the DNS name or IP address of the external interface of the NAT instead of the Routing and Remote Access server. Because the BPA cannot determine the name or address of the NAT device, it cannot determine if any installed certificates meet those requirements. If this is the case, then you must manually examine your certificates to ensure that they are appropriate for the NAT connection used by your client computers.
A valid certificate for SSTP must meet the following requirements:
The certificate is configured with the Server Authentication purpose or the All Purposes purpose in the Enhanced Key Usage (EKU) extensions.
The certificate has a private key.
The certificate is not expired.
The subject name of the certificate is the IP address of the external interface on the remote access server, or a regular expression containing a DNS name that resolves to that IP address. If the remote access server is located behind a NAT device, then the IP address or DNS name must be that of the external interface of the NAT device.
Use the Certificates MMC snap-in to request and configure a certificates for SSTP that specifies a subject name matching the DNS name or IP address of the external interface of the NAT router that is between the RRAS server and the remote access clients.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.
To view the certificates in the local computer store
Start the Microsoft Management Console. Click Start, type MMC, and then press ENTER.
Click File and then click Add/Remove Snap-in.
In the Available snap-ins list, select Certificates and then click Add.
Select Computer account, and then click Next.
Select Local computer, click Finish, and then click OK.
Expand Certificates (Local Computer), expand Personal, and then expand Certificates
Double-click a certificate to see the details.
On the Details tab, select Enhanced Key Usage to see in the box below the currently assigned purposes.
Click OK to close the dialog box.
For more about creating certificates by using the Active Directory Certificate Services server role, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?linkid=136444) in the Windows Server Technical Library.
For more about the Routing and Remote Access role service, see Routing and Remote Access (http://go.microsoft.com/fwlink/?linkid=153482) on TechNet, and Routing and Remote Access Service in the Windows Server Technical Library.