La función de tabla ADMIN_GET_TLS_CERT

1. Por qué TLS es importante en Db2

En muchos entornos Db2, TLS ya no es opcional. Protege:

credenciales durante la autenticación del cliente
datos de la aplicación en tránsito
conexiones administrativas en redes compartidas
canales de replicación e integración que cruzan fronteras de confianza

Sin TLS, una conexión TCP a Db2 puede exponer nombres de usuario, contraseñas y tráfico de aplicación a cualquier persona con visibilidad de red. Incluso en redes internas, eso suele ser inaceptable.

Db2 sigue usando muchos nombres de parámetros que contienen SSL, pero operativamente el tema es ahora TLS. En la práctica, cuando un administrador Db2 dice "activar SSL en Db2", el trabajo suele consistir en configurar un listener con capacidad TLS, asignar la etiqueta correcta del certificado y demostrar qué cadena de certificados está usando realmente Db2.

Ese último punto antes era incómodo. Era posible inspeccionar keystores con herramientas GSKit y probar conexiones desde el lado del cliente, pero no había una interfaz SQL simple en Db2 que dijera qué cadena de certificados estaba presentando realmente el servidor.

Ahí es exactamente donde ayuda ADMIN_GET_TLS_CERT. En Db2 12.1, esta table function devuelve información sobre la cadena de certificados para contextos TLS como conexiones cliente/servidor, HADR y KMIP. Esto hace que la revisión de certificados, la verificación de expiración y la validación operativa sean mucho más fáciles de integrar en la administración normal basada en SQL.

2. Dónde aparece TLS en Db2

En entornos Db2, TLS aparece muchas veces en más de un lugar:

CLIENT_SERVER para conexiones de clientes al listener
HADR para la comunicación entre primary y standby
KMIP para la comunicación con un gestor externo de claves

Esta distinción importa porque ADMIN_GET_TLS_CERT informa explícitamente el contexto de uso, en lugar de tratar todos los certificados como si sirvieran al mismo propósito.

Para TLS cliente/servidor, las definiciones a nivel de instancia que más importan son:

Configuración	Finalidad
`DB2COMM`	Activa el protocolo de comunicación. Para TLS, `SSL` debe estar incluido.
`SSL_SVCENAME`	Define el nombre de servicio o el puerto TCP usado por el listener TLS.
`SSL_SVR_KEYDB`	Apunta a la key database del servidor.
`SSL_SVR_STASH`	Apunta al stash file de la contraseña de la key database.
`SSL_SVR_LABEL`	Identifica la etiqueta del certificado del servidor dentro de la key database.

Para otros contextos TLS, Db2 también usa etiquetas como:

HADR_SSL_LABEL
SSL_KMIP_CLIENT_CERTIFICATE_LABEL

3. Qué devuelve `ADMIN_GET_TLS_CERT`

IBM documenta la función como:

ADMIN_GET_TLS_CERT(member, full_list)

Importan dos parámetros:

member
- -1 significa el miembro actual de la base de datos
- -2 significa todos los miembros activos
full_list
- 0 devuelve solo el certificado endpoint o del servidor
- 1 devuelve la cadena completa, incluyendo endpoint, intermedios y certificado signer/root

Las columnas devueltas son operativamente útiles porque cubren no solo la etiqueta, sino también la forma y la calidad del certificado:

USAGE
LABEL
CERT_TYPE
CERT_SIGNATURE_ALG
PUBKEY_TYPE
PUBKEY_SIZE
FINGERPRINT
SERIAL_NUMBER
NOT_BEFORE
NOT_AFTER
ISSUER_DN
SUBJECT_DN
SUBJECT_ALTERNATE_NAMES
KEYSTORE_LOCATION

Esto significa que puede usar SQL para responder a preguntas como:

¿Qué cadena de certificados está usando Db2 en este momento para TLS cliente/servidor?
¿El certificado endpoint caduca pronto?
¿El servidor sigue usando un tamaño de clave débil o un algoritmo de firma desactualizado?
¿Los SAN son los que esperamos para el hostname de producción?
¿Qué ubicación de keystore está sirviendo la cadena en un miembro determinado?

4. Primeras consultas de inspección

Comience solo por el certificado endpoint de cliente/servidor:

SELECT
  MEMBER,
  USAGE,
  LABEL,
  CERT_TYPE,
  NOT_BEFORE,
  NOT_AFTER,
  SUBJECT_DN,
  SUBJECT_ALTERNATE_NAMES
FROM TABLE(ADMIN_GET_TLS_CERT(-1, 0)) AS T
WHERE USAGE = 'CLIENT_SERVER';

Esta es la forma más rápida de confirmar qué certificado endpoint está usando Db2 para conexiones TLS entrantes.

Después inspeccione la cadena completa:

SELECT
  MEMBER,
  USAGE,
  LABEL,
  CERT_TYPE,
  ISSUER_DN,
  SUBJECT_DN,
  NOT_AFTER
FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
WHERE USAGE = 'CLIENT_SERVER'
ORDER BY NOT_AFTER;

Esto facilita bastante la revisión de expiración, porque permite ver inmediatamente si es el endpoint o un certificado signer el que se acerca primero a la fecha límite.

5. Consultas útiles de administración

Encontrar certificados que caducan pronto:

SELECT
  USAGE,
  LABEL,
  CERT_TYPE,
  NOT_AFTER,
  DAYS(NOT_AFTER) - DAYS(CURRENT TIMESTAMP) AS DAYS_LEFT
FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
WHERE NOT_AFTER < CURRENT TIMESTAMP + 90 DAYS
ORDER BY NOT_AFTER;

Verificar tamaños de clave y algoritmos de firma:

SELECT
  USAGE,
  LABEL,
  CERT_TYPE,
  PUBKEY_TYPE,
  PUBKEY_SIZE,
  CERT_SIGNATURE_ALG
FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
ORDER BY USAGE, CERT_TYPE, LABEL;

Verificar todos los miembros activos:

SELECT
  MEMBER,
  USAGE,
  LABEL,
  CERT_TYPE,
  KEYSTORE_LOCATION,
  NOT_AFTER
FROM TABLE(ADMIN_GET_TLS_CERT(-2, 1)) AS T
ORDER BY MEMBER, USAGE, CERT_TYPE, LABEL;

6. Visibilidad sobre HADR y KMIP

Como USAGE identifica el contexto TLS, la misma función puede revelar si Db2 está usando certificados diferentes para:

CLIENT_SERVER
HADR
KMIP

Ejemplo:

SELECT
  USAGE,
  LABEL,
  CERT_TYPE,
  SUBJECT_DN,
  NOT_AFTER
FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
ORDER BY USAGE, CERT_TYPE, LABEL;

Para comunicación HADR, la función devuelve información de la cadena de certificados solo para el servidor al que está actualmente conectado. Si quiere inspeccionar ambos lados de un par HADR, conéctese y ejecute la consulta en cada servidor, en lugar de asumir que la salida local representa al socio remoto.

7. Errores comunes que esta función ayuda a exponer

ADMIN_GET_TLS_CERT no resuelve todos los problemas de TLS, pero elimina mucha ambigüedad. Es particularmente útil cuando se diagnostican estas situaciones:

Etiqueta incorrecta configurada

El keystore contiene el certificado correcto, pero SSL_SVR_LABEL apunta a otro. La función muestra inmediatamente la etiqueta activa y el subject del certificado.

Cadena incompleta

El certificado endpoint está presente, pero falta el certificado intermedio necesario. Con full_list = 1, puede ver si la cadena signer esperada está realmente disponible.

Sorpresas de expiración

Muchas veces el certificado endpoint sigue siendo válido mientras un signer intermedio está a punto de expirar. Ordenar por NOT_AFTER expone esto más rápidamente que una inspección manual del keystore.

SAN incompatible

Los clientes fallan la validación del hostname porque los SAN del certificado no corresponden al hostname de la cadena de conexión. La columna SUBJECT_ALTERNATE_NAMES permite verificarlo directamente vía SQL.

Configuración inconsistente entre miembros

En sistemas multi-member, un miembro puede haber sido actualizado y otro no. Hacer la consulta con member = -2 hace visible esa deriva.

8. Checklist práctico de validación

Cuando hace deploy o rotación de un certificado TLS en Db2, la secuencia limpia de validación es:

Confirmar que la key database contiene la etiqueta esperada.
Confirmar que la DBM CFG de Db2 apunta a la key database, el stash file, el listener y la etiqueta esperados.
Reiniciar la instancia si el cambio lo exige.
Ejecutar una prueba real de conexión TLS desde un cliente.
Ejecutar ADMIN_GET_TLS_CERT(-1, 0) para confirmar el certificado endpoint.
Ejecutar ADMIN_GET_TLS_CERT(-1, 1) para confirmar la cadena completa.
Verificar NOT_AFTER, PUBKEY_SIZE y SUBJECT_ALTERNATE_NAMES.
En entornos multi-member o HADR, repetir la validación en todos los servidores relevantes.

Esta combinación es mucho más fuerte que confiar solo en una prueba de conexión o solo en la inspección del keystore.

Los comandos para hacer ese trabajo se dejan deliberadamente fuera de la parte teórica de este artículo. La parte hands-on queda confinada al laboratorio Docker de abajo.

9. Un laboratorio Docker en un único host

La segunda mitad de este artículo transforma las ideas anteriores en un laboratorio que puede ejecutarse con una máquina Linux y la imagen Db2 Community Edition.

El objetivo es deliberadamente limitado:

Iniciar un contenedor Db2
Crear un certificado simple de servidor para el laboratorio
Activar un listener TLS en Db2
Validar el listener desde el host Linux
Inspeccionar el certificado activo de Db2 con ADMIN_GET_TLS_CERT

9.1 Requisitos previos

Va a necesitar:

una máquina Linux
Docker Engine y el plugin Docker Compose
al menos 8 GB de RAM disponibles para el laboratorio
acceso shell en el host
openssl

Para Db2 12.1.5.0, hay un detalle práctico: el contenedor base expone gsk9certutil_64, pero en algunos entornos el runtime ICU necesario para esa herramienta no está inmediatamente disponible. Vamos a construir una pequeña imagen derivada que añade las bibliotecas runtime necesarias antes de iniciar Db2.

El laboratorio usa esta imagen base:

icr.io/db2_community/db2:12.1.5.0

9.2 Crear el directorio del laboratorio

Cree las carpetas necesarias en el host:

mkdir db2-tls-docker-lab
cd db2-tls-docker-lab
mkdir -p host-tls
mkdir -p host-tls/db2server
chmod 777 host-tls host-tls/db2server

Mantenga los archivos del laboratorio exactamente con esta estructura:

db2-tls-docker-lab/
|- Dockerfile
|- docker-compose.yml
`- host-tls/
   `- db2server/

Esto importa porque el archivo de docker compose usa un bind mount relativo:

- ./host-tls:/host-tls

Por eso, docker-compose.yml debe permanecer en la raíz del laboratorio, no dentro de host-tls/.

9.3 Construir una pequeña imagen derivada

Comience por hacer pull de la imagen explícitamente:

docker pull icr.io/db2_community/db2:12.1.5.0
docker images | grep db2_community

Establezca una sesión de vi

vi Dockerfile

y pegue el siguiente contenido. Después salga de la sesión guardando (:wq):

FROM icr.io/db2_community/db2:12.1.5.0

USER root

RUN if command -v microdnf >/dev/null 2>&1; then \
      microdnf install -y libicu && microdnf clean all; \
    elif command -v dnf >/dev/null 2>&1; then \
      dnf install -y libicu && dnf clean all; \
    elif command -v yum >/dev/null 2>&1; then \
      yum install -y libicu && yum clean all; \
    else \
      echo "No supported package manager found in container image" >&2; \
      exit 1; \
    fi

Construya la imagen:

docker build -t pyxis-db2-tls:12.1.5.0 .

9.4 Crear `docker-compose.yml`

Ejecute esto para crear el archivo de docker compose:

cat > docker-compose.yml <<'EOF'
services:
  db2tls:
    image: pyxis-db2-tls:12.1.5.0
    container_name: db2tls
    privileged: true
    hostname: db2tls
    environment:
      LICENSE: accept
      DB2INST1_PASSWORD: passw0rd
    ports:
      - "50000:50000"
      - "50001:50001"
    volumes:
      - db2tls_data:/database
      - ./host-tls:/host-tls
    healthcheck:
      test: ["CMD", "su", "-", "db2inst1", "-c", "db2pd -inst"]
      interval: 30s
      timeout: 10s
      retries: 15
      start_period: 600s

volumes:
  db2tls_data:
    name: db2tls_data
EOF

9.5 Iniciar el contenedor

docker compose up -d

Si ya existe un contenedor db2tls creado a partir de una definición de imagen más antigua, fuerce la recreación:

docker compose up -d --force-recreate

Verifique el estado del contenedor:

docker ps

La inicialización de Db2 tarda tiempo en el primer arranque. Repita el comando hasta encontrar el contenedor en estado healthy.

9.6 Confirmar Db2 dentro del contenedor

Ejecute una comprobación simple de la instancia:

docker exec -it db2tls su - db2inst1 -c "db2level"

Cree una pequeña base de datos para usar en el laboratorio:

docker exec -it db2tls su - db2inst1 -c "db2 create database TLSLAB"

9.7 Crear un certificado self-signed de servidor

La carpeta de trabajo TLS ya se creó en el host antes de que arrancara el contenedor:

Para Db2 12.1.5.0, use las rutas explícitas de la herramienta GSKit 9 y de sus bibliotecas runtime:

binario: /opt/ibm/db2/V12.1/gskit/bin/gsk9certutil_64
library path: /opt/ibm/db2/V12.1/lib64/gskit_db2

Exporte esos valores antes de usar la CLI GSKit:

docker exec -it db2tls bash -lc '
export PATH=/opt/ibm/db2/V12.1/gskit/bin:$PATH
export LD_LIBRARY_PATH=/opt/ibm/db2/V12.1/lib64/gskit_db2:$LD_LIBRARY_PATH
gsk9certutil_64 -help
'

Cree la key database y el stash file:

docker exec -it db2tls bash -lc '
export PATH=/opt/ibm/db2/V12.1/gskit/bin:$PATH
export LD_LIBRARY_PATH=/opt/ibm/db2/V12.1/lib64/gskit_db2:$LD_LIBRARY_PATH
gsk9certutil_64 -keydb -create \
  -db /host-tls/db2server/server.kdb \
  -pw Db2Tls123! \
  -stash
'

Cree un certificado self-signed de servidor en esa key database:

docker exec -it db2tls bash -lc '
export PATH=/opt/ibm/db2/V12.1/gskit/bin:$PATH
export LD_LIBRARY_PATH=/opt/ibm/db2/V12.1/lib64/gskit_db2:$LD_LIBRARY_PATH
gsk9certutil_64 -cert -create \
  -db /host-tls/db2server/server.kdb \
  -pw Db2Tls123! \
  -label db2server \
  -dn "CN=db2tls,O=Pyxis,C=PT" \
  -default_cert yes \
  -expire 365 \
  -size 2048 \
  -sig_alg SHA256WithRSA
'

Confirme que la etiqueta existe:

docker exec -it db2tls bash -lc '
export PATH=/opt/ibm/db2/V12.1/gskit/bin:$PATH
export LD_LIBRARY_PATH=/opt/ibm/db2/V12.1/lib64/gskit_db2:$LD_LIBRARY_PATH
gsk9certutil_64 -cert -list \
  -db /host-tls/db2server/server.kdb \
  -pw Db2Tls123!
'

Como estos comandos se ejecutan a través de docker exec ... bash -lc, los archivos generados pueden acabar perteneciendo a root dentro del contenedor. Db2 arranca el listener SSL como db2inst1, por eso corrija la ownership antes de configurar TLS:

docker exec -it db2tls bash -lc '
chown db2inst1:db2iadm1 /host-tls/db2server/server.*
chmod 600 /host-tls/db2server/server.*
ls -l /host-tls/db2server
'

9.8 Configurar Db2 para TLS en el contenedor

Active el protocolo SSL/TLS a nivel de instancia:

docker exec -it db2tls su - db2inst1 -c "db2set DB2COMM=SSL"

Configure el listener TLS y las definiciones del certificado:

docker exec -it db2tls su - db2inst1 -c "db2 update dbm cfg using SSL_SVCENAME 50001"
docker exec -it db2tls su - db2inst1 -c "db2 update dbm cfg using SSL_SVR_KEYDB /host-tls/db2server/server.kdb"
docker exec -it db2tls su - db2inst1 -c "db2 update dbm cfg using SSL_SVR_STASH /host-tls/db2server/server.sth"
docker exec -it db2tls su - db2inst1 -c "db2 update dbm cfg using SSL_SVR_LABEL db2server"

Reinicie la instancia para que los cambios queden activos:

docker exec -it db2tls su - db2inst1 -c "db2stop force"
docker exec -it db2tls su - db2inst1 -c "db2start"

Confirme los valores activos:

docker exec -it db2tls su - db2inst1 -c '
db2 get dbm cfg | egrep -i "SSL_SVCENAME|SSL_SVR_KEYDB|SSL_SVR_STASH|SSL_SVR_LABEL"
'

docker exec -it db2tls su - db2inst1 -c "db2set -all | grep DB2COMM"

Ahora debería ver:

DB2COMM=SSL
SSL_SVCENAME definido como 50001
la ruta de la key database bajo /host-tls/db2server
SSL_SVR_LABEL definido como db2server

9.9 Validar el listener TLS desde el host Linux

Use openssl s_client:

openssl s_client -connect localhost:50001 -showcerts </dev/null

Lo que quiere ver:

un handshake TLS completado con éxito
el subject del certificado visible en la salida
las fechas de validez del certificado

Como este es un certificado self-signed de laboratorio, OpenSSL normalmente se quejará del trust si le pide validación contra una cadena PKI pública. Eso es esperado en este laboratorio.

Si openssl devuelve no peer certificate available y el handshake lee 0 bytes, el puerto TCP está accesible, pero Db2 todavía no está presentando realmente un certificado TLS. En ese caso, verifique por este orden:

confirmar que la key database contiene realmente la etiqueta db2server
confirmar que la key database y el stash file están presentes dentro del contenedor
reiniciar de nuevo Db2 después de que existan los archivos del certificado
confirmar que Db2 está escuchando en el puerto TLS dentro del contenedor
confirmar que Docker sigue publicando el puerto en el host

Los comandos prácticos son:

docker exec -it db2tls bash -lc '
export PATH=/opt/ibm/db2/V12.1/gskit/bin:$PATH
export LD_LIBRARY_PATH=/opt/ibm/db2/V12.1/lib64/gskit_db2:$LD_LIBRARY_PATH
gsk9certutil_64 -cert -list \
  -db /host-tls/db2server/server.kdb \
  -pw Db2Tls123!
'

docker exec -it db2tls bash -lc 'ls -l /host-tls/db2server'

docker exec -it db2tls su - db2inst1 -c "db2stop force"
docker exec -it db2tls su - db2inst1 -c "db2start"

docker exec -it db2tls bash -lc 'ss -ltnp | grep 50001 || netstat -ltn 2>/dev/null | grep 50001'

docker port db2tls

Si la configuración del gestor Db2 ya muestra:

DB2COMM=SSL
SSL_SVCENAME=50001
SSL_SVR_KEYDB=/host-tls/db2server/server.kdb
SSL_SVR_STASH=/host-tls/db2server/server.sth
SSL_SVR_LABEL=db2server

entonces la causa de fallo suele ser una de estas:

la key database se creó sin la etiqueta esperada
la key database o el stash file no existen en el directorio montado
la key database o el stash file siguen perteneciendo a root y no pueden ser leídos por db2inst1
la instancia se reinició antes de que existieran los archivos y no volvió a reiniciarse después
Db2 no pudo hacer bind del listener TLS, aunque la configuración haya sido aceptada

9.10 Usar `ADMIN_GET_TLS_CERT` dentro del laboratorio

Empiece por el certificado final (endpoint):

docker exec -it db2tls su - db2inst1 -c '
db2 connect to TLSLAB &&
db2 -x "SELECT
          '\''member='\'' || RTRIM(CHAR(MEMBER)) ||
          '\'' | usage='\'' || USAGE ||
          '\'' | label='\'' || LABEL ||
          '\'' | cert_type='\'' || CERT_TYPE ||
          '\'' | not_before='\'' || VARCHAR_FORMAT(NOT_BEFORE, '\''YYYY-MM-DD HH24:MI:SS'\'') ||
          '\'' | not_after='\'' || VARCHAR_FORMAT(NOT_AFTER, '\''YYYY-MM-DD HH24:MI:SS'\'') ||
          '\'' | subject='\'' || SUBJECT_DN ||
          '\'' | keystore='\'' || KEYSTORE_LOCATION
      FROM TABLE(ADMIN_GET_TLS_CERT(-1, 0)) AS T
      WHERE USAGE = '\''CLIENT_SERVER'\''" &&
db2 connect reset
'

Para visualizar la cadena completa, ejecute:

docker exec -it db2tls su - db2inst1 -c '
db2 connect to TLSLAB &&
db2 -x "SELECT
          '\''member='\'' || RTRIM(CHAR(MEMBER)) ||
          '\'' | usage='\'' || USAGE ||
          '\'' | label='\'' || LABEL ||
          '\'' | cert_type='\'' || CERT_TYPE ||
          '\'' | not_after='\'' || VARCHAR_FORMAT(NOT_AFTER, '\''YYYY-MM-DD HH24:MI:SS'\'') ||
          '\'' | issuer='\'' || ISSUER_DN ||
          '\'' | subject='\'' || SUBJECT_DN
      FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
      WHERE USAGE = '\''CLIENT_SERVER'\''
      ORDER BY NOT_AFTER" &&
db2 connect reset
'

En este laboratorio, la cadena debe contener un único certificado: el propio certificado endpoint self-signed. Eso es perfectamente normal. El objetivo es confirmar que:

la función funciona
el uso se informa como CLIENT_SERVER
la etiqueta es la configurada en SSL_SVR_LABEL
la marca temporal de expiración es visible en SQL

Mostrar fingerprints de los certificados:

docker exec -it db2tls su - db2inst1 -c '
db2 connect to TLSLAB &&
db2 -x "SELECT
          '\''label='\'' || LABEL ||
          '\'' | cert_type='\'' || CERT_TYPE ||
          '\'' | fingerprint='\'' || FINGERPRINT
      FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
      WHERE USAGE = '\''CLIENT_SERVER'\''" &&
db2 connect reset
'

Mostrar tiempo de vida restante del certificado:

docker exec -it db2tls su - db2inst1 -c '
db2 connect to TLSLAB &&
db2 -x "SELECT
          '\''label='\'' || LABEL ||
          '\'' | cert_type='\'' || CERT_TYPE ||
          '\'' | not_after='\'' || VARCHAR_FORMAT(NOT_AFTER, '\''YYYY-MM-DD HH24:MI:SS'\'') ||
          '\'' | days_left='\'' || RTRIM(CHAR(DAYS(NOT_AFTER) - DAYS(CURRENT TIMESTAMP)))
      FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
      WHERE USAGE = '\''CLIENT_SERVER'\''
      ORDER BY NOT_AFTER" &&
db2 connect reset
'

Mostrar tamaño de clave, algoritmo de firma y SAN en una sola consulta:

docker exec -it db2tls su - db2inst1 -c '
db2 connect to TLSLAB &&
db2 -x "SELECT
          '\''label='\'' || LABEL ||
          '\'' | cert_type='\'' || CERT_TYPE ||
          '\'' | key='\'' || PUBKEY_TYPE || '\''/'\'' || RTRIM(CHAR(PUBKEY_SIZE)) ||
          '\'' | sig_alg='\'' || CERT_SIGNATURE_ALG ||
          '\'' | sans='\'' || COALESCE(SUBJECT_ALTERNATE_NAMES, '\''<none>'\'')
      FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
      WHERE USAGE = '\''CLIENT_SERVER'\''
      ORDER BY CERT_TYPE, LABEL" &&
db2 connect reset
'

Mostrar todos los contextos TLS visibles en la instancia:

docker exec -it db2tls su - db2inst1 -c '
db2 connect to TLSLAB &&
db2 -x "SELECT
          '\''usage='\'' || USAGE ||
          '\'' | label='\'' || LABEL ||
          '\'' | cert_type='\'' || CERT_TYPE ||
          '\'' | not_after='\'' || VARCHAR_FORMAT(NOT_AFTER, '\''YYYY-MM-DD HH24:MI:SS'\'')
      FROM TABLE(ADMIN_GET_TLS_CERT(-1, 1)) AS T
      ORDER BY USAGE, CERT_TYPE, LABEL" &&
db2 connect reset
'

10. Qué aborda este enfoque

La parte teórica de este artículo explica lo que Db2 espera:

el listener correcto
la ruta correcta de la key database
el stash file correcto
la etiqueta correcta del certificado
el contexto de uso correcto en ADMIN_GET_TLS_CERT

El laboratorio en Docker demuestra estas ideas end-to-end en un entorno reproducible.

Con solo un host Linux y un contenedor Db2, puede validar la secuencia operativa completa:

crear una key database y un certificado de servidor
activar un listener TLS en Db2
confirmar el listener desde el host con OpenSSL
inspeccionar el certificado activo desde Db2 con ADMIN_GET_TLS_CERT

Esto es suficiente para hacer concretos varios conceptos importantes de TLS en Db2:

la diferencia entre tener simplemente un archivo de certificado y realmente vincularlo a Db2
la importancia de SSL_SVR_LABEL
la utilidad de la inspección de certificados vía SQL después de un cambio

11. Observaciones finales

La configuración TLS en Db2 normalmente no es difícil, pero es fácil equivocarse en detalles sutiles. Los modos de fallo más comunes son incompatibilidades operativas:

etiqueta incorrecta
hostname incorrecto
cadena signer incorrecta
miembro incorrecto
ownership incorrecta de los archivos
suposición incorrecta sobre lo que Db2 está sirviendo realmente

ADMIN_GET_TLS_CERT cierra una laguna importante de visibilidad porque permite inspeccionar la cadena de certificados activa con SQL, usando las mismas herramientas y flujos administrativos que los equipos Db2 ya utilizan para monitorización y validación.

Si ya usa TLS en Db2, merece la pena añadir esta función a las comprobaciones normales posteriores al cambio. Si está a punto de introducir TLS, merece la pena incluirla desde el primer día, para que la validación de certificados pase a formar parte de la operación normal de Db2 en lugar de una investigación manual excepcional.

Menú

La función de tabla ADMIN_GET_TLS_CERT

1. Por qué TLS es importante en Db2

2. Dónde aparece TLS en Db2

3. Qué devuelve `ADMIN_GET_TLS_CERT`

4. Primeras consultas de inspección

5. Consultas útiles de administración

6. Visibilidad sobre HADR y KMIP

7. Errores comunes que esta función ayuda a exponer

Etiqueta incorrecta configurada

Cadena incompleta

Sorpresas de expiración

SAN incompatible

Configuración inconsistente entre miembros

8. Checklist práctico de validación

9. Un laboratorio Docker en un único host

9.1 Requisitos previos

9.2 Crear el directorio del laboratorio

9.3 Construir una pequeña imagen derivada

9.4 Crear `docker-compose.yml`

9.5 Iniciar el contenedor

9.6 Confirmar Db2 dentro del contenedor

9.7 Crear un certificado self-signed de servidor

9.8 Configurar Db2 para TLS en el contenedor

9.9 Validar el listener TLS desde el host Linux

9.10 Usar `ADMIN_GET_TLS_CERT` dentro del laboratorio

10. Qué aborda este enfoque

11. Observaciones finales

Más en esta área

La función de tabla ADMIN_GET_TLS_CERT

1. Por qué TLS es importante en Db2

2. Dónde aparece TLS en Db2

3. Qué devuelve ADMIN_GET_TLS_CERT

4. Primeras consultas de inspección

5. Consultas útiles de administración

6. Visibilidad sobre HADR y KMIP

7. Errores comunes que esta función ayuda a exponer

Etiqueta incorrecta configurada

Cadena incompleta

Sorpresas de expiración

SAN incompatible

Configuración inconsistente entre miembros

8. Checklist práctico de validación

9. Un laboratorio Docker en un único host

9.1 Requisitos previos

9.2 Crear el directorio del laboratorio

9.3 Construir una pequeña imagen derivada

9.4 Crear docker-compose.yml

9.5 Iniciar el contenedor

9.6 Confirmar Db2 dentro del contenedor

9.7 Crear un certificado self-signed de servidor

9.8 Configurar Db2 para TLS en el contenedor

9.9 Validar el listener TLS desde el host Linux

9.10 Usar ADMIN_GET_TLS_CERT dentro del laboratorio

10. Qué aborda este enfoque

11. Observaciones finales

Más en esta área

Artículos de Db2 LUW

3. Qué devuelve `ADMIN_GET_TLS_CERT`

9.4 Crear `docker-compose.yml`

9.10 Usar `ADMIN_GET_TLS_CERT` dentro del laboratorio