Representación de servidores en un certificado TLS

Es necesario crear certificados para los Db2 servidores a los que se conectan sus clientes. Estos certificados se generan a partir de solicitudes de firma de certificados (CSR) enviadas a entidades emisoras de certificados internas o de terceros para su firma, o se autofirman dentro de la organización. La validación de nombre de host en el cliente Db2 es satisfactoria si el nombre de host que el cliente ha configurado para conectar coincide con uno de los nombres de host presentes en el certificado de servidor. Existen varias opciones para representar una instancia de Db2 en un certificado.

Los ejemplos incluidos en esta sección se aplican a ambos y se crean utilizando IBM Global Security Kit (GSKit).

Utilización de un valor de nombre común (CN)

El campo Nombre común del nombre de asunto del certificado se puede utilizar para especificar el nombre de host del servidor. La validación de nombre de host se realizará correctamente si el nombre de host que el cliente ha configurado coincide con lo que está presente en el nombre común del certificado.

Si una entrada de nombre alternativo de asunto (SAN) está presente en el certificado, el nombre común se ignora.
Los nombres de host comodín (*) en el campo de nombre común están soportados al realizar la validación de nombre de host.

Aviso: De acuerdo con RFC 6125, utilice un nombre alternativo de asunto (SAN) en lugar de un nombre común para especificar el nombre de host del servidor en el certificado.

Por ejemplo, para crear un certificado con xyz.db2.example.com como nombre común, CN=xyz.db2.example.com debe estar presente como parte de la opción -dn en el mandato gsk8capicmd_64 -cert -create (para certificados autofirmados) o el mandato gsk8capicmd_64 -certreq (para CSR).

El ejemplo siguiente muestra cómo aparece el nombre común en el certificado generado:

Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=xyz.db2.example.com
Not Before : November 26, 2020 4:44:11 PM EST

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

Signature Algorithm : SHA1WithRSASignature

Utilización de nombres DNS como valores SAN

Se pueden especificar uno o más nombres de host en el certificado utilizando las entradas dNSName bajo la extensión SAN (Subject Alternate Name). La validación de nombre de host se realiza correctamente si el nombre de host al que se ha configurado el cliente para conectarse coincide con al menos una de las entradas dNSName . Estas entradas también se conocen como nombre DNS en algunos lugares.

Por ejemplo, para crear un certificado con xyz.db2.example.com en la SAN, incluya la opción -san_dnsname "xyz.db2.example.com" del mandato IBM Global Security Kit (GSKit)

El ejemplo siguiente muestra un certificado generado para incluir un único nombre DNS en la SAN.

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

Para crear un certificado con varios nombres DNS en la SAN, simplemente sepárelos con comas (-san_dnsname "xyz.db2.example.com,abc.db2.example2.com) en el mandato IBM Global Security Kit (GSKit) .

El ejemplo siguiente muestra un certificado generado para incluir varios nombres DNS en la SAN:

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
        dNSName: abc.db2.example2.com

Signature Algorithm : SHA1WithRSASignature

También puede configurar el certificado para incluir un valor de nombre común, así como un valor SAN que se utiliza para la validación de nombre de host.

Nota: Con esta configuración, el valor de nombre común se ignora cuando se realiza la validación de nombre de host, ya que se ha especificado una SAN en el certificado.

Para crear un certificado con xyz.db2.example.com en el nombre común y abc.db2.example2.com en la SAN, incluya CN=xyz.db2.example.com como parte de la opción -dn y "abc.db2.example2.com" como la opción -san_dnsname en el mandato IBM Global Security Kit (GSKit) .

El ejemplo siguiente muestra un certificado generado para incluir un valor de nombre común y un nombre DNS en la SAN:

Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=xyz.db2.example.com
Not Before : November 26, 2020 4:44:11 PM EST

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

Extensions
    subjectAlternativeName
        dNSName: abc.db2.example2.com

Signature Algorithm : SHA1WithRSASignature

Utilización de direcciones IP como valores SAN

Puede especificar una o más direcciones IP en el mandato IBM Global Security Kit (GSKit) utilizando el campo -san_ipaddr .

Como práctica recomendada, utilice nombres de host en lugar de direcciones IP en el certificado por las razones siguientes:

Una dirección IP no es necesariamente un identificador fiable para un servidor, debido a redes privadas, NAT, etc.
Según RFC 6125, menos del 1% de los certificados TLS emitidos los utilizan.
Se debe volver a crear un certificado cada vez que cambie la dirección IP de un servidor.

Sin embargo, si el cliente se conecta a un servidor utilizando una dirección IP (IPV4 o IPV6), esta dirección IP debe estar presente en el certificado del servidor para que la validación del nombre de host sea satisfactoria.

Nota: Cuando se utiliza una dirección IP para conectarse a un servidor, esta dirección no se resuelve en su nombre de host para que coincida con el certificado del servidor al realizar la validación de nombre de host.

Para crear un certificado con 127.0.0.1 en la SAN, incluya -san_ipaddr "127.0.0.1" en el mandato IBM Global Security Kit (GSKit) .

El ejemplo siguiente muestra un certificado generado para incluir una dirección IP en la SAN:

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
        iPAddress=127.0.0.1

Signature Algorithm : SHA1WithRSASignature

Para crear un certificado con varias direcciones IP en la SAN, simplemente sepárelas con comas (-san_ipaddr "127.0.0.1,127.0.0.2") en el mandato IBM Global Security Kit (GSKit) .

El ejemplo siguiente muestra un certificado generado para incluir varias direcciones IP en la SAN:

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
        iPAddress=127.0.0.1
        iPAddress=127.0.0.2

Signature Algorithm : SHA1WithRSASignature

Para crear un certificado con un valor de nombre común así como una dirección IP en la SAN, simplemente incluya las dos opciones (-dn "CN=xyz.db2.example.com,..." -san_ipaddr "127.0.0.1") en el mandato IBM Global Security Kit (GSKit) .

Nota: En este caso, el valor de nombre común se ignora al realizar la validación de nombre de host, ya que se ha especificado una SAN en el certificado.

El ejemplo siguiente muestra un certificado generado para incluir un nombre común y una dirección IP en la SAN:

Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=xyz.db2.example.com
Not Before : November 26, 2020 4:44:11 PM EST

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

Extensions
    subjectAlternativeName
        iPAddress=127.0.0.1

Signature Algorithm : SHA1WithRSASignature

Para crear un certificado con un nombre DNS y una dirección IP en la SAN, simplemente añada sentencias -san para ambas opciones (-san_dnsname "xyz.db2.example.com" -san_ipaddr "127.0.0.1",) en el mandato IBM Global Security Kit (GSKit) .

El ejemplo siguiente muestra un certificado generado para incluir un nombre DNS y una dirección IP en la SAN:

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
        iPAddress=127.0.0.1

Signature Algorithm : SHA1WithRSASignature

Utilización de comodines en nombres de host

Los certificados con el carácter comodín, *, como parte de los nombres de host están soportados al realizar la validación de nombre de host en el cliente. Sin embargo, tal como se especifica en RFC 6125, el cliente utiliza las reglas siguientes al comparar los nombres de host con los certificados comodín:

El carácter comodín sólo puede estar presente en la etiqueta situada más a la izquierda y sólo se puede incluir una vez.
El carácter comodín sólo se puede utilizar para que coincida con una sola etiqueta.
El carácter comodín no tiene que ser el único carácter de la etiqueta.
El carácter comodín puede coincidir con cero o más caracteres en la etiqueta.

Nota: La etiqueta de término de estas reglas hace referencia a la etiqueta de nombre de dominio. Las etiquetas se unen separadas por puntos para formar un nombre de host completo. Por ejemplo, xyz, db2, ejemploy com son las etiquetas que constituyen el nombre de host completo, xyz.db2.example.com.

Por ejemplo, se permite el siguiente uso de comodines:

"*.db2.example.com"
"f*.db2.example.com"

Sin embargo, los ejemplos siguientes no están permitidos, ya que el comodín se utiliza en etiquetas distintas de la etiqueta situada más a la izquierda en el nombre de host:

"foo.*.db2.example.com"
"*.db2.example.*.com"

Para crear un certificado con *.db2.example.com como nombre común, incluya CN=*.db2.example.com como parte del campo -dn en el mandato IBM Global Security Kit (GSKit)

Para crear un certificado con *.db2.example.com en la SAN, incluya -san_dnsname "*.db2.example.com" en el mandato IBM Global Security Kit (GSKit) . Esto permite a la SAN representar todos los nombres de host en el dominio de example.com .

El ejemplo siguiente muestra un certificado generado para incluir un único nombre de host comodín en la SAN:

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: *.db2.example.com

Signature Algorithm : SHA1WithRSASignature

Para crear un certificado con varios nombres de host comodín en la SAN, debe incluir ambos nombres de host, separados por una coma, en el campo -san_dnsname del mandato IBM Global Security Kit (GSKit) .

El ejemplo siguiente muestra un certificado generado para incluir varios nombres de host comodín:

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: *.db2.example.com
        dNSName: a*.db2.example2.com

Signature Algorithm : SHA1WithRSASignature

Para crear un certificado con una combinación de nombres de host y nombres de host comodín, simplemente incluya ambos en el campo -san_dnsname del mandato IBM Global Security Kit (GSKit) .

-san_dnsname "xyz.db2.example.com,*.db2.example2.com"

Utilización de nombres de host cortos

Un nombre de host corto es esencialmente la primera etiqueta del nombre de dominio completo (xyz.db2.example.com). Cuando se configura un cliente de Db2 para conectarse a un servidor utilizando un nombre de host corto, este nombre de host no se resuelve en un nombre de dominio completo cuando se realiza la validación de nombre de host. El razonamiento es que averiguar qué nombre de dominio añadir a este nombre de host corto depende del contenido del archivo /etc/resolv.conf . El cliente no debe necesariamente depositar su confianza en el archivo resolv.conf , ya que es posible que este archivo sea modificado por un actor remoto a través de DHCP.

Este es también el método estándar de la industria de validación de nombre de host.

Debido a esto, no se recomienda el uso de nombres de host cortos al configurar los clientes de Db2 para la validación de nombre de host. Sin embargo, su empresa puede requerir que utilice un nombre de host corto al configurar la información de conexión del servidor en el cliente. Cuando este es el caso, el certificado devuelto por el servidor durante el reconocimiento TLS también debe contener este nombre de host corto.

Por ejemplo, si el cliente se conecta utilizando una serie de conexión que se parece a Hostname=xyz;Security=SSL;SSLClientHostnameValidation=Basic;Database=…, el certificado devuelto por el servidor debería tener un aspecto similar al siguiente.

Key Size : 2048
Version : X509 V3
Serial : xxx
Issuer : CN=Example Enterprise CA
Subject : CN=xyz.db2.example.com
Not Before : November 26, 20204:44:11 PM EST

Not After : November 27, 20214:44:11 PM EST

Extensions
    subjectAlternativeName
        dNSName: xyz

Signature Algorithm : SHA1WithRSASignature