Unable to connect with PSDDeployroots due to SSL issue

[keeper05]

I am unable to get past the step of validating access to the deploy root. The message I see is:

unable to Retrieve directory listing of https://mypsdserver/psdproduction/control via WebDAV. Error message: Exception calling "GetResponse" with "0" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure connection.

I have generated the certificate with the ps1 script, both rootca and server cert. Also used my incommon access and installed those certs. Same message. The certs work because I can navigate to the deploy root and look at the virtual directory.

[keeper05]

All the settings in WebDAV and IIS were configured by the script and I double-checked manually, as well.

[3pichaxz0r]

if you are confident the cert is not at fault here then I'd check the device you are using to run a test deployment. Make sure the BIOS has the correct date and time set or the certificate check will throw the error you mention

[keeper05]

Tried on another machine and got the same result.

Originally I used the supplied scripts to generate the Root CA and the server cert. Put the root CA in the psdresources folder and the server cert was automatically selected as a binding to 443 in IIS. Then I used my employers service to create a csr and received the server cert back from inCommon and also downloaded our Root CA (from Sectigo) and added that root CA cert to the PSDResources folder and changed the bindings in IIS to the new inCommon server cert. Cert is valid as I can navigate to the virtual directory and browse it. See attached that shows a lock indicating the cert is in working order.

[image: image.png]

On Thu, Nov 16, 2023 at 7:58 AM Dark_Web_Dennis @.***> wrote:

if you are confident the cert is not at fault here then I'd check the device you are using to run a test deployment. Make sure the BIOS has the correct date and time set or the certificate check will throw the error you mention

— Reply to this email directly, view it on GitHub https://github.com/FriendsOfMDT/PSD/issues/108#issuecomment-1814485672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABC4TYPC2AB4S5YIYTBLNPDYEYLYTAVCNFSM6AAAAAA7NC3YXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUGQ4DKNRXGI . You are receiving this because you authored the thread.Message ID: @.***>

[keeper05]

[GeoSimos]

Tried on another machine and got the same result. Originally I used the supplied scripts to generate the Root CA and the server cert. Put the root CA in the psdresources folder and the server cert was automatically selected as a binding to 443 in IIS. Then I used my employers service to create a csr and received the server cert back from inCommon and also downloaded our Root CA (from Sectigo) and added that root CA cert to the PSDResources folder and changed the bindings in IIS to the new inCommon server cert. Cert is valid as I can navigate to the virtual directory and browse it. See attached that shows a lock indicating the cert is in working order. [image: image.png] … On Thu, Nov 16, 2023 at 7:58 AM Dark_Web_Dennis @.> wrote: if you are confident the cert is not at fault here then I'd check the device you are using to run a test deployment. Make sure the BIOS has the correct date and time set or the certificate check will throw the error you mention — Reply to this email directly, view it on GitHub <#108 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABC4TYPC2AB4S5YIYTBLNPDYEYLYTAVCNFSM6AAAAAA7NC3YXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUGQ4DKNRXGI . You are receiving this because you authored the thread.Message ID: @.>

The WinPE boot image must trust the certificate that is bound on your IIS. For every such change, you have to include the RootCA certificate and possibly any intermediate CA that may have been used to create the certificate of IIS. The WinPE boot image must be rebuilt and tested for proper connections and operation. Please check the documentation here https://github.com/FriendsOfMDT/PSD/blob/master/Documentation/PowerShell%20Deployment%20-%20IIS%20Configuration%20Guide.md#https-and-certificates.

[keeper05]

Thanks for the response Geo. I did consult that documentation and rebuilt the image in deployment workbench and replaced in my WDS setup after every change. I have not added an intermediate CA, so I will do that next. Thanks

[GeoSimos]

Thanks for the response Geo. I did consult that documentation and rebuilt the image in deployment workbench and replaced in my WDS setup after every change. I have not added an intermediate CA, so I will do that next. Thanks

You need to have the whole chain of trust for a certificate to be trusted. If you check the certificate you will see it in the rightmost tab. All the certs before it must be included in the WinPE boot image.

[GeoSimos]

@keeper05 any news?

[keeper05]

I am still unable to get the certs working despite my best efforts. On Jan 16, 2024, at 16:38, George Simos @.***> wrote: @keeper05 any news?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[trongtinh1212]

i have this issue to when using with our company domain, in my lab is just fine

[LOldfield]

i have this issue to when using with our company domain, in my lab is just fine

Likewise, was running fine with self-signed certs, and still does run fine inside of WinPE, but as soon as it boots into Windows and tries to install applications I get: "The remote certificate is invalid according to the validation procedure" in the PSDApplications Log.

[technerdist]

I too am having an issue with this. I have all certs in place, logging in with a user who has permissions to the deployment share.

[jengstrom440]

I am also getting a "Error message: Exception calling "GetResponse" with "0" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure connection." error. I have our company Enterprise Root CA as well as a issuing CA, so I don't want to stand up another root CA just to do that. On the IIS server, I went into certlm.msc and requested a certificate from the issuing CA to be put in the personal store from the webserver template, added it's fqdn name and edited the bindings in the default web site where the virtual directory is. Checked the virtual directory url with https in edge and came back as valid/ secure connection. Exported that cert without private key and placed it in the %Deploymentroot%\PSDResources\Certificates\PSDCert.cer" path.

Not sure what is going on here? It would be nice if the PowerShell certificate script could have it so you can use your existing enterprise CA structure instead of standing up a "rouge" one :)

Otherwise, I am excited for this project. Thank you to everyone that is working on this; you are doing God's work here.

[LOldfield]

For me, this turned out to be an issue where I was leaving too much content in the deployroot, and it was preventing PSD from downloading the certs when in booted into PE. I fixed it by using the build in PSD functions to download required content after booting into Windows proper. Have you added anything to the deployment recently?

[jengstrom440]

For me, this turned out to be an issue where I was leaving too much content in the deployroot, and it was preventing PSD from downloading the certs when in booted into PE. I fixed it by using the build in PSD functions to download required content after booting into Windows proper. Have you added anything to the deployment recently?

This was a new deployment share for testing, so I can't imagine I had too much content on the deployroot. Some old drivers and 1 win10 wim file; that shouldn't be too wild one would think. I did get it working using the supplied RootCA setup script, and it appears to work fine. It doesn't seem to like my old 2016 server that I am going to be decommissioning soon for some of the IIS scripts. I have to do some work to get PSD to kick off some Ansible Jobs in the task sequences via ssh or REST and after my testing I have to rebuild the production environment.