I think that everyone of you know that the AL HttpClient data type provides a data type for sending HTTP requests and receiving HTTP responses from a resource identified by a URI.
A very basic piece of AL code that sends a GET request to an endpoint and return a response can be defined as follows:
procedure GetResponseFromUrl(URL: Text): Text
var
HttpClient: HttpClient;
HttpResponseMessage: HttpResponseMessage;
Response: Text;
begin
HttpClient.Get(URL, HttpResponseMessage);
HttpResponseMessage.Content.ReadAs(Response);
Exit(Response);
end;The AL HttpClient object relies on the standard .NET HttpClient data type.
When you’re using the HttpClient object in C# over https, a certificate validation is usually performed (unless you disable or change it).
But what happens in Dynamics 365 Business Central?
If you try to connect with the above AL code via HTTPS to a remote site where a certificate is expired or invalid (to test that you can use the public endpoints provided by the BadSSL.com website, for example https://untrusted-root.badssl.com/), with Dynamics 365 Business Central on-premise you will have an error like the following:
The SSL connection could not be established, see inner exception.
The remote certificate is invalid because…
With Dynamics 365 Business Central online, you will have the following:
No errors! The remote url is successfully called by the HttpClient object, without any warnings related to the certificate validation, and the content of the destination page (or the result of the remote call) is returned to the client without problems.
It seems that at the moment Dynamics 365 Business Central online is not doing validation for remote certificates.
Microsoft seems to have accepted the issue reported and probably the HttpClient behavior will change with Business Central version 25.x.
Please remember that in the future a full remote certificate validation check could break some of your existing connections if your third-party endpoint will not have a valid SSL certificate in place (what works today will be an error in v25.x).
The performance considerations of this new future setting could cause additional delay when establishing the connection with the remote endpoint (remember that if you call an external web service using the HttpClient module in AL, the Business Central Server blocks the execution of AL code for the session until the call completes. ), but for sure the new behavior will be more secure.
Stefano Demiliani 
Hello Stefano,
I’m reaching out because I’m experiencing a similar situation but with different behavior.
From Business Central Online, I need to consume a web service from an external application provided by another vendor.
The public URL looks like this: https://ext.domain.fr:xxxx/application/Service.svc/Login
But the traffic is then redirected to port 443 of a local server on our client’s network with an address like this: https://hostname/application/Service.svc/Login
The service provider managing the infrastructure has confirmed that there is no IP address filtering.
The server is certified by a local certification authority, not by an SSL certificate signed by a recognized authority.
Locally, when I try from Postman, it works, even though I get an alert saying “Unable to verify the first certificate.”
It also works in Python using the Requests library by ignoring SSL certificate verification (verify=False).
It works in PowerShell as well when using the TrustAllCertsPolicy class.
However, when I try from Business Central in a Docker container, I get the message you mentioned:
“The SSL connection could not be established, see inner exception. The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch, RemoteCertificateChainErrors”
But when I try from a Business Central Online sandbox, I get another message:
“A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.”
I get the same message when trying from Power Automate with an instant cloud flow and the HTTP connector.
So there’s an issue when I try to reach this web service from the Microsoft cloud, but I don’t know what it is.
Do you have any ideas?
Thank you so much.
LikeLike
Exactly. The SSL validation is active on Docker and on BC on-prem, but not on SaaS (this is the reason why on Docker you have an SSL error, on SaaS just a connction error). The connection error seems that the service you’re calling is unable to reach the other url. Maybe somethin g in the redirection? From SaaS you cannot reach a local url…
LikeLike
Thanks for your answer Stefano.
Finally, after several investigations between the IT service provider and the internet provider (Orange),
There is indeed a routing problem between an Azure context whatever it is (BC, Power Automate, Azure VM) and the API.
Sorry for the inconvenience.
LikeLike