Does VerifyFull authenticate a specific PostgreSQL Flexible Server under private VNet DNS redirection?

Question

For Azure Database for PostgreSQL Flexible Server using private VNet integration, does a connection using Npgsql VerifyFull to the designated server’s FQDN authenticate and route exclusively to that server resource?

If TLS terminates on shared infrastructure, what prevents DNS or address redirection from reaching another database while certificate verification still succeeds?

Please distinguish guarantees provided by TLS verification from those that require trusted private DNS, routing, resource-lifecycle controls or other customer configuration. Does this behavior hold across certificate rotation, restore, revival and server-name reuse?

Answer 1

Hello @Duane Wald

No. Npgsql SslMode=VerifyFull does not cryptographically authenticate a specific Azure Resource Manager PostgreSQL server. It verifies two things:

1. The server certificate chains to a trusted certificate authority.
2. The certificate is valid for the hostname supplied in the connection string.

Npgsql describes VerifyFull as encryption, certificate validation, and verification against the specified hostname.

Therefore, VerifyFull protects against an untrusted endpoint or a certificate that doesn’t match the requested FQDN. It doesn’t validate the Azure subscription, resource group, ARM resource ID, database contents, or lifecycle identity of the server.

The connection reaches the intended resource through several independent controls:

• Private DNS must resolve the designated FQDN to the correct private address.
• The client VNet must be linked to the appropriate private DNS zone.
• VNet routing, NSGs, firewalls, and delegated-subnet controls must permit only the intended path.
• Azure’s service infrastructure must map the endpoint to the intended Flexible Server.
• PostgreSQL authentication must then authorize the supplied database identity.

I recommend always connecting with the server FQDN because the private IP address can change. Clients in other VNets must also be linked to the server’s private DNS zone or use an appropriately configured DNS forwarder.

If DNS is maliciously or incorrectly redirected, VerifyFull fails only when the endpoint cannot present a trusted certificate valid for the requested FQDN. Microsoft’s documentation doesn’t state that the TLS certificate uniquely identifies one Azure ARM resource, so it shouldn’t be treated as resource-level attestation.

Certificate rotation should continue to work as long as the replacement certificate remains valid for the FQDN and chains to a root trusted by the client. I recommend retaining the complete Azure root CA set to accommodate certificate changes.

A restore is different: point-in-time and geo-restore operations create a new Flexible Server rather than overwriting the original. Update the connection string to the restored server’s name and recreate the required networking controls.

Finally, VerifyFull does not guarantee continuity after deletion and server-name reuse. If a future resource legitimately owns the same DNS name and presents a trusted certificate valid for that name, hostname verification alone doesn’t distinguish it from the former resource. Use Azure RBAC, deletion protection or resource locks, controlled private DNS permissions, Azure Policy, and deployment governance where resource continuity matters.

References:

Npgsql security documentation

Configure TLS for PostgreSQL Flexible Server

Private networking for PostgreSQL Flexible Server

Backup and restore concepts

---

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Answer 2

Npgsql VerifyFull authenticates the certificate chain and the hostname supplied in the connection string; it does not cryptographically bind the session to a particular Azure resource ID, subscription, tenant, private IP, or historical server instance.

What VerifyFull guarantees

For a connection such as:

var cs = new NpgsqlConnectionStringBuilder
{
    Host = "myserver.postgres.database.azure.com",
    Database = "appdb",
    Username = "appuser",
    Password = password,
    SslMode = SslMode.VerifyFull
}.ConnectionString;

await using var connection = new NpgsqlConnection(cs);
await connection.OpenAsync();

VerifyFull requires TLS, validates the server certificate to a trusted CA, and verifies that the certificate matches myserver.postgres.database.azure.com.^1^

Consequently:

• Redirecting DNS to an endpoint that cannot present a trusted certificate valid for that hostname causes TLS validation to fail.
• Redirecting the IP while retaining the original hostname does not by itself defeat VerifyFull; the endpoint must still satisfy certificate-chain and hostname validation.
• VerifyFull does not inspect the Azure Resource Manager resource ID.
• TLS validates the service name represented by the certificate—not which private DNS record, VNet, subnet, subscription, or Flexible Server resource produced the address.

The available documentation does not state that every Flexible Server receives a certificate containing a unique, immutable resource identity, nor that a certificate matching its FQDN can only ever be presented by one backend. Therefore, an exclusive-resource guarantee cannot be inferred from VerifyFull alone, including when TLS terminates on shared service infrastructure.

Database authentication is an additional check, but it authenticates the supplied PostgreSQL or Microsoft Entra credentials under the server reached; it does not turn the TLS certificate into an Azure resource-ID assertion.

What prevents unintended redirection

The complete boundary is layered:

Layer	What it establishes
VerifyFull	Trusted certificate chain and hostname match
Private DNS	Which private address the FQDN resolves to
VNet routing/peering	Which endpoint is reachable from the client
NSGs and route tables	Which network paths and port 5432 flows are allowed
PostgreSQL/Entra authentication	Whether the principal can sign in to the reached server
Azure control-plane governance	Who can change DNS, networking, delete, restore, or recreate resources

With VNet integration, Azure Private DNS supplies resolution inside linked VNets. DNS-zone links and VNet peering are independent; clients in another VNet need access to the server’s Private DNS zone. Custom DNS must forward Flexible Server FQDN resolution to Azure DNS, and routing/NSGs remain separate from name resolution.^2^

For a stronger operational guarantee:

1. Use the server’s official FQDN as Host; do not connect by raw private IP.
2. Set SslMode=VerifyFull.
3. Trust Azure’s supported root CAs, not an intermediate or individual server certificate.
4. Restrict modification of the linked Private DNS zone, VNet links, route tables, NSGs, and server resource through Azure RBAC.
5. Monitor those resources for control-plane changes.
6. Use a resource lock to reduce accidental server deletion; Microsoft explicitly recommends one for that purpose.^3^
7. If the application must detect that it reached a particular logical deployment, perform an application-level check after login—for example, query a deployment identifier stored in a protected table—and reject an unexpected value. That is an application control, not a TLS guarantee.

Rotation, restore, revival, and name reuse

Certificate rotation: The hostname-and-CA guarantee continues when configured as recommended. Maintain Azure’s complete supported root set and do not pin an intermediate or leaf/server certificate. Intermediate and server-certificate rotations are routine and may be unannounced; pinning them is unsupported and can cause connection failures.^4^

Point-in-time restore: A restore provisions a new server, and its chosen unique name forms its FQDN. VerifyFull authenticates that resulting hostname; it does not prove that the new resource is the same Azure resource or has the intended restored data.^5^

Deleted-server revival: Recovery is available only under documented conditions and is not guaranteed. A revived server may use a name different from the deleted server; VNet-enabled recovery must also specify the delegated subnet and private DNS zone. Microsoft recommends using a different name to avoid possible DNS errors during restoration.^6^

Server-name reuse: No documented TLS guarantee binds a reused FQDN permanently to the former resource or its data. If a name later resolves to a service presenting a trusted certificate valid for that name, hostname verification can succeed. Treat deletion/recreation and DNS reassignment as lifecycle events requiring control-plane governance and application-level identity validation where continuity matters.

---

References

1. Configure TLS connection in Azure Database for PostgreSQL flexible server
2. Network with private access (virtual network integration) in Azure Database for PostgreSQL flexible server
3. Backup and restore in Azure Database for PostgreSQL flexible server
4. Transport Layer Security (TLS) in Azure Database for PostgreSQL flexible server
5. Restore to latest restore point
6. Restore a deleted server in Azure Database for PostgreSQL flexible server