DSC Pull server unable to register Windows 10 (1709) Client

Issue:
Unable to register DSC windows 10 (version 1709) client with pull server.

Background: Below is a detailed list of the environment/configuration that was implemented and working correctly to register the windows 10 client node (version: 1511) before updating the client to version 1709. The pull server and its certificate has been recreated using the below configurations to keep the configurations as simple as possible to prove the issue.

Pull Server system details:

OS: Windows Server 2012 R2

WinVer: Version 6.3 (Build 9600)

PSVersion: 5.1.14409.1012

xPSDesiredStateConfiguration: 7.0.0.0

Pull Server configuration:

The pull server was configured using the microsoft sample script located here under page title: “Setting up a web pull server” (copied below for convenience)

<pre>configuration Sample_xDscPullServer
{ 
param  
( 
        [string[]]$NodeName = $Env:computername
 ) 

 Import-DSCResource -ModuleName xPSDesiredStateConfiguration
 Import-DSCResource –ModuleName PSDesiredStateConfiguration

 Node $NodeName 
 { 
     WindowsFeature DSCServiceFeature 
     { 
         Ensure = 'Present'
         Name   = 'DSC-Service'             
     } 

     xDscWebService PSDSCPullServer 
     { 
         Ensure                   = 'Present' 
         EndpointName             = 'PSDSCPullServer' 
         Port                     = 8080 
         PhysicalPath             = "$env:SystemDrive\inetpub\PSDSCPullServer" 
         CertificateThumbPrint    = {My CertificateThumbPrint}         
         ModulePath               = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules" 
         ConfigurationPath        = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration" 
         State                    = 'Started'
         DependsOn                = '[WindowsFeature]DSCServiceFeature'     
         UseSecurityBestPractices = $false
     } 

    File RegistrationKeyFile
    {
        Ensure          = 'Present'
        Type            = 'File'
        DestinationPath = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
        Contents        = {Generated GUID using powershell new-Guid}
    }
}
}</pre>

Pull Server Certificate Information:

The pull server has a self-signed certificate installed (which I suspect the problem is with new certificate regulations implemented in the 1709 update) using this Microsoft script titled: “New-SelfSignedCertificateEx.ps1”

The certificate was created with the below code from “Securing the Mof” and above function from Microsoft:

  <pre>   New-SelfsignedCertificateEx &#8175;
    -Subject "CN=${ENV:ComputerName}" &#8175;
    -EKU 'Document Encryption' &#8175;
    -KeyUsage 'KeyEncipherment, DataEncipherment' &#8175;
    -SAN ${ENV:ComputerName} &#8175;
    -FriendlyName 'DSC Credential Encryption certificate' &#8175;
    -Exportable &#8175;
    -StoreLocation 'LocalMachine' &#8175;
    -KeyLength 2048 &#8175;
    -ProviderName 'Microsoft Enhanced Cryptographic Provider v1.0' &#8175;
    -AlgorithmName 'RSA' &#8175;
    -SignatureAlgorithm 'SHA256'
   # Locate the newly created certificate
   $Cert = Get-ChildItem -Path cert:\LocalMachine\My &#8175;
    | Where-Object {
        ($_.FriendlyName -eq 'DSC Credential Encryption certificate') &#8175;
        -and ($_.Subject -eq "CN=${ENV:ComputerName}")
    } | Select-Object -First 1</pre>

Pull Client System Details (Working LCM registration)

OS: Windows 10 Pro

WinVer: Version 1511 (Build 10586.63)

PSVersion: 5.0.10586.63

xPSDesiredStateConfiguration: 7.0.0.0

Pull Client LCM Configuration:

Simple configuration found from: “Setting up a pull client using configuration names”

<pre>[DSCLocalConfigurationManager()]
configuration PullClientConfigNames
{
    Node $Target
    {
        Settings
        {
            RefreshMode = 'Pull'
            RefreshFrequencyMins = 30
            RebootNodeIfNeeded = $true
        }
        ConfigurationRepositoryWeb CONTOSO-PullSrv
        {
            ServerURL = "https://${env:computername}:8080/PSDSCPullServer.svc"
            RegistrationKey = {Correct registration key from pull server}
            ConfigurationNames = @($Target)
        }
    }
}
PullClientConfigNames</pre>

Now before I updated the pull client to windows 10 version 1709 all of the above code worked and the client was able to register with the pull server. However after applying the windows update the client no longer registers with the pull server.

Pull Client System Details after update

OS: Windows 10 Pro

WinVer: Version 1709 (Build 16299.19)

PSVersion: 5.1.16299.19

xPSDesiredStateConfiguration: 7.0.0.0

Pull Client Errors (Event Viewer)

(Microsoft-Windows-Desired State Configuration/Operational) during attempted pull server registration.

  Job {7BD76187-B9A2-11E7-8ACF-080027D18DCF} : 
    Http Client A3B5331D-B51C-11E7-8ACE-080027D18DCF failed to register Dsc Agent: 
    + FullyQualifiedErrorId : RegisterDscAgentCommandFailed
    + CategoryInfo : InvalidResult: (:) [], InvalidOperationException
    + ExceptionMessage : Failed to register Dsc Agent with AgentId A3B5331D-B51C-11E7-8ACE-080027D18DCF with the server https://dsc-ws1264-co02:8080/PSDSCPullServer.svc/Nodes(AgentId='A3B5331D-B51C-11E7-8ACE-080027D18DCF').
    + InnerException : System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> 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.TlsStream.EndWrite(IAsyncResult asyncResult)
    at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
    --- End of inner exception stack trace ---
    at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
    at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
     --- End of inner exception stack trace ---
     --- End of inner exception stack trace ---
     at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
     at Microsoft.PowerShell.DesiredStateConfiguration.Commands.RegisterDscAgentCommand.IssueRequest(DotNetHttpClient client, String subLink, ErrorRecord& errorRecord)
     ---> (Inner Exception #0) System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> 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.TlsStream.EndWrite(IAsyncResult asyncResult)
     at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
     --- End of inner exception stack trace ---
     at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
     at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
     --- End of inner exception stack trace ---<---

Final Notes:
It appears that after updating the pull client Microsoft has changed what is considered a valid certificate. Notice the following line from stack trace from the client:

<pre>The remote certificate is invalid according to the validation procedure</pre>

Has Microsoft stopped supporting self-signed certificates for the pull server? Maybe there is a new group policy setting that allows the new windows version (1709) to accept a self-signed certificates. Either way my resource have been exhausted. This issue is easy to recreate using the above configurations on the mentions OS/Versions. Any insight on how to further debug/fix this issue would be greatly appreciated.

The error indicates that the client does not trust the CA that issued the pull server’s SSL certificate, as your Final Notes suggest.

MS never “supported” self-signed certificates for pull server. By definition, only the machine creating a self-signed cert trusts that cert. The easy (and correct) fix would be to obtain a proper SSL certificate.

I’ll go a bit further and mention that if the goal is to use self-signed certs for SSL, you might as well just use HTTP and not HTTPS. Self-signed SSL connections are trivially easy to compromise in various attacks, especially Man-in-the-Middle and such. The point of a certificate is not encryption per se; it is to identify the party on the other end of the call. If “identification” is just taking the person’s word for it, then you don’t actually know who you’re talking to, so it doesn’t really matter if the call is private or not. Self-signed certs are “okay” for test environments, but that’s it. And they’re even just barely okay then.

I could stand up a pull server on your network, use a self-signed certs, diddle with DNS, and your nodes would take whatever nasty config I fed them. On the other hand, if you’re using real SSL certs and not trusting self-signed certs, I’d have a heck of a harder time. If I used a real SSL ceert in that kind of attack, you’d have an easy time identifying me.

Thank you for your quick reply. I was aware of the variability with self-signed certificates however I thought it curious as to why my test environment could no longer run once the client was updated to the latest version of windows. I would not use self-signed certificates for a production environment but would still like a fake (ssl with self-signed cert) secure pull server for my test environment. Do you know if this is still possible with the latest version of windows?
I’ve have installed the self-signed cert as a Trusted Root CA on the client node. However the client still will not trusted my self-signed certificate.
Is there some setting I can use to bypass this security temporally?

I’m a little uncomfortable bypassing security ;). Experian is fresh in my mind, still. Self-signed certs shouldn’t be used for SSL, full stop. I’m glad MS has closed this, because despite folks knowing it’s a bad idea, it’s still been prevalent.

Thank you for the insight. I will switch back to a http pull server in my test environment.