Certificates do not conform to algorithm

@brtrach-MSFT

Is there any updates for this? Sha 1 certitifcates have been deprecated since 2021 (https://video2.skills-academy.com/en-us/lifecycle/announcements/sha-1-signed-content-retired)

Anything using Java 17 will not connect to a postgresql server using a sha1 certitifcate now.

@Hedgelot We understand that you are trying to use a newer algorithm with your Azure PostgreSQL flexible server but are encountering an error. We wanted to verify that the flexible server does indeed use the older SHA1 algorithm. At this time, there is not a way to update the algorithm to the newer SHA256 algorithm. The product group will need to make this change for customers. We invite you to create a feedback/product request over here on Azure Feedback to share your request and business justification so they can understand the ask. The product group watches the Azure Feedback site and should review your request. We appreciate your understanding.

There was an announcement via mail to the users of PostgreSQL Flexible that the certificate will be changed in May 2024 and the new cert "Microsoft RSA Root Certificate Authority 2017" uses sha384.

https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt

Also there is a feedback in the Azure Community here:

https://feedback.azure.com/d365community/idea/2cc1f0ed-1931-ee11-a81c-000d3ae37d1e

Action Required for Azure Database for PostgreSQL – Flexible Server to update your trusted root store, if you are doing certificate pinning

You're receiving this notice because you use Azure Database for PostgreSQL – Flexible Server

In May 2024, we’ll begin updating Azure Database for PostgreSQL Flexible Server to use TLS certificates from Microsoft RSA Root Certificate Authority 2017. If your apps use certificate pinning, you’ll need to update your trusted root store to accept this root CA in addition to existing  DigiCert Global Root CA.

• If your applications take advantage of verify-ca or verify-full as value of sslmode parameter in the database client connectivity they may be affected by this change and need to follow below directions to add new certificates to certificate store to maintain connectivity.
• If your connection string includes sslmode=disable, sslmode=allow, sslmode=prefer, or sslmode=require, you don’t need to update certificates. If you’re using a client that abstracts the connection string away, review the client's documentation to understand whether it verifies certificates. To understand PostgreSQL sslmode, review the SSL mode descriptions in PostgreSQL documentation.

Required action

Please download Microsoft RSA Root Certificate Authority 2017 and DigiCert Global Root CA certificates from the following URI. Generate a combined CA certificate store with both DigiCert Global Root CA and Microsoft RSA Root Certificate Authority 2017 certificates are included. For Java (PostgreSQL JDBC) users using DefaultJavaSSLFactory, please use the following certificate:

• keytool -importcert -alias PostgreSQLServerCACert -DigiCertGlobalRootCA.crt.pem -keystore truststore -storepass password -noprompt

keytool -importcert -alias PostgreSQLServerCACert2 -file D:\ Microsoft ECC Root Certificate Authority 2017.crt.pem -keystore truststore -storepass password -noprompt

Then replace the original keystore file with the new generated one:

• System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");

System.setProperty("javax.net.ssl.trustStorePassword","password");

For .NET (Npgsql) users on Windows, make sure DigiCert Global Root CA and Microsoft RSA Root Certificate Authority 2017 both exist in Windows Certificate Store Trusted Root Certification Authorities. For .NET (Npgsql) users on Linux using SSL_CERT_DIR, make sure DigiCert Global Root CA and Microsoft RSA Root Certificate Authority 2017 both exist in the directory indicated by SSL_CERT_DIR. If any certificates don't exist, please create the missing certificate file. For other PostgreSQL client users, you can merge two CA certificate files like the following format:

• -----BEGIN CERTIFICATE-----

(Root CA1: DigiCertGlobalRootCA.crt.pem)

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

(Root CA2: Microsoft ECC Root Certificate Authority 2017.crt.pem)

-----END CERTIFICATE-----

Replace the original root CA pem file with the combined root CA file and restart your application/client. 

If you’re using SSL/TLS, you don't need to restart the database server to start using the new root CA certificate. This is a client-side change, and the incoming client connections need to use the new certificate to ensure that they can connect to the database server. If you aren’t using SSL/TLS, you don’t need to update the root CA certificate and no further action is required. Action Required for Azure Database for PostgreSQL – Flexible Server to update your trusted root store, if you are doing certificate pinning

You're receiving this notice because you use Azure Database for PostgreSQL – Flexible Server

In May 2024, we’ll begin updating Azure Database for PostgreSQL Flexible Server to use TLS certificates from Microsoft RSA Root Certificate Authority 2017. If your apps use certificate pinning, you’ll need to update your trusted root store to accept this root CA in addition to existing  DigiCert Global Root CA.

• If your applications take advantage of verify-ca or verify-full as value of sslmode parameter in the database client connectivity they may be affected by this change and need to follow below directions to add new certificates to certificate store to maintain connectivity.
• If your connection string includes sslmode=disable, sslmode=allow, sslmode=prefer, or sslmode=require, you don’t need to update certificates. If you’re using a client that abstracts the connection string away, review the client's documentation to understand whether it verifies certificates. To understand PostgreSQL sslmode, review the SSL mode descriptions in PostgreSQL documentation.

Required action

Please download Microsoft RSA Root Certificate Authority 2017 and DigiCert Global Root CA certificates from the following URI. Generate a combined CA certificate store with both DigiCert Global Root CA and Microsoft RSA Root Certificate Authority 2017 certificates are included. For Java (PostgreSQL JDBC) users using DefaultJavaSSLFactory, please use the following certificate:

• keytool -importcert -alias PostgreSQLServerCACert -DigiCertGlobalRootCA.crt.pem -keystore truststore -storepass password -noprompt keytool -importcert -alias PostgreSQLServerCACert2 -file D:\ Microsoft ECC Root Certificate Authority 2017.crt.pem -keystore truststore -storepass password -noprompt

Then replace the original keystore file with the new generated one:

• System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");

System.setProperty("javax.net.ssl.trustStorePassword","password");

For .NET (Npgsql) users on Windows, make sure DigiCert Global Root CA and Microsoft RSA Root Certificate Authority 2017 both exist in Windows Certificate Store Trusted Root Certification Authorities. For .NET (Npgsql) users on Linux using SSL_CERT_DIR, make sure DigiCert Global Root CA and Microsoft RSA Root Certificate Authority 2017 both exist in the directory indicated by SSL_CERT_DIR. If any certificates don't exist, please create the missing certificate file. For other PostgreSQL client users, you can merge two CA certificate files like the following format:

• -----BEGIN CERTIFICATE-----

(Root CA1: DigiCertGlobalRootCA.crt.pem)

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

(Root CA2: Microsoft ECC Root Certificate Authority 2017.crt.pem)

-----END CERTIFICATE-----

Replace the original root CA pem file with the combined root CA file and restart your application/client. 

If you’re using SSL/TLS, you don't need to restart the database server to start using the new root CA certificate. This is a client-side change, and the incoming client connections need to use the new certificate to ensure that they can connect to the database server. If you aren’t using SSL/TLS, you don’t need to update the root CA certificate and no further action is required.