Windows Web Services communication failure saying 503 Service Unavailable

Malzaar 60 Reputation points
2026-09-25T23:36:56.14+00:00

Our microservices hosted on IIS/Windows Servers are failing to communicate with each other, returning 503 Service Unavailable errors. This appears to be caused by an expired Windows Root/Intermediate CA certificate breaking the HTTPS/mTLS mutual authentication between the servers.

__I__nter-service communication between Windows endpoints is down, causing application downtime and blocking API requests across our servers.

Could you help us check the expiration status of the IIS/Active Directory Certificate Services (AD CS) certificates on the affected Windows Servers?

What is the standard procedure to force a certificate renewal or push updated CA certificates via Windows Group Policy (GPO)? and what steps should we follow to restore secure service-to-service communication on Windows without requiring a full server reboot?

Windows for business | Windows Server | Directory services | Certificates and public key infrastructure (PKI)
0 comments No comments

Answer accepted by question author
Jason Nguyen Tran 27,210 Reputation points Independent Advisor
2026-09-26T01:11:51.74+00:00

Hi Malzaar,

Based on your description, an expired root, intermediate, or service certificate is a very plausible cause of the 503 errors, especially if your applications rely on HTTPS and mutual TLS authentication between servers. The first step is to verify the certificate chains on the affected servers by reviewing the certificates in the Local Computer certificate store and checking the expiration dates of the server, intermediate, and root CA certificates. You should also review the System, Application, and Schannel event logs, as TLS trust failures are often recorded there and can help pinpoint the exact certificate that is failing validation.

For AD CS-issued certificates, you can force certificate renewal through the Certificate MMC snap-in or by triggering enrollment against Active Directory Certificate Services. If updated root or intermediate CA certificates need to be distributed, Group Policy is usually the preferred approach. After updating the certificate stores, run a Group Policy refresh and verify that the new CA chain is visible on the affected servers before testing application connectivity.

To restore communication without a full reboot, restart the affected application pools, IIS services, or application services that maintain TLS sessions and certificate caches. In many cases, services must be restarted before they begin using newly issued certificates or updated trust chains. I also recommend validating the TLS handshake from both sides of the connection to confirm that the correct certificate chain is being presented and trusted.

As a best practice, implement certificate expiration monitoring and alerts well before certificates reach their expiration dates. This can prevent unexpected service interruptions and give enough time for renewal and deployment.

I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

Jason

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.