OS Name/Version: Windows Server 2022 21H2 + Windows Server 2016 Datacenter + Ubuntu 20.04
Product Name/Version: AMP Release “Callisto” v2.5.0.10, built 19/05/2024 18:30
Problem Description:
Invalid SSL certificate on server “198.244.186.210:443” cause problems on secured servers, because well secured servers do not allow to download / connect to server with invalid SSL certificate.
HttpRequestException
[0] (HttpRequestException) : An error occurred while sending the request.
at ModuleShared.VersionManifest.<FetchAsync>()
WebException
[1] (WebException) : Unable to connect to the remote server
at Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
SocketException
[2] (SocketException) : 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 198.244.186.210:443
at Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult) at Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult) at Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
Failure to evaluate list source for setting: ADSModule.ADS.DownloadMirror
Couldn't create a delegate for ADSModule.ADSConfig+ADSSettings.MirrorSources - Object reference not set to an instance of an object.
Steps to reproduce:
Install Windows Server 2022
Apply GPO security baselines from Security Compliance Toolkit
Try to deploy any instance
Actions taken to resolve so far:
This problem can be “fixed” by allowing server to connect to host without valid SSL certificate, but it is really not thing what anyone would want to have set on server
The CC site uses a wildcard cert. This isn’t an uncommon method. Your baseline GPO is being too strict really. Disable that portion if you want to connect.
This looks like you’re trying to browse to an IP in the browser rather than a domain name, which isn’t going to work. CubeCoders sites can only be accessed by name.
It is not about the browser screenshot. The screen shot is just for reference. The problem is that the AMP itself trying to connect to 198.244.186.210:443 directly by IP under the hood instead of using hostname. Windows security layer refuse the connection from AMP so the AMP itself has to access to the hostname wrong.
AMP itself uses the hostname, what you’re seeing is a lower-level connection failure.
This isn’t a certificate issue, the problem is that AMP is timing out talking to the server (which happens to be at that IP) - the hostname isn’t logged because it’s at a lower level.
What you might find is that NETWORK SERVICE is being blocked from making outgoing connections. So you should indeed revisit your GPO.
The wildcard is not a problem. Windows does not refuse the connection because of the wildcard. Windows refuse the connection because AMP itself makes the connection directly to IP or to hostname what is not part of SAN. The connection goes directly from AMP so the AMP build the connection wrong way.
Strict GPO? This is basic security rule. Client can risk wrong SSL but server should never connect to anything with invalid certificate.
Those aren’t intended to be put in across the board. The MS toolkit is just for comparison, testing, and best practices. They aren’t 100% going to work out of the box for everything. AMP is using .NET’s standard connection process. Nothing we control. You need to adjust the GPO.
All network connections are made to an IP address. The hostname is part of the request after it has been resolved.
AMP isn’t even getting that far, something is preventing it from talking to the server in the first place. This has nothing to do with the certificate, nothing to do with the host name, domain or anything else. AMP can’t talk to the server.
The certificate is valid - what you did was take the resolved IP and put it into a browser and incorrectly assumed that is what AMP is doing. The connection is timing out according to the logs. Nothing to do with the certificate.
What you’ve got to check is whether or not something is preventing AMP from making network connections entirely.
SSL or Certificate errors result in a TrustFailure exception which is something different entirely.