Admitted, my first technology blog title has the ring of a Sherlock Holmes case. The solution to the problem I’ll try to describe certainly didn’t present itself easily.
Introduction
Navision with SSL communication
When configuring Navision to use the secure SSL communication protocol, you need to provide a certificate. The procedure is described in TechNet, and I’ll also make another post about this specific setup.
The certificate proves to the client (webclient or full client application) who is setting up a communication channel with the server that he is really the server he claims to be.
Normally, the certificate contains a DNS name for the server, e.g. nav.axis0.be. As a client you’ll connect to the NAV server nav.axis0.be. The certificate exchanged will confirm this to your client. This will allow the protocol to exchange encryption key for the session and start encrypted communication.
DnsIdentity
In some cases, the certificate in the server can claim to be nav-a320.axis0.be while the URI you access is nav.axis0.be, which is in fact an alias in DNS.
In this case, it’s useful to specify in your client configuration that you know you’re connecting to an alias, but are in fact really expecting to connect to nav-a320.axis0.be
You can specify this in the DnsIdentity parameter in the ClientSettings.config file, while still using nav.axis0.be as friendly name to connect to the system.
The ClientSettings.config file will reason “yes, he’s trying to be fancy, as long as that server I’m speaking to tells me he’s nav-a320.axis0.be, I don’t mind the obscurity”
Subject Alternative Name
A certificate can also define a list of DNS names for which the certificate can be used.
This allows you to create (or buy) just a single certificate that is valid for a number of different DNS names. E.g. nav-a318.axis0.be, nav-a319.axis0.be, nav-a320.axis0.be, nav-a321.axis0.be
The same certificate can be imported in the different servers, which makes the management a little easier.
You’ll find this information in the details of the certificate under the “Subject Alternative Name” property.
Problem: Unexpected Remote Endpoint error
So far the theory.
Imagine having a server called nav-a320.axis0.be on which Navision is running, with a certificate that has the following Subject Alternative Name list:
– nav.axis0.be
– nav-a318.axis0.be
– nav-a319.axis0.be
– nav-a320.axis0.be
– nav-a321.axis0.be
When connecting to Navision from the RoleTailored client, the following elaborate message pops up:
“The client could not create a connection to the Microsoft Dynamics NAV Server. Reason = “Configuration Setting ‘DnsIdentity’ has an invalid value” Description = “Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was ‘nav-a320.axis0.be‘ but the remote endpoint provided DNS claim ‘nav-a321.axis0.be‘. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity ‘nav-a321.axis0.be‘ as the Identity property of EndpointAddress when creating channel proxy.”
However, we did provide the Thumbprint of the certificate, and specified in DnsIdentity “nav-a320.axis0.be”
Why would the server (called nav-a320.axis0.be) present itself as nav-a321.axis0.be?
The answer is: “the order of the SAN”.
Due to a bug (or let’s call it new behaviour since .Net 4.6.1) the last DNS name in the list is picked by the framework to identify the server with, in our case: nav-a321.axis0.be, which is not very convenient.
Workarounds
Forced setup (mis)using DnsIdentity
You can configure DnsIdentity to say “nav-a321.axis0.be”, so both the name returned by the server and the client’s expectations of this name are met, but it’s not really straightforward. It will work as a “hardcoded” solution.
However, it bypasses the purpose of having multiple Subject Alternative Names in the list. Yes, you can use the same certificate on multiple servers, as it will always claim it’s the last one in the list.
But, when the time comes to renew the certificate, you might receive a brand new one, in which the order of the SAN has changed, and there is another server last in the list.
This means that you have to update the ClientUser.config file on every end-user’s PC with the new DnsIdentity value the server ‘thinks’ it is.
Rollback .Net behaviour
For NAV 2018, a workaround in the configuration exists. This allows to roll-back the new .Net behaviour by specifying the following switches in C:\Program Files\Microsoft Dynamics NAV\100\Service\Microsoft.Dynamics.Nav.Server.exe.config
Final solution
Microsoft has accepted this as a bug, and is evaluating a hotfix to remove this undesired behaviour.
Read More
In case you’re interested in Navision setup, also read my article on configuring Navision with an Azure SQL DB or how to track user session using PowerBI