User Profile
chapbak
Copper Contributor
Joined Nov 21, 2022
User Widgets
Recent Discussions
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?Solved249Views0likes1CommentIIS Static Compression caching truncated files
OS: Windows Server 2016 IIS: 10.0.14393.0 We serve a 1.5MB CSS file from our main website. With static compression enabled, it delivers a ~220kb file to the client from the IIS compression cache. However, we've now had several instances where the cached version of the file is truncated. Since it is the main CSS for the page, the layout is distorted, and the site becomes unusable. I was able to partially reproduce the issue by forcing a slow upload over FTP. Since the FTP server doesn't lock the file during upload, IIS serves a partial file if it reaches the cache threshold (the default 2 loads in 10 seconds in our case), during the copy. This is expected - IIS doesn't know the file upload is in progress, and it isn't locked, so it serves the partial file. However, it seems that periodically, IIS doesn't notice that the cached version differs from the source file, and it continues to serve the truncated file from the compression cache after the file is fully uploaded. I haven't been able to reproduce the conditions that cause this specifically - during testing, IIS detects the difference and re-caches the compressed version of the full file. But a partial file has been left in the cache multiple times on our production servers within the last 2-3 months. For now, we're fixing this my automating deletion of the cached copy when it is detected as being too small, but we'd be interested in a more permanent fix. Our process has not changed recently - no new software installed on the web servers other than Windows updates. Has anyone else encountered this?1.3KViews0likes2Comments
Recent Blog Articles
No content to show