Condividi tramite

Proteggere la connettività con TLS in Database di Azure per PostgreSQL

Database di Azure per PostgreSQL richiede la connessione delle applicazioni client a un'istanza di server flessibile di Database di Azure per PostgreSQL utilizzando il protocollo Transport Layer Security (TLS). TLS è un protocollo standard del settore che garantisce connessioni di rete crittografate tra il server di database e le applicazioni client. TLS è un protocollo aggiornato di Secure Sockets Layer (SSL). I termini SSL e TLS vengono ancora usati in modo intercambiabile.

Importante

A partire dal 11 novembre 2025, le aree di Azure nell'elenco seguente sono pianificate per una rotazione dei certificati TLS/SSL che usa nuovi certificati CA intermedi.

  • Stati Uniti centro-occidentali
  • East Asia
  • UK South

A partire dal 19 gennaio 2026, questa rotazione è pianificata per estendersi a tutte le aree di Azure rimanenti, tra cui Azure per enti pubblici e tutte le altre aree.

Per informazioni sulla risoluzione dei problemi, vedere Problemi di associazione del certificato.

Catene di certificati

Una catena di certificati è un elenco ordinato di certificati che contengono un certificato TLS/SSL e certificati CA. Consentono al ricevitore di verificare che il mittente e tutte le CA siano attendibili. La catena o il percorso inizia con il certificato TLS/SSL. Ogni certificato nella catena è firmato dall'entità identificata dal certificato successivo nella catena.

La catena termina con un certificato della CA radice. Questo certificato è sempre firmato dalla CA stessa. Le firme di tutti i certificati nella catena devono essere verificate fino al certificato della CA radice.

Qualsiasi certificato che si trova tra il certificato TLS/SSL e il certificato CA radice nella catena è denominato certificato intermedio.

Versioni di TLS

Diverse entità governative a livello globale mantengono linee guida per TLS in materia di sicurezza di rete. Negli Stati Uniti, queste organizzazioni includono il Dipartimento della salute e dei servizi umani e l'Istituto nazionale di standard e tecnologia. Il livello di sicurezza fornito da TLS è più interessato dalla versione del protocollo TLS e dai pacchetti di crittografia supportati.

Una suite di crittografia è un set di algoritmi che includono una crittografia, un algoritmo di scambio di chiavi e un algoritmo hash. Vengono usati insieme per stabilire una connessione TLS sicura. La maggior parte dei client e dei server TLS supporta più alternative. Devono negoziare, al momento della creazione di una connessione sicura, per selezionare una versione TLS e una suite di cifratura comuni.

Database di Azure per PostgreSQL supporta la versione 1.2 e successive di TLS. In RFC 8996, la Internet Engineering Task Force (IETF) indica in modo esplicito che TLS 1.0 e TLS 1.1 non devono essere usati. Entrambi i protocolli sono stati deprecati entro la fine del 2019.

Tutte le connessioni in ingresso che usano versioni precedenti del protocollo TLS, ad esempio TLS 1.0 e TLS 1.1, verranno rifiutate per impostazione predefinita.

IETF ha rilasciato la specifica TLS 1.3 in RFC 8446 nell'agosto 2018 e TLS 1.3 è ora la versione TLS più comune e consigliata in uso. TLS 1.3 è più veloce e più sicura di TLS 1.2.

Annotazioni

I certificati SSL e TLS certificano che la connessione è protetta con protocolli di crittografia all'avanguardia. Crittografando la connessione durante la trasmissione, si impedisce l'accesso non autorizzato ai dati durante il transito. È consigliabile usare le versioni più recenti di TLS per crittografare le connessioni a un'istanza del server flessibile di Database di Azure per PostgreSQL.

Anche se non è consigliabile, se necessario, è possibile disabilitare TLS\SSL per le connessioni all'istanza del server flessibile di Database di Azure per PostgreSQL. È possibile aggiornare il parametro del server require_secure_transport a OFF. È anche possibile impostare la versione di TLS impostando i parametri del server ssl_min_protocol_version e ssl_max_protocol_version.

L'autenticazione del certificato viene eseguita usando i certificati client SSL per l'autenticazione. In questo scenario, il server PostgreSQL confronta l'attributo nome comune del certificato client presentato con l'utente del database richiesto.

Al momento, Database di Azure per PostgreSQL non supporta:

Annotazioni

Microsoft ha apportato modifiche alla CA radice per vari servizi di Azure, tra cui Database di Azure per PostgreSQL. Per altre informazioni, vedere Modifiche al certificato TLS di Azure e la sezione Configurare SSL nel client.

Per determinare lo stato corrente della connessione TLS\SSL, è possibile caricare l'estensione sslinfo e quindi chiamare la funzione ssl_is_used() per determinare se viene usato SSL. La funzione restituisce t se la connessione usa SSL. In caso contrario, viene restituito f. È anche possibile raccogliere tutte le informazioni sull'utilizzo SSL dell'istanza del server flessibile di Database di Azure per PostgreSQL tramite processo, client e applicazione usando la query seguente:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Per i test, è anche possibile usare direttamente il comando openssl:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Questo comando stampa informazioni di protocollo di basso livello, ad esempio la versione e la crittografia TLS. È necessario usare l'opzione -starttls postgres. In caso contrario, questo comando segnala che non è in uso alcun protocollo SSL. L'uso di questo comando richiede almeno OpenSSL 1.1.1.

Per applicare la versione più recente e più sicura di TLS per la protezione della connettività dal client a un server flessibile di Azure Database per PostgreSQL, impostare il parametro su ssl_min_protocol_version1.3. Questa impostazione richiede ai client che si connettono all'istanza del server flessibile di Database di Azure per PostgreSQL di usare questa versione del protocollo solo per comunicare in modo sicuro. I client meno recenti potrebbero non essere in grado di comunicare con il server perché non supportano questa versione.

Configurare SSL nel client

Per impostazione predefinita, PostgreSQL non esegue alcuna verifica del certificato del server. Per questo motivo, è possibile eseguire lo spoofing dell'identità del server (ad esempio, modificando un record DNS o acquisendo l'indirizzo IP del server) senza che il client ne sia a conoscenza. Tutte le opzioni SSL comportano un certo sovraccarico dovuto alla crittografia e allo scambio di chiavi, quindi si rende necessario un compromesso tra prestazioni e sicurezza.

Per evitare lo spoofing, è necessario usare la verifica del certificato SSL nel client.

Esistono molti parametri di connessione per configurare il client per SSL. Alcuni tra i più importanti sono:

  • ssl: Connettere tramite SSL. Questa proprietà non richiede un valore associato. La sua semplice presenza specifica una connessione SSL. Per la compatibilità con le versioni future, il valore true è preferibile. In questa modalità, quando si stabilisce una connessione SSL, il driver del client convalida l'identità del server per impedire attacchi "man in the middle". Verifica che il certificato del server sia firmato da un'autorità attendibile e che l'host a cui ci si connette sia lo stesso del nome host nel certificato.

  • sslmode: se si necessita di crittografia e si vuole che la connessione venga interrotta se non può essere crittografata, impostare sslmode=require. Questa impostazione garantisce che il server sia configurato per accettare le connessioni SSL per questo host o indirizzo IP e che il server riconosca il certificato client. Se il server non accetta connessioni SSL o il certificato client non viene riconosciuto, la connessione non riesce. Nella tabella seguente sono elencati i valori per questa impostazione:

    SSL Mode (Modalità SSL) Explanation
    disable La crittografia non è usata.
    allow La crittografia viene usata se le impostazioni del server la richiedono o la impongono.
    prefer La crittografia viene usata se le impostazioni del server lo consentono.
    require La crittografia viene usata. Ciò garantisce che il server sia configurato per accettare le connessioni SSL per questo host o indirizzo IP e che il server riconosca il certificato client.
    verify-ca La crittografia viene usata. Verificare la firma del certificato del server rispetto al certificato archiviato nel client.
    verify-full La crittografia viene usata. Verificare la firma del certificato del server e il nome host rispetto al certificato archiviato nel client.

La modalità predefinita sslmode usata è diversa tra i client basati su libpq (ad esempio psql) e JDBC. Per impostazione predefinita, i client basati su libpq sono prefer. Per impostazione predefinita, i client JDBC sono verify-full.

  • sslcert, sslkeye sslrootcert: questi parametri possono eseguire l'override del percorso predefinito del certificato client, della chiave client PKCS-8 e del certificato radice. Per impostazione predefinita, i valori sono /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 e /defaultdir/root.crt rispettivamente, mentre defaultdir corrisponde a ${user.home}/.postgresql/ nei sistemi Linux e a %appdata%/postgresql/ su Windows.

Le autorità di certificazione sono le istituzioni responsabili per il rilascio dei certificati. Un'autorità di certificazione attendibile è un'entità autorizzata a verificare che qualcuno sia realmente chi dichiara di essere. Affinché questo modello funzioni, tutti i partecipanti devono accettare un set di CA attendibili. Tutti i sistemi operativi e la maggior parte dei Web browser prevedono un set di CA attendibili.

L'utilizzo delle impostazioni di configurazione verify-ca e verify-fullsslmode può anche essere noto come associazione del certificato. In questo caso, i certificati CA radice nel server PostgreSQL devono corrispondere alla firma del certificato e anche al nome host rispetto al certificato nel client.

Potrebbe essere necessario aggiornare periodicamente i certificati archiviati dal client quando le CA cambiano o scadono nei certificati del server PostgreSQL. Per determinare se si stanno aggiungendo CA, vedere Aggiunta di certificati e servizi di Azure.

Per altre informazioni sulla configurazione di SSL\TLS nel client, vedere la documentazione di PostgreSQL.

Per i client che usano le impostazioni di configurazione verify-ca e verify-fullsslmode (ovvero l'aggiunta di certificati) devono distribuire tre certificati CA radice negli archivi certificati client:

Scaricare i certificati CA radice e aggiornare i client dell'applicazione negli scenari di aggiunta di certificati

Per aggiornare le applicazioni client negli scenari di aggiunta di certificati, è possibile scaricare i certificati:

Per importare i certificati negli archivi certificati client, potrebbe essere necessario convertire i file con estensione .crt del certificato in formato .pem dopo aver scaricato i file di certificato dagli URI precedenti. È possibile usare l'utilità OpenSSL per eseguire queste conversioni di file:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

Le informazioni sull'aggiornamento degli archivi certificati delle applicazioni client con nuovi certificati CA radice sono documentate in Aggiornare i certificati TLS client per i client dell'applicazione.

Importante

Alcune delle librerie client Postgres, mentre l'impostazione sslmode=verify-full è in uso, potrebbero riscontrare errori di connessione con certificati CA radice firmati con certificati intermedi. Il risultato è percorsi di attendibilità alternativi. In questo caso, è consigliabile specificare in modo esplicito il parametro sslrootcert. In alternativa, impostare la variabile di ambiente PGSSLROOTCERT su un percorso locale in cui viene inserito il certificato CA radice Microsoft RSA 2017, dal valore predefinito di %APPDATA%\postgresql\root.crt.

  1. Interruzione della connettività dall'applicazione client all'istanza del server flessibile di Database di Azure per PostgreSQL: è stato aperto un ticket di supporto.
  2. Se il certificato intermedio è stato ruotato, potrebbe essere necessario aggiornare l'archivio certificati client con il nuovo certificato intermedio.
  3. come verificare se si esegue l'associazione del certificato intermedio - vedere Associazione del certificato e servizi di Azure.

Repliche in lettura con scenari di associazione del certificato

Con la migrazione della CA radice a Microsoft RSA Root CA 2017, è possibile che le repliche appena create siano in un certificato CA radice più recente rispetto al server primario creato in precedenza. Per i client che usano le impostazioni di configurazione verify-ca e verify-fullsslmode (ovvero l'aggiunta di certificati), è fondamentale che la connettività interrotta accetti tre certificati CA radice:

Al momento, Database di Azure per PostgreSQL non supporta l'autenticazione basata su certificati.

Testare i certificati client connettendosi con psql negli scenari di aggiunta di certificati

È possibile usare la riga di comando psql dal client per testare la connettività al server negli scenari di aggiunta del certificato:

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Per altre informazioni sui parametri SSL e certificato, vedere la documentazione di psql.

Testare la connettività TLS/SSL

Prima di provare ad accedere al server abilitato per SSL da un'applicazione client, assicurarsi di potervi accedere tramite psql. Se è stata stabilita una connessione SSL, verrà visualizzato un output simile all'esempio seguente:

psql (14.5)connessione SSL (protocollo: TLSv1.2, crittografia: ECDHE-RSA-AES256-GCM-SHA384, bit: 256, compressione: off)tipo "help" per assistenza.

È anche possibile caricare l'estensione sslinfo e quindi chiamare la funzione ssl_is_used() per determinare se SSL sia in uso. La funzione restituisce t se la connessione usa SSL. In caso contrario, viene restituito f.

Pacchetti di crittografia

Una suite di crittografia è un set di algoritmi crittografici. I protocolli TLS/SSL usano algoritmi di una suite di crittografia per creare chiavi e crittografare le informazioni.

Una pacchetto di crittografia viene visualizzata come una lunga stringa di informazioni apparentemente casuali, ma ogni segmento di tale stringa contiene informazioni essenziali. In genere, questa stringa di dati include diversi componenti chiave:

  • Protocollo (ovvero TLS 1.2 o TLS 1.3)
  • Algoritmo di scambio delle chiavi o contratto
  • Algoritmo di firma digitale (autenticazione)
  • Algoritmo di crittografia di massa
  • Algoritmo di Message Authentication Code (MAC)

Versioni diverse di TLS/SSL supportano suite di crittografia diverse. I pacchetti di crittografia di TLS 1.2 non possono essere negoziati con connessioni TLS 1.3 e viceversa.

Al momento, Database di Azure per PostgreSQL supporta molte suite di crittografia con la versione del protocollo TLS 1.2 che rientra nella categoria HIGH:!aNULL .

Troubleshoot

Usare le indicazioni riportate in questa sezione Risolvere i problemi per identificare e risolvere rapidamente i problemi comuni di TLS/SSL. Iniziare riproducendo il problema e raccogliendo i dati di diagnostica (messaggi di errore lato client, output psql, openSSL s_client output e log del server), quindi verificare i parametri del server (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), la catena di certificati e le impostazioni sslmode/sslrootcert client per individuare le mancate corrispondenze nelle versioni del protocollo, pacchetti di crittografia o certificati mancanti/ruotati.

Errori di connettività TLS/SSL

  1. Il primo passaggio per risolvere i problemi di compatibilità delle versioni del protocollo TLS/SSL consiste nell'identificare i messaggi di errore visualizzati dall'utente o dagli utenti quando tentano di accedere all'istanza del server flessibile di Database di Azure per PostgreSQL nella crittografia TLS dal client. A seconda dell'applicazione e della piattaforma, i messaggi di errore potrebbero differire. In molti casi, indicano chiaramente il problema sottostante.
  2. Per essere certi della compatibilità della versione del protocollo TLS/SSL, è necessario controllare la configurazione TLS/SSL del server di database e del client dell'applicazione per assicurarsi che supportino le versioni compatibili e i pacchetti di crittografia.
  3. Analizzare eventuali discrepanze o lacune tra il server di database e le versioni TLS/SSL del client e i pacchetti di crittografia. Provare a risolverli abilitando o disabilitando determinate opzioni, aggiornando o eseguendo il downgrade del software o modificando certificati o chiavi. Ad esempio, potrebbe essere necessario abilitare o disabilitare versioni TLS/SSL specifiche nel server o nel client, a seconda dei requisiti di sicurezza e compatibilità. Ad esempio, potrebbe essere necessario disabilitare TLS 1.0 e TLS 1.1, considerati non sicuri e deprecati, e abilitare TLS 1.2 e TLS 1.3, più sicuri e moderni.
  4. Il certificato più recente rilasciato con Microsoft RSA Root CA 2017 ha un livello intermedio nella catena con firma incrociata da Digicert Global Root G2 CA. Alcune delle librerie client Postgres, mentre le impostazioni sslmode=verify-full o sslmode=verify-ca sono in uso, potrebbero riscontrare errori di connessione con certificati CA radice firmati con certificati intermedi. Il risultato è percorsi di attendibilità alternativi.

Per risolvere questi problemi, aggiungere tutti e tre i certificati necessari all'archivio certificati client o specificare in modo esplicito il parametro sslrootcert. In alternativa, impostare la variabile di ambiente PGSSLROOTCERT al percorso locale in cui viene inserito il certificato CA radice Microsoft RSA 2017, dal valore predefinito di %APPDATA%\postgresql\root.crt.

Problemi di associazione del certificato

Annotazioni

Se non utilizzi le impostazioni sslmode=verify-full o sslmode=verify-ca nella stringa di connessione dell'applicazione client, le rotazioni dei certificati non ti riguardano. Pertanto, non è necessario seguire i passaggi descritti in questa sezione.

  1. Verificare se si sta usando l'associazione del certificato nell'applicazione.
  2. Genera l'elenco dei certificati presenti nell'archivio radice attendibile
    1. Ad esempio, è possibile ottenere un elenco di certificati attendibili nell'archivio chiavi Java a livello di codice.
    2. Ad esempio, è possibile controllare l'archivio chiavi Java cacerts per verificare se contiene già i certificati necessari.
  3. Si usa l'associazione del certificato, se si possiedono certificati intermedi individuali o certificati individuali del server PostgreSQL.
  4. Per rimuovere l'associazione, rimuovi tutti i certificati dall'archivio radice attendibile e aggiungi i nuovi certificati.
    1. È possibile scaricare i certificati aggiornati dal repository ufficiale di Microsoft: dettagli dell'autorità di certificazione di Azure.
      1. Catena corrente:
        1. DigiCert Global Root G2
        2. Microsoft Azure RSA TLS CA emittente 03 / 04 / 07 / 08
      2. Nuova catena:
        1. DigiCert Global Root G2
        2. Microsoft TLS RSA Root G2
        3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

Se si verificano problemi anche dopo aver seguito questi passaggi, contattare il supporto tecnico Microsoft. Includi nel titolo Rotazione ICA 2026.

Contenuti correlati

  • Last updated on