ArcherPoint Dynamics NAV Business Central Developer Digest - vol 346
This edition of Developer Digest digs deep into one major challenge with SSL Certificates and configuring a service tier in Dynamics 365 Business Central.
The Dynamics NAV and Business Central community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV/BC experts and devotees around the world. We hope these insights will benefit you, too.
A Plea for Help with SSL Certificates
Kyle makes a plea for help with SSL certificates: “I am trying to configure a BC16 on premises service tier to allow ODATA4 connections from the outside world, except I can’t even get SSL to work on the internal network with ODATA. The same certificate works with the web client, but that terminates in IIS rather than directly on the service tier. Further, the service tier won’t tell me what’s wrong: no event log entries, no way to turn on some sort of logging. All I get is a Connection Reset error when I attempt to connect. Connections work fine internally if I turn off SSL, so I know this is certificate related. I just have no idea how to troubleshoot, because it won’t tell me what the problem is. Any suggestions are helpful!
Tom responds: “It might be an issue with the port not being open on the firewall or the incorrect port being used.”
Kyle adds: “Since the error I get is a connection reset, that means it was actively rejected. I can also telnet to that port and it connects.”
Eugene offers: “Hey Kyle, let’s to do a little troubleshooting first before we dig deeper. At the command prompt, type the following command to view the current port configurations:
netsh http show sslcert
All port bindings to SSL certificates are listed. Each entry is indicated by the IP:port field, where IP is the IP address that uses the port (0.0.0.0 indicates all IP addresses) and port is the port number.
If SSL is already configured on the address and port that you want to use for OData web services, then use the following command to delete the entry:
netsh http delete ssl ipport=ipaddress:port
Substitute ipaddress and port with the IP address and port number of the entry that you want to delete. For example, netsh http delete ssl ipport=0.0.0.0:7047
Rebind an SSL certificate OData web service port; use the following command:
netsh http add sslcert ipport=ipaddress:port certhash=thumbprint appid={id}
The hash is the certificate thumbprint that you obtained.
The id is a 32-digit hexadecimal number that identifies the Microsoft Dynamics NAV application. The id must be in the format {NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN). If you do not know the appid, then use any value, such as {00112233-4455-6677-8899-AABBCCDDEEFF}.
Restart the NAV Server Instance and try again.”
Suresh provides more information for an older version: “Kyle, we had similar type of issue for another client, but they are on 2013R2. Below are my notes related to that:
The same TLS error happens on local browser, and there is no FW or AV that would block any particular ports.
It is somewhat port related, however. Checking the server settings, it appears the HH cert used was not bound to any ports except 443 and 9047 (working NAV instance). Because these NAV instances run their own web server and not IIS, you must link it from the command line rather than IIS GUI. See the Microsoft documentation on configuring web services to use SSL (SOAP and OData) that might be relevant to this and other NAV Web configurations.
netsh http add sslcert ipport=0.0.0.0:9047 certhash=25f77516289627f461dc2c25080a0e8ef4a485f6 appid={4dc3e181-e14b-4a21-b022-59fc669b0914}
netsh http add sslcert ipport=0.0.0.0:9048 certhash=25f77516289627f461dc2c25080a0e8ef4a485f6 appid={4dc3e181-e14b-4a21-b022-59fc669b0914}
netsh http add urlacl url=https://+:7147/ sddl=D:(A;;GX;;;NS)(A;;GX;;;BA)
netsh http add urlacl url=https://+:7147/NAVDEVWS/ user=HOLLYHUNTnavsql_svcacc
netsh http add sslcert ipport=0.0.0.0:7147 certhash=25f77516289627f461dc2c25080a0e8ef4a485f6 appid={4dc3e181-e14b-4a21-b022-59fc669b0914
Kyle concludes: “I figured out the problem, which spawned this tip on how to go about troubleshooting:
Developer Tip of the Day: How to configure SOAP, OData, or API to use SSL (and some troubleshooting)
- Create a new dedicated service tier with no web client access (or you can have that on, but it isn’t required)
- Make it work without SSL
- Default client Odata
- Windows authentication
- Enable API Services no
- Enable OData Services yes
- Enable SSL no
- Enable V3 Endpoint no
- Enable V4 Endpoint yes
- Port 7148
- OData Base URL
- Restart service tier
- elevated command prompt
- netsh http show urlacl
- remove anything bound to port 7148
- netsh http delete urlacl https:/
- Reboot
- Disable forced https in Microsoft Edge
- chrome://net-internals/#hsts
- Delete domain security policies
- Localhost
- Server
- server.domain.com
- telnet test on the server itself
- telnet localhost 7148 and make sure it answers
- Edge http://server.domain.com:7148/EDITest/ODataV4
It should return a large json document with all of the offered OData version 4 web services, per this document on Using Security Certificates with Business Central On-Premises.
- Get certificate generated
NOTE: You must have both Server Authentication and Client Authentication as certificate purposes
- Grant full permissions to private key to the BCST service account in the Certificate admin tool
- Replace the urlacl
- netsh http show urlacl
- Reserved URL : http://+:7148/EDITest/
- netsh http delete urlacl http://+:7148/EDITest/
- netsh http add urlacl url=https://+:7148/EDITest/ user=DOMAINbcst_service_account
Get the relevant certificate information—thumbprint and common name (CN) from PowerShell:
- Get-ChildItem -Path Cert:LocalMachineMy
- BCST Service Tier – set these things
- Certificate Thumbprint from PowerShell above
- Do not copy/paste from the Certificate admin tool
- Enable OData Services yes
- Enable SSL yes
- Enable V3 Endpoint no
- Enable V4 Endpoint yes
- Port 7148
- OData Base URL https://server:7148/EDITest/OData/
- Reboot
- telnet test on the server itself
- telnet localhost 7148 and make sure it answers
- Microsoft Edge on local network https://server.domain.com:7148/EDITest/ODataV4
It should return a large json document with all the offered OData version 4 web services.
In BC, Web Services:
- Find Page 16, Chart of Accounts
- Click on OData V4 URL to test (this only tests inside the firewall)
Troubleshooting
ERR_SSL_PROTOCOL_ERROR
- export certificate to x.509 base64 cer file without private keys
- open with notepad
- copypaste to https://certificatedecoder.dev/
- decode
- subjectAltName dNSName server.domain.com www.server.domaincom
- keyUsage digitalSignature keyEncipherment
- extKeyUsage serverAuth clientAuth
HTTPS handshake to server.domain.com (for #50) failed. System.IO.IOException The handshake failed due to an unexpected packet format.
Only TLS 1.2 or newer is supported as of BC15
BCST config file: SecurityProtocol
Configuring Web Services to use SOAP (SSL and OData)
Force TLS1.2 in the BCST configuration file
That made it work.
To make it work externally, use public DNS A record that matches the certificate FQDN.
We hope this saves you from a headache!
If you are interested in Dynamics NAV and Business Central development, be sure to see our collection of NAV/BC Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.