Configurazione della validazione hostname per le connessioni TLS a server alternativi, server federati e altre topologie

È possibile configurare il Db2 11.5.6 per convalidare i nomi di host dei server elencati nei certificati restituiti quando si negoziano connessioni TLS a varie istanze Db2 istanze. Questo argomento ha esaminato la configurazione della convalida del nome host per connessioni a server Db2 alternativi, origini dati federate e altre topologie di rete.

Connessioni ai server alternativi

Un server alternativo è un server Db2 a cui viene dirottato un client Db2 durante ACR, se si perde la connessione originale al database. Per la convalida hostname per riuscire per questa connessione rerouted, il nomehostname nel certificato restituito dal server alternativo deve corrispondere al nome hostname specificato nel comando UPDATE ALTERNATE SERVER eseguito sul server originale:
UPDATE ALTERNATE SERVER FOR DATABASE USING <HOSTNAME> PORT <PORT NUMBER>
Utilizzare un hostname completamente qualificato durante l'esecuzione di questo comando.

Connessioni ai server z/OS

In un ambiente sysplex, un client Db2 deve connettersi al server Db2 per il server z/OS utilizzando il nome hostname che si assota all'indirizzo IP del distributore. Quando si impostano i certificati sul server, utilizzare un certificato comune su tutti i membri contenenti questo hostname.

Ad esempio, se un client Db2 tenta di connettersi a xyz.db2.example.com con una stringa di connessione che include il nomehost, il certificato restituito deve includere xyz.db2.example.com in SAN o il Nome comune per la validazione hostname per avere successo. Questo indipendentemente da dove le connessioni vengono instradate al distributore.

Stringa di connessione di esempio:
 Hostname=xyz.db2.example.com;Security=SSL;SSLClientHostnameValidation=Basic;Database=…
Il seguente esempio mostra come il certificato deve apparire per la validazione del nome host per avere successo.
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: xyz.db2.example.com

Signature Algorithm : SHA1WithRSASignature
Se un client Db2 si collega ad uno dei membri del sysplex direttamente invece di passare attraverso il distributore, il certificato restituito dal membro di destinazione deve includere il nome host del membro a cui il client è configurato per connettersi.
Nota: Se viene utilizzato un indirizzo IP invece di un hostname per connettersi a un server Db2 per z/OS , il certificato restituito dal server dovrebbe contenere questo indirizzo IP per la validazione del nome host per avere successo.

Connessioni a origini dati federate

Quando un'origine dati federata viene configurata su un server Db2 , il server si comporta come un richiedente dell'applicazione quando si comunica con questa fonte di dati. TLS è supportato per queste connessioni in uscita e la seguente opzione server wrapper DRDA federato controlla il comportamento di validazione del nome host.

Sintassi opzione server:
SSL_HOSTNAMEVALIDATION = 'Basic' | 'OFF'
dove
  • La validazione di base = Hostname è abilitata
  • OFF = convalida Hostname è disabilitata. Questo è il valore predefinito.
    Nota: TLS deve essere abilitato quando si imposta SSL_HOSTNAMEVALIDATION su OFF.
    Questa opzione server è limitata attualmente al wrapper DRDA e può essere impostata solo quando TLS è abilitata. Quando TLS non è abilitato, impostare SSL_HOSTNAMEVALIDATION su 'Basic' o 'OFF' per il server di federazione genera l'errore SQL1881N . Utilizzare le seguenti opzioni del server per abilitare TLS:
    • SSL_MEMORIZZAZIONE
    • SSL_KEYSTASH
    • SSL_SERVERCERTIFICATO

    Per ulteriori informazioni, vedere Convalida del nome host per i client di Db2 11.5.6.

Connessioni ai gateway Db2 Connect

Quando Db2 si comporta come un server gateway, come avviene per un server Db2 Connect , la validazione del nome host può essere abilitata per le connessioni TLS in entrata.

Abilitare la convalida del nome host per connessioni in entrata impostando il parametro SSLHostnameValidation DS Driver su Base sul client. La validazione hostname non è disponibile per le connessioni TLS in uscita dal server Gateway.

Connessione ai server KMIP

Se si imposta la parola chiave SSL_KMIP_CLIENT_HOSTNAME_VALIDATION nel file di configurazione del keystore su BASIC, Db2 convalida che il nome dell'host del server KMIP sia contenuto nel certificato usato dal server KMIP quando si stabilisce la connessione TLS. Per ulteriori informazioni, vedere Creazione di un file di configurazione del keystore KMIP

Connessioni ai server multi - homed

Un server multi - homed può essere conosciuto da più di un hostname. Ciò significa che un client Db2 può connettersi allo stesso server di database utilizzando più nomi host. Il certificato del server deve contenere tutti i nomi host che i client utilizzano per collegarsi al database.

Ad esempio, se un server Db2 è noto con i nomi host xyz.db2.example1.com, abc.db2.example2.come pqr.db2.example3.com, è necessario includere tali nomi host, separati da virgole, nell'istruzione SAN del comando IBM Global Security Kit (GSKit) :

Il seguente esempio mostra come il certificato deve apparire per la validazione del nome host per avere successo. Notare i nomi hostomi elencati nella sezione Extensions del certificato restituito:
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=ExampleCA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: xyz.db2.example1.com
        dNSName: abc.db2.example2.com
        dNSName: pqr.db2.example3.com

Signature Algorithm : SHA1WithRSASignature
Nota: I nomi host delle carte Wild possono essere utilizzati anche se questi hostnomi fanno parte dello stesso dominio.

Connessioni che utilizzano nomi record DNS CNAME e DNAME

In un server DNS, i record CNAME e DNAME possono essere utilizzati per creare alias ad un hostname del server Db2 . Se un client si connette al database utilizzando un alias hostname, il certificato del server deve contenere questo alias nell'istruzione SAN o nella dichiarazione nome comune per la validazione del nome hostname per avere successo.

Ad esempio, se un client si connette a xyz.db2.example.com, il cui record CNAME nel server DNS punta a abc.db2.example.com, il certificato del server deve contenere l'alias in SAN per la validazione del nome host per avere successo.

Notare il valore nella sezione Extensions del certificato restituito:
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: xyz.db2.example.com

Signature Algorithm : SHA1WithRSASignature

Connessioni a più record A per indirizzi IP

Si applicano anche qui i consigli della sezione server multi - homed . In breve, se ci sono più record A nel DNS per un determinato server Db2 , il setup del certificato sul server dovrebbe contenere tutti i nomi host che i client utilizzano per collegarsi al server.

Connessioni ai distributori o ai balzi di carico

Quando un client Db2 si connette a un distributore o a un bilanciatore di carico, il traffico di rete dal client viene reindirizzato ad un server di database effettivo. Il certificato restituito dal server database di destinazione deve contenere il nome host del distributore o il bilanciatore di carico in SAN o Common Name per la validazione del nome hostname per avere successo.

Ad esempio, se il client si connette a xyz.balancer.com , che è il nome host di un programma di bilanciamento del carico che inoltra il traffico al server di destinazione reale, abc.db2.example.com, il certificato restituito dal server deve contenere xyz.balancer.com come valore SAN.

Notare il valore nella sezione Extensions del certificato restituito:
Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=ExampleCA
Subject : CN=none
Not Before : November 26, 2020 4:44:11 PM EST

Not After : November 27, 2021 4:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: xyz.balancer.com

Signature Algorithm : SHA1WithRSASignature