Azure-docs: VPN gateway offers certificate with a different subject to the DNS name

[webash]

For some reason VPN gateway responds to IKEv2 connectivity requests with a certificate containing a subject that doesn't match the FQDN used to find/request the gateway endpoint.

For example, say the gateway I configure my VPN client to connect to is the FQDN azuregateway-01234567-890A-BCDE-F0123-4567890ABCDE-a1b2c3d4e5f6.vpn.azure.com. When I connect to that using a VPN client configured through something like Intune or manually, then I receive a certificate error because the name returned in the subject for the gateway endpoint's certificate is: 01234567-890A-BCDE-F0123-4567890ABCDE.vpn.azure.com

What's interesting is that this second name doesn't resolve...unless you are on Microsoft internal network.

Is this expected behaviour? _If so, it should be documented in this page somehow_, explaining why the certificate for the endpoint has a name mismatch. Otherwise, I see this as a bug; because we should not be allowing users the possibility of being exposed to accepting certificates that have a name mismatch.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a3113b20-0f6c-988e-444b-eff387f3ffef
• Version Independent ID: ded2a816-93c7-a4b3-1ec2-c29ce86cd492
• Content: About Azure Point-to-Site VPN connections
• Content Source: articles/vpn-gateway/point-to-site-about.md
• Service: vpn-gateway
• GitHub Login: @cherylmc
• Microsoft Alias: cherylmc

[SumanthMarigowda-MSFT]

@webash Thanks for your question. We are checking on this and will respond to you soon.

[msrini-MSFT]

@webash , It is by design and I will assign this issue to the content author to validate and update the doc.

[cherylmc]

reassign:anzaman

[webash]

Thanks @msrini-MSFT . I wonder if it would be prudent for the VPN setup package that is downloaded from the portal to communicate this in the ProfileXML, too.

[webash]

Any update here?

[anzaman]

PR merged

[webash]

The advice that people should ‘Un-check "Verify the server's identity by validating the certificate"’ is _extremely_ dangerous advice. That then means that users of that VPN would be vulnerable to malicious attacks on their connectivity, should their traffic or DNS queries be MITM’d or otherwise co-opted. TLS certificate verification should never be bypassed in this way!

The second option provided of ‘add the server FQDN along with the certificate’ doesn’t specify what this FQDN should be; the documentation should spell out the structure of the certificate name, versus the DNS name. Otherwise, again, if there is malicious MITM or DNS, the cert name they end up trusting could be wrong. This should really be the only option provided.

[anzaman]

With Azure certificate authentication the same certificate is being used for server validation in the VPN tunneling protocol (IKEv2/SSTP) and the EAP protocol. Since the server certificate and FQDN is already validated by the VPN tunneling protocol, it is redundant to validate the same again in EAP. However when using RADIUS authentication, the RADIUS server certificate and FQDN must be validated in the EAP protocol as it is a different server

[webash]

I'm not sure I agree that that logic provides a remit to be able to ignore the server certificate at the EAP level. Certificates only work if people trust them. If they aren't trusted, and are ignored, then that's how bad things happen.

If you truly believe that ignoring a certificate name mismatch is valid advice, then the documentation should include this explanation for people to make their own decision as to whether they agree, rather than just suggesting something dangerous without an explanation.

However, I would strongly urge that the only advice given in this section is to provide the FQDN that should be matched, and help people determine what that FQDN should be. (since there is no warning in any interface in the Azure Portal, let alone this documentation, that helps you determine it)

[webash]

Whilst I appreciate that it is a holiday period across most of the globe, this bad advice is still present on the site. Can this be updated with a matter of urgency?

[anzaman]

What you are saying only makes sense when the VPN tunnel and EAP terminate on different servers. In this case both of them are terminating on the same server,, there is no benefit of validating the server identity twice.

[webash]

The general guidance of ignoring certificates should never be done. It undermines the certificate trust system. It shouldn't matter what assumptions can be made about the configuration of the remote endpoint; the whole point of certificates is that if one is being offered for the name you expect, you have some trust that those names have been validated out of band.

Your assumption about there being no benefit to validating the server identity twice only makes sense when it is known to the administrator/user that it is the same server. We can't possibly see that topology for an Azure Gateway. Additionally, there doesn't need to be a _benefit_ to validate a cert, but there is a _detriment_ to not validate the cert. Can you guarantee that there isn't a situation where ignoring the certificate would open the client device to MITM or some other kind of impersonation problem?

If the certificate is offering a different name, then that name should be targeted. All I'm asking is that you drop the guidance about ignoring the certificate, and provide more specificity on how to determine the FQDN that _is_ on the EAP server certificate.

Finally: if the VPN tunnel and EAP terminate on the same server, why do they present different certificates? Why not just have the EAP use the same certificate and avoid this problem entirely?

[anzaman]

I have added the clarification in the document. Thank you for your feedback. We appreciate your intent and applaud your desire to ensure the safest and most secure methods of certificate validation. We’ve discussed within our development team and feel certain that the correction stands as it would be a redundant check. Again, thank you for bringing this to our attention and please continue to let us know of any future issues you find. We value our customers’ advice and feedback.

[webash]

I still don't agree, but there's only so much time I can provide to this. The clarification at least leaves those who read it to ponder the choice.

I only wish you would provide more information on how to correctly determine the FQDN that is offered on the EAP server certificate since it is different to the external FQDN, but I can see I'm not winning here.