Forum Discussion
Admin Center choosing the wrong certificate
Windows Admin Center version 2410, build 2.4.2.1.
We're encountering an issue following the instructions outlined https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/configure/update-certificate?tabs=powershell when replacing the WAC certificate. We've installed a certificate from a third-party CA in the local machine store. The common name matches the DNS FQDN and hostname of the server. Despite specifying the thumbprint of the 3rd party CA cert with the "Set-WACCertificateSubjectName" cmdlet, WAC binds to a different certificate issued by our internal CA for WinRM. The WinRM cert shares the same common name, but it has a later expiration date. I suspect WAC is picking the certificate with the latest expiration date. This also happens when using the GUI, even when we specify the 3rd party cert during customization. We've confirmed that the NETWORK SERVICE account has rights to the private key on the cert as well.
I tried deleting the binding using netsh and rebinding to the updated thumbprint. While this is successful, and the output from "netsh http show sslcert" shows the 3rd party CA cert on the port 443 binding, the browser still presents the Internal-CA cert on 443 even after restarting the WinRM and Windows Admin Center services (and rebooting). It seems like there is an issue when multiple valid certificates exist with the same common name in the machine store. Additionally, the "Set-WACCertificateAcl" seems to fail in this case. The Configuration log contains the error below whenever it is run.
Set-WACCertificateAcl: Unable to find machine key path for certificate. Skipping setting access control list.
We'd prefer to use the 3rd party cert for the HTTPS port and the internal CA cert for WinRM. Is this possible?
1 Reply
We’ve seen something similar when WAC and WinRM share the same CN and there are several valid certs in LocalMachine\My.
According to the WAC certificate docs, the Set-WACCertificateSubjectName flow expects a unique subject; if multiple certs match, the tooling can end up binding a different one than the thumbprint you had in mind.
A pattern that worked for us was:- Issue a dedicated public cert for WAC with its own FQDN (for example, wac.contoso.com) and keep a separate internal-CA cert for WinRM with a different subject.
- Re-run the WAC config using the public cert’s thumbprint and confirm the HTTP.sys binding with netsh http show sslcert (check both 0.0.0.0:443 and any explicit IP bindings).
- Configure the WinRM HTTPS listener independently with the internal CA cert via winrm create / Set-WSManInstance, as in the WinRM over HTTPS guidance.
With that split, WAC presents the public cert on 443 for the browser, while WinRM continues to use the internal CA cert for management traffic.
