/ Infrastructure

SCCM upstream and downstream SUPs fail SSL/TLS negotiation

I have two SCCM SUP systems, one is the top and the other is downstream. The SCCM infrastructure is operating in Native Mode and all WSUS synchronizations and configurations happen over HTTPS.

The internal SUP (SKN01) is the site server and has a site system in the DMZ (DMZ01) which it uses as a SUP for external IBCM clients. I had a look at the system status a couple of days ago only to see the SMS_WSUS_CONFIGURATION_MANAGER component had gone critical with this message all over the place:

SMS_WSUS_CONFIGURATION_MANAGER Message ID: 6600
WSUS Configuration Manager failed to configure upstream server settings on WSUS Server "Internal". 
Possible cause: WSUS Server version 3.0 SP1 and above is not installed or cannot be contacted. 
Solution: Verify that the WSUS Server version 3.0 SP1 or greater is installed. Verify that the IIS ports configured in SMS are same as those configured on the WSUS IIS website.

I looked at WCM.log to see exactly which server it is failing to configure. To reproduce the error I started and stopped the SMS_WSUS_CONFIGURATION_MANAGER component using theConfigMgr Service Manager tool.

WCM.log showed the initial connection to the primary SKN01 SUP as successful with a fairly odd .NET exception following:

System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> 
System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.~~ 
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)~~ 
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)~~ 
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)~~ at
...

Basically, this meant that whatever WSUS server the primary was attempting to connect to (it wasn't exactly specific…) was failing to negociate SSL and aborting. FYI, I used ProcMon to figure out which WSUS server it was connecting to during the failure. It turns out it was DMZ01

This was odd because WSUS synchronization and configuration had worked for a while and seemingly overnight the certificate became invalid? Not likely. I checked the machine certificates and their trust chain and it all seemed in order on both servers.

I remembered that recently I was troubleshooting an issue with the Management Point and I had removed the Intranet FQDN from the site system in the DMZ (the IBCM SUP server, DMZ01).

It turns out all I had to do was enter the Intranet FQDN in the DMZ site system’s properties (DMZ01) and all was well. If you’re still experiencing issues after entering the FQDN, remove the SUP from the DMZ site and re-add it.

Who knew that removing this FQDN would cause the WSUS configuration to fail. I guess the internal SUP uses the supplied internal FQDN by the DMZ site system to validate the web server certificate supplied by WSUS?

So yeah.. make sure you configure both the Intranet and Internet FQDNs in the DMZ site system's properties.