Https URL cannot be registered when enabling NAV Web Services

Two weeks ago, a Dynamics NAV partner in The Netherlands asked me whether I know how to solve the message “Https URL cannot be registered”.

This message is telling us that the NAV server is trying to register a port number on the system (in this case for OData web services), but that the same port number is already in use for a different protocol.

This seems to be logical, you cannot use the same port for encrypted and unencrypted communication. This is quite normal in networking.

By the way, Dynamics NAV is using the same port number for both HTTP and HTTPS. Other applications are normally using different ports for these protocol. Default ports for IIS is 80 for HTTP and 443 for HTTPS. And SMTP uses port 25 for unencrypted communication, but for encrypted communication port 465 or 587 is a standard port to be used.

Back to our problem.

The most logical solution for this would be to set the OData web service to use SSL. However, this was already done… In the next screen print you see the error message again together with the setting of the OData web service.

So now the question raises, why there is an error message telling us that there is already a registration existing for https on port 7048 and that it cannot register both http and https on the same port, while we have set the OData web service to use SSL? Obviously, the NAV administration tool is trying to register http on port 7048 instead of https.

The only reason for this is that the NAV administration tool is saving and activating each setting separately. First is determines that we want to enable OData services. At that time, the configuration file does not contain the SSL setting. When OData services is being activated, without SSL, it will try to register port 7048 for http. And that failed, because another NAV server is running on the system, using OData services with SSL.

To prove this, we can look at the PowerShell history of the NAV administration tool.

Here we can see what happened. The first line gets the actual setttings from the NAV server instance. After that we have set both Enable OData services and Enable SSL at the same time and clicked Save. That issued the next cmdlet, Set-NAVServerConfiguration for property ODataServicesEnabled. And this command fails, because the SSL setting wasn’t set yet.

So, what to do next? Stop or disable the other OData service first, and then retry? No, that wouldn’t work either. The registration of https happens together with setting the SSL Enabled property, so just stopping the other OData  service, or disabling it will not work.

What we need to do is to first set the SSL enabled property and save it. Then the https registration is done. After that, edit the settings again and enable OData services and saves it. This is the only order that works in this situation.

This story works for both OData and SOAP services. But I guess you already assumed that.

Warning: there are also sites that tells you to use the netsh http command. Be careful with that. You only need this if the server that occupied the URL is not existing anymore. That would only happen if the server wasn’t removed in a normal way. Otherwise, stick to the NAV administration tool and let it handle the URL registration for you.

Curious what this is all about? The NAV Server is in fact a self-hosted web service, instead of relying on IIS for http / https connections. I found a nice and short description about this topic here: http://www.flexecom.com/self-hosted-web-service-on-windows-server-2012/