Edit

Share via

Transport Layer Security (TLS) in Azure Database for PostgreSQL

Introduction

Azure Database for PostgreSQL requires all client connections to use Transport Layer Security (TLS), an industry-standard protocol that encrypts communications between your database server and client applications. TLS supersedes the older SSL protocol, with only TLS versions 1.2 and 1.3 recognized as secure. The integrity of TLS security relies on three pillars:

  • Using only TLS versions 1.2 or 1.3.
  • Client validates the server's TLS certificate issued by a Certificate Authority (CA) in a chain of CAs started by a trusted root CA.
  • Negotiating a secure cipher suite between server and client.

Trusted root certs and cert rotations

Important

We have started a TLS certificate rotation for Azure Database for PostgreSQL to update new intermediate CA certificates and the resulting certificate chain. The root CAs remain the same.

No action is required if your client configuration implements the Recommended configurations for TLS.

Certificate rotation schedule

  • Azure regions West Central US, East Asia, and UK South started their TLS certificate rotation on November 11, 2025.
  • Beginning January 19, 2026, this certificate rotation is planned to extend to the remaining (except China) regions including Azure Government.
  • After the Spring Festival (Chinese New Year) 2026, China regions will also undergo a certificate rotation that includes a change to one of the root CAs.

Root CAs used by Azure Database for PostgreSQL

Root CAs are the top-level authorities in the certificate chain. Azure Database for PostgreSQL currently uses dual-signed certificates issued by an ICA anchored by the following root CAs:

China regions currently use the following CAs:

About Intermediate CAs

Azure Database for PostgreSQL uses intermediate CAs (ICAs) to issue server certificates. Microsoft periodically rotates these ICAs and the server certificates they issue to maintain security. These rotations are routine and not announced in advance.

The current rotation of intermediate CAs for DigiCert Global Root CA (see Certificate rotation) started in November 2025 and scheduled to be completed in Q1 of 2026 replaces intermediate CAs as follows. If you followed the recommended practices, then this change requires no changes in your environment.

Old CA chain

This information is provided for reference only. Don't use intermediate CAs or server certificates in your trusted root store.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Server certificate

New CA chain

This information is provided for reference only. Don't use intermediate CAs or server certificates in your trusted root store.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Server certificate

Read replicas

Root CA migration from DigiCert Global Root CA to DigiCert Global Root G2 isn't completed in all regions. Therefore, it's possible for newly created read replicas to be on a newer root CA certificate than the primary server. Therefore, you should add DigiCert Global Root CA to the read replicas trusted store.

Certificate chains

A certificate chain is a hierarchical sequence of certificates issued by trusted Certificate Authorities (CAs), starting at the root CA, which issues intermediate CA (ICA) certificates. ICAs may issue certificates for lower ICAs. The lowest ICA in the chain issues individual server certificates. The chain of trust is established by verifying each certificate in the chain up to the root CA certificate.

Reducing connection failures

Utilizing recommended TLS configurations helps reduce the risk of connection failures due to certificate rotations or changes in intermediate CAs. Specifically, avoid trusting intermediate CAs or individual server certificates, as these practices can lead to unexpected connection issues when Microsoft updates the certificate chain.

Important

Changes in root CAs are announced ahead of time to help you prepare your client applications; however, server certificate rotations and changes to intermediate CAs are routine and therefore not announced.

Caution

Using unsupported (client) configurations cause unexpected connection failures.

Best configuration

  • Enforce the latest, most secure TLS version by setting the ssl_min_protocol_version server parameter to TLSv1.3.
  • Use sslmode=verify-all for PostgreSQL connections to ensure full certificate and hostname verification. Depending on your DNS configuration with Private Endpoints or VNET integration, verify-all might not be possible; therefore you may use verify-ca instead.
  • Always maintain the complete set of Azure root certificates in your trusted root store.

Good configuration

  • Set the ssl_min_protocol_version server parameter to TLSv1.3. If you must support TLS 1.2, don't set the minimal version.
  • Use sslmode=verify-all or sslmode=verify-ca for PostgreSQL connections to ensure full or partial certificate verification.
  • Ensure that the trusted root store contains the root CA certificate currently used by Azure Database for PostgreSQL:

We strongly advise against the following configurations:

  • Disable TLS completely by setting require_secure_transport to OFF and setting the client-side to sslmode=disable.
  • Prevent man-in-the-middle attacks by avoiding client-side sslmode settings disable, allow, prefer, or require.

Unsupported configurations; do not use

Azure PostgreSQL doesn't announce changes about intermediate CA changes or individual server certificate rotations; therefore, the following configurations are unsupported when using sslmode settings verify-ca or verify-all:

  • You use intermediate CA certificates in your trusted store.
  • You use certificate pinning, such as, using individual server certificates in your trusted store.

Caution

Your applications fail to connect to the database servers without warning whenever Microsoft changes the certificate chain’s intermediate CAs or rotates the server certificate.

Certificate pinning issues

Note

If you aren't using sslmode=verify-full or sslmode=verify-ca settings in your client application connection string, then certificate rotations don't affect you. Therefore, you don't need to follow the steps in this section.

Never use certificate pinning in your applications since it breaks certificate rotation such as the current certificate change of intermediate CAs. If you don't know what certificate pinning is, it's unlikely that you're using it. To check for certificate pinning:

  • Produce your list of certificates that are in your trusted root store.
  • You're using certificate pinning if you have intermediate CA certificates or individual PostgreSQL server certificates in your trusted root store.
  • To remove certificate pinning, remove all the certificates from your trusted root store and add the recommended root CA certificates.

If you're experiencing issues due to the intermediate certificate even after following these steps, contact Microsoft support. Include in the title ICA Rotation 2026.

Other considerations for TLS

Insecure and secure TLS versions

Several government entities worldwide maintain guidelines for TLS regarding network security. In the United States, these organizations include the Department of Health and Human Services and the National Institute of Standards and Technology. The level of security that TLS provides is most affected by the TLS protocol version and the supported cipher suites.

Azure Database for PostgreSQL supports TLS version 1.2 and 1.3. In RFC 8996, the Internet Engineering Task Force (IETF) explicitly states that TLS 1.0 and TLS 1.1 must not be used. Both protocols were deprecated by the end of 2019. All incoming connections that use earlier insecure versions of the TLS protocol, such as TLS 1.0 and TLS 1.1, are denied by default.

The IETF released the TLS 1.3 specification in RFC 8446 in August 2018, and TLS 1.3 is the recommended version since it's faster and more secure than TLS 1.2.

Although we don't recommend it, if needed, you can disable TLS for connections to your Azure Database for PostgreSQL. You can update the require_secure_transport server parameter to OFF.

Important

We strongly recommend that you use the latest versions of TLS 1.3 to encrypt your database connections. You can specify the minimal TLS version by setting the ssl_min_protocol_version server parameter to TLSv1.3. Don't set the ssl_max_protocol_version server parameter.

Cipher suites

A cipher suite is a set of algorithms that include a cipher, a key-exchange algorithm, and a hashing algorithm. They're used together with the TLS certificate and the TLS version to establish a secure TLS connection. Most TLS clients and servers support multiple cipher suites and sometimes multiple TLS versions. During the establishment of the connection, the client and server negotiate the TLS version and cipher suite to use through a handshake. During this handshake, the following occurs:

  • Client sends a list of acceptable cipher suites.
  • Server selects the best (by its own definition) cipher suite from the list and informs the client of the choice.

TLS features not available in Azure Database for PostgreSQL

At this time, Azure Database for PostgreSQL doesn't implement the following TLS features:

  • TLS certificate-based client authentication through TLS with mutual authentication (mTLS).
  • Custom server certificates (bring your own TLS certificates).

Related content

  • Last updated on