What’s the issue?
Always On Availability Group endpoints can be configured to authenticate connections between replicas using either Windows authentication or certificate-based authentication. Certificate authentication is the standard approach in workgroup environments, in deployments that span Active Directory domain boundaries, or in any scenario where Windows authentication between the SQL Server service accounts is not practical.When certificates are used, each replica has its own certificate that authenticates outbound connections, and it trusts the certificates of its partner replicas through copies imported into the master database. Like all SQL Server certificates, these certificates have an expiry_date property recorded in sys.certificates.
This finding identifies AG endpoints configured with certificate authentication where the certificate has an expiration date set, particularly those approaching expiration.
Why is this a problem?
For endpoint authentication, SQL Server does check certificate expiration during the authentication handshake, so an expired certificate can prevent replicas from establishing connections to each other. The behavior is different from TDE certificate expiration (which only produces a warning), and it can cause genuine outages of AG synchronization once the certificate has expired.The most likely operational impact is that AG synchronization stops working at the moment the certificate expires. Existing connections may continue for some time, but new connection attempts after expiration fail authentication, which can cascade into the AG appearing as not synchronizing, transaction log growth on the primary, and inability to fail over cleanly. The cause may not be obvious without specifically checking certificate expiration on each replica.
Certificate expiration is also frequently overlooked because endpoint certificates are not managed through the same processes as web server certificates or other application-level certificates. They live entirely inside SQL Server, and unless someone has deliberately added them to a tracking system, the expiration date can pass without anyone noticing until the AG breaks.
Some organizations also have policies that require certificate rotation on a defined schedule for security reasons, regardless of whether a specific service enforces expiration. Long-lived certificates increase the impact of a potential certificate compromise, so rotating them periodically is a reasonable security practice in addition to the operational requirement of replacing them before they expire.
What should you do about this?
Plan a certificate rotation well before expiration. Create a new certificate on each replica with an appropriate expiration date, export the new certificates, and import each replica’s certificate to its partner replicas. Update the endpoint configuration on each replica to use the new certificate using ALTER ENDPOINT [EndpointName] FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE [NewCertificateName]);, and verify that AG synchronization continues to work after the change.Test the new configuration carefully, since a misconfigured rotation can break authentication between replicas and disrupt AG operation. Plan the rotation during a maintenance window, have a rollback path in place, and verify connectivity from each replica to every other replica before considering the rotation complete.
Retain the old certificates and their backups until you are certain the rotation is fully successful and stable. Once the new certificates have been verified working across all replicas and any failover scenarios, the old certificates can be removed from the master database, although there is little downside to leaving them in place beyond minor metadata clutter.