Hello, We are renewing the certificates on the DDC's using a new Root CA (internal use). There is no Netscaler involved. The error i'm getting in the eventlog: “An SSL connection could not be established: You have not chosen to trust the issuer of the server's security certificate, Root CA. This message was reported from the Citrix XML Service at address https://serveradress/scripts/wpnbr.dll. The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services.” And i have no desktops showing up in storefront. (yes, i've have asked this question earlier trough discord, but that getting messy)

Root cert is trusted by your SF? the full chain?

yes, it's trusted full chain

It has to be around the root CA. If it's on the correct store, and you proved SF trust this new CA. It could be around the algo. Not sure here.

I'm on 2203 CU4 btw

Thanks, unfortunately that does not fix the problem

I'm 95% sure that ECDSA isn't supported for xml traffic. I'll see if I can get something on email back, but that communication was on a mailbox of a previous company. Got that answer after months of back and forward with Citrix and lab reproductions etc.

What does netsh http show sslcert show on your DDC's ?

I'm getting the following error: You have not chosen to trust "Certificate Authority", the issuer to the server's security certificate."

Did you propogate the new root certificates to all machines in the domain? And reset the signature on the broker service to the new one from the cert.

Yes. As my SF and DDC are on the same server I only need to configure it in IIS. (i also tried the other way, same result)

yeah it's bascially garanteed that if you use a nonECDSA that it will work like a charm

That only adds the cert, you still need to tag the brokerservice. And get the domain root certs in Trusted roots.

@Jeff Riechers same results

yeah trying to find something, but it was a project for an airgapped high secure client through a previous consulting firm that I no longer work for. Otherwise I would have it for you in minutes, seeing if I can find any trace of it

I'm confused about your SF print screen to show if cert is valid. From your SF, if you do https://ControllerControllerFQDN you should get a 404 and loaded. Right?

yes, but it's only encrypted xml traffic that doesn't work with this cert, he's showing that he's not getting any apps/desktop data because the xml service can't get them

Ok. Did you bind it via IIS or netsh?

Did both @jvitech it’s weird that Citrix uses its own ssl broker instead of windows. That would have fixed the issue probably

It's more IIS is not needed for the Controller so you need netsh to bind it. I couldn't find anything about this issue on Internet. If it was a bug about sha384, it would be surprising you are the first. If you switch back the cert (assuming you can) does it work? Also your new cert hold the same usage than previous? Server authentication is all you need.

Well, looks like I’m not the first, @Lucas Van den Broeck has had the same issue. Switching back does work. No problem with the old certificate. Same key usage.

it's not sha384, it's ECDSA that is the actual issue. When I logged it (about 5 years ago) they had never heard of it (but I'm pretty sure everyone gets that in every case they log, so ...) But I just remember it took months for Citrix to reproduce it inhouse (airgapped customer so no remote sessions) and they came back with the statement that indeed it did not work and they had no plans to support it at that time

Good to know for ECDSA! You create a new root CA just for this cert and shut it down :)

Looks like that’s the only thing that solves the problem 😅