Detent PointThe default for these endpoints is Windows authentication with the service accounts, which is fine when every replica is a domain member of the same forest. Across a trust boundary — a DR site in another domain, a workgroup node, a partner replica you don’t administer — that stops being simple. Certificate authentication sidesteps it: each side presents its own certificate, and each side is told which of the other’s certificates to trust.
The trade is that it’s a few coordinated steps done on two servers in the right order, and a step done on the wrong side, or skipped, surfaces only when the session refuses to connect.
Three paid tools (Professional tier and up) do the state-changing work. set_sql_endpoint_cert_authentication ensures the endpoint exists and authenticates with a given local certificate — creating it that way when absent, and doing nothing when it’s already so. export_sql_endpoint_certificate writes out the endpoint’s public certificate — the public half only, never the private key — to hand to the partner. grant_sql_endpoint_cert_access takes a partner’s public certificate, creates a login from it, and grants that login CONNECT on the endpoint.
Run the set-and-export pair on each server, then grant each side the other’s certificate, and the two endpoints can authenticate each other. test_sql_endpoint_cert_auth reads back the state — free — so you can confirm each side before expecting the session to come up.
This was proven end to end rather than in a mock: a certificate-authenticated database-mirroring session between two separate instances reached SYNCHRONIZED — the endpoints authenticated each other by certificate over a live cross-node data connection — and a Service Broker message crossed between the same two instances over the same certificate trust. What SqlCertForge does not do is build the mirroring or availability-group topology itself; it sets up the certificate trust the endpoints run on, and points you at replicas that already exist.