“A função de tabela ADMIN_GET_TLS_CERT"

1. Porque é que o TLS é importante no Db2

Em muitos ambientes Db2, o TLS já não é opcional. Protege:

credenciais durante a autenticação do cliente
dados da aplicação em trânsito
ligações administrativas em redes partilhadas
canais de replicação e integração que atravessam fronteiras de confiança

Sem TLS, uma ligação TCP ao Db2 pode expor nomes de utilizador, palavras-passe e tráfego aplicacional a qualquer pessoa com visibilidade de rede. Mesmo em redes internas, isso é muitas vezes inaceitável.

O Db2 continua a usar muitos nomes de parâmetros que contêm SSL, mas operacionalmente o tema é agora TLS. Na prática, quando um administrador Db2 diz "ativar SSL no Db2", o trabalho costuma passar por configurar um listener com capacidade TLS, atribuir a etiqueta correta do certificado e provar que cadeia de certificados o Db2 está efetivamente a usar.

Esse último ponto costumava ser incómodo. Era possível inspecionar keystores com ferramentas GSKit e testar ligações do lado do cliente, mas não havia uma interface SQL simples no Db2 que dissesse que cadeia de certificados o servidor estava realmente a apresentar.

É exatamente aí que ADMIN_GET_TLS_CERT ajuda. No Db2 12.1, esta table function devolve informação sobre a cadeia de certificados para contextos TLS como ligações cliente/servidor, HADR e KMIP. Isto torna a revisão de certificados, a verificação de expiração e a validação operacional muito mais fáceis de integrar na administração normal baseada em SQL.

2. Onde o TLS aparece no Db2

Em ambientes Db2, o TLS aparece muitas vezes em mais do que um sítio:

CLIENT_SERVER para ligações de clientes ao listener
HADR para comunicação entre primary e standby
KMIP para comunicação com um gestor externo de chaves

Esta distinção importa porque ADMIN_GET_TLS_CERT reporta explicitamente o contexto de uso, em vez de tratar todos os certificados como se servissem o mesmo propósito.

Para TLS cliente/servidor, as definições ao nível da instância que mais importam são:

Definição	Finalidade
`DB2COMM`	Ativa o protocolo de comunicação. Para TLS, `SSL` tem de estar incluído.
`SSL_SVCENAME`	Define o nome de serviço ou a porta TCP usada pelo listener TLS.
`SSL_SVR_KEYDB`	Aponta para a key database do servidor.
`SSL_SVR_STASH`	Aponta para o ficheiro stash da password da key database.
`SSL_SVR_LABEL`	Identifica a etiqueta do certificado do servidor dentro da key database.

Para outros contextos TLS, o Db2 também usa etiquetas como:

HADR_SSL_LABEL
SSL_KMIP_CLIENT_CERTIFICATE_LABEL

3. O que devolve `ADMIN_GET_TLS_CERT`

A IBM documenta a função como:

ADMIN_GET_TLS_CERT(member, full_list)

Dois parâmetros importam:

member
- -1 significa o membro atual da base de dados
- -2 significa todos os membros ativos
full_list
- 0 devolve apenas o certificado endpoint ou do servidor
- 1 devolve a cadeia completa, incluindo endpoint, intermédios e certificado signer/root

As colunas devolvidas são operacionalmente úteis porque cobrem não apenas a etiqueta, mas também a forma e a qualidade do 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

Isto significa que pode usar SQL para responder a perguntas como:

Que cadeia de certificados está o Db2 a usar neste momento para TLS cliente/servidor?
O certificado endpoint expira em breve?
O servidor ainda está a usar um tamanho de chave fraco ou um algoritmo de assinatura desatualizado?
Os SANs são os que esperamos para o hostname de produção?
Que localização de keystore está a servir a cadeia num determinado membro?

4. Primeiras queries de inspeção

Comece apenas pelo 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 é a forma mais rápida de confirmar que certificado endpoint o Db2 está a usar para ligações TLS de entrada.

Depois inspecione a cadeia 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;

Isto facilita bastante a revisão de expiração, porque permite ver imediatamente se é o endpoint ou um certificado signer que se aproxima primeiro da data-limite.

5. Queries úteis de administração

Encontrar certificados que expiram em breve:

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 tamanhos de chave e algoritmos de assinatura:

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 os membros ativos:

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. Visibilidade sobre HADR e KMIP

Como USAGE identifica o contexto TLS, a mesma função pode revelar se o Db2 está a usar certificados diferentes para:

CLIENT_SERVER
HADR
KMIP

Exemplo:

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 comunicação HADR, a função devolve informação da cadeia de certificados apenas para o servidor a que está atualmente ligado. Se quiser inspecionar ambos os lados de um par HADR, ligue-se e execute a query em cada servidor, em vez de assumir que a saída local representa o parceiro remoto.

7. Erros comuns que esta função ajuda a expor

ADMIN_GET_TLS_CERT não resolve todos os problemas de TLS, mas remove muita ambiguidade. É particularmente útil quando se diagnosticam estas situações:

Etiqueta errada configurada

O keystore contém o certificado correto, mas SSL_SVR_LABEL aponta para outro. A função mostra imediatamente a etiqueta ativa e o subject do certificado.

Cadeia incompleta

O certificado endpoint está presente, mas o certificado intermédio necessário está em falta. Com full_list = 1, pode ver se a cadeia signer esperada está realmente disponível.

Surpresas de expiração

Muitas vezes o certificado endpoint ainda é válido enquanto um signer intermédio está prestes a expirar. Ordenar por NOT_AFTER expõe isso mais rapidamente do que uma inspeção manual do keystore.

SAN incompatível

Os clientes falham a validação do hostname porque os SANs do certificado não correspondem ao hostname da string de ligação. A coluna SUBJECT_ALTERNATE_NAMES permite verificar isso diretamente via SQL.

Configuração inconsistente entre membros

Em sistemas multi-member, um membro pode ter sido atualizado e outro não. Fazer a query com member = -2 torna esse drift visível.

8. Checklist prático de validação

Quando faz deploy ou rotação de um certificado TLS no Db2, a sequência limpa de validação é:

Confirmar que a key database contém a etiqueta esperada.
Confirmar que a DBM CFG do Db2 aponta para a key database, o stash file, o listener e a etiqueta esperados.
Reiniciar a instância se a alteração o exigir.
Executar um teste real de ligação TLS a partir de um cliente.
Fazer ADMIN_GET_TLS_CERT(-1, 0) para confirmar o certificado endpoint.
Fazer ADMIN_GET_TLS_CERT(-1, 1) para confirmar a cadeia completa.
Verificar NOT_AFTER, PUBKEY_SIZE e SUBJECT_ALTERNATE_NAMES.
Em ambientes multi-member ou HADR, repetir a validação em todos os servidores relevantes.

Esta combinação é muito mais forte do que confiar apenas num teste de ligação ou apenas na inspeção do keystore.

Os comandos para fazer esse trabalho são deliberadamente deixados fora da parte teórica deste artigo. A componente hands-on fica confinada à lab em Docker abaixo.

9. Uma lab Docker num único host

A segunda metade deste artigo transforma as ideias anteriores numa lab que pode ser executada com uma máquina Linux e a imagem Db2 Community Edition.

O objetivo é deliberadamente limitado:

Iniciar um container Db2
Criar um certificado simples de servidor para a lab
Ativar um listener TLS no Db2
Validar o listener a partir do host Linux
Inspecionar o certificado ativo do Db2 com ADMIN_GET_TLS_CERT

9.1 Pré-requisitos

Vai necessitar de:

uma máquina Linux
Docker Engine e o plugin Docker Compose
pelo menos 8 GB de RAM disponíveis para a lab
acesso shell no host
openssl

Para o Db2 12.1.5.0, há um detalhe prático: o container base expõe gsk9certutil_64, mas em alguns ambientes o runtime ICU necessário para essa ferramenta não está imediatamente disponível. Vamos construir uma pequena imagem derivada que adiciona as bibliotecas runtime necessárias antes de iniciar o Db2.

O lab usa esta imagem base:

icr.io/db2_community/db2:12.1.5.0

9.2 Criar a diretoria da lab

Crie as pastas necessárias no 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

Mantenha os ficheiros do lab exatamente com esta estrutura:

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

Isto importa porque o ficheiro de docker compose usa um bind mount relativo:

- ./host-tls:/host-tls

Por isso, docker-compose.yml tem de ficar na raiz da lab, não dentro de host-tls/.

9.3 Construir uma pequena imagem derivada

Comece por fazer pull da imagem explicitamente:

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

Estabeleça uma sessão de vi

vi Dockerfile

e cole o seguinte conteúdo e saia da sessão gravando (: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

Construa a imagem:

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

9.4 Criar `docker-compose.yml`

Execute, para criar o ficheiro 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 o container

docker compose up -d

Se já existir um container db2tls criado a partir de uma definição de imagem mais antiga, force a recriação:

docker compose up -d --force-recreate

Verifique o estado do container:

docker ps

A inicialização do Db2 demora tempo no primeiro arranque. Repita o comando até encontrar o container no estado healthy.

9.6 Confirmar o Db2 dentro do contentor

Execute uma verificação simples da instância:

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

Crie uma pequena base de dados para usar no lab:

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

9.7 Criar um certificado self-signed de servidor

A pasta de trabalho TLS já foi criada no host antes de o container arrancar:

Para o Db2 12.1.5.0, use os caminhos explícitos da ferramenta GSKit 9 e das respetivas bibliotecas runtime:

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

Exporte esses valores antes de usar a 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
'

Crie a key database e o 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
'

Crie um certificado self-signed de servidor nessa 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 a 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 estes comandos são executados através de docker exec ... bash -lc, os ficheiros gerados podem acabar a pertencer a root dentro do contentor. O Db2 arranca o listener SSL como db2inst1, por isso corrija a ownership antes de configurar o 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 o Db2 para TLS no contentor

Ative o protocolo SSL/TLS ao nível da instância:

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

Configure o listener TLS e as definições do 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 a instância para que as alterações fiquem ativas:

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

Confirme os valores ativos:

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"

Deve agora ver:

DB2COMM=SSL
SSL_SVCENAME definido como 50001
o caminho da key database sob /host-tls/db2server
SSL_SVR_LABEL definido como db2server

9.9 Validar o listener TLS a partir do host Linux

Use openssl s_client:

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

O que quer ver:

um handshake TLS concluído com sucesso
o subject do certificado visível na saída
as datas de validade do certificado

Como este é um certificado self-signed de lab, o OpenSSL vai normalmente queixar-se de trust se lhe pedir validação contra uma cadeia PKI pública. Isso é esperado nesta lab.

Se openssl devolver no peer certificate available e o handshake ler 0 bytes, a porta TCP está acessível, mas o Db2 ainda não está realmente a apresentar um certificado TLS. Nesse caso, verifique por esta ordem:

confirmar que a key database contém realmente a etiqueta db2server
confirmar que a key database e o stash file estão presentes dentro do contentor
reiniciar novamente o Db2 depois de os ficheiros do certificado existirem
confirmar que o Db2 está a escutar na porta TLS dentro do contentor
confirmar que o Docker continua a publicar a porta no host

Os comandos práticos são:

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

Se a configuração do gestor Db2 já mostrar:

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

então a causa de falha costuma ser uma destas:

a key database foi criada sem a etiqueta esperada
a key database ou o stash file não existem na diretoria montada
a key database ou o stash file continuam a pertencer a root e não podem ser lidos por db2inst1
a instância foi reiniciada antes de os ficheiros existirem e não voltou a ser reiniciada depois
o Db2 falhou o bind do listener TLS, apesar de a configuração ter sido aceite

9.10 Usar `ADMIN_GET_TLS_CERT` dentro da lab

Comece pelo 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 a cadeia completa, execute:

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
'

Neste lab, a cadeia deverá conter apenas um único certificado: o próprio certificado endpoint self-signed. Isso é perfeitamente normal. O objetivo é confirmar que:

a função funciona
o uso é reportado como CLIENT_SERVER
a etiqueta é a configurada em SSL_SVR_LABEL
o timestamp de expiração é visível em SQL

Mostrar fingerprints dos 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 tempo de vida restante do 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 tamanho de chave, algoritmo de assinatura e SANs numa só query:

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 os contextos TLS visíveis na instância:

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. O que esta abordámos

A parte teórica deste artigo explica o que o Db2 espera:

o listener correto
o caminho correto da key database
o stash file correto
a etiqueta correta do certificado
o contexto de uso correto em ADMIN_GET_TLS_CERT

O lab em Docker prova estas ideias end-to-end num ambiente reproduzível.

Com apenas um host Linux e um contentor Db2, consegue validar a sequência operacional completa:

criar uma key database e um certificado de servidor
ativar um listener TLS no Db2
confirmar o listener a partir do host com OpenSSL
inspecionar o certificado ativo a partir do Db2 com ADMIN_GET_TLS_CERT

Isto é suficiente para tornar concretos vários conceitos importantes de TLS no Db2:

a diferença entre apenas ter um ficheiro de certificado e realmente ligá-lo ao Db2
a importância de SSL_SVR_LABEL
a utilidade da inspeção de certificados via SQL depois de uma alteração

11. Observações finais

A configuração TLS no Db2 normalmente não é difícil, mas é fácil errar em pormenores subtis. Os modos de falha mais comuns são incompatibilidades operacionais:

etiqueta errada
hostname errado
cadeia signer errada
membro errado
ownership errada dos ficheiros
pressuposto errado sobre o que o Db2 está realmente a servir

ADMIN_GET_TLS_CERT fecha uma lacuna importante de visibilidade porque permite inspecionar a cadeia de certificados ativa com SQL, usando as mesmas ferramentas e fluxos administrativos que as equipas Db2 já usam para monitorização e validação.

Se já usa TLS no Db2, vale a pena acrescentar esta função às verificações normais pós-alteração. Se está prestes a introduzir TLS, vale a pena incluí-la desde o primeiro dia, para que a validação de certificados passe a fazer parte da operação normal do Db2 em vez de uma investigação manual excepcional.

Menu

“A função de tabela ADMIN_GET_TLS_CERT"

1. Porque é que o TLS é importante no Db2

2. Onde o TLS aparece no Db2

3. O que devolve `ADMIN_GET_TLS_CERT`

4. Primeiras queries de inspeção

5. Queries úteis de administração

6. Visibilidade sobre HADR e KMIP

7. Erros comuns que esta função ajuda a expor

Etiqueta errada configurada

Cadeia incompleta

Surpresas de expiração

SAN incompatível

Configuração inconsistente entre membros

8. Checklist prático de validação

9. Uma lab Docker num único host

9.1 Pré-requisitos

9.2 Criar a diretoria da lab

9.3 Construir uma pequena imagem derivada

9.4 Criar `docker-compose.yml`

9.5 Iniciar o container

9.6 Confirmar o Db2 dentro do contentor

9.7 Criar um certificado self-signed de servidor

9.8 Configurar o Db2 para TLS no contentor

9.9 Validar o listener TLS a partir do host Linux

9.10 Usar `ADMIN_GET_TLS_CERT` dentro da lab

10. O que esta abordámos

11. Observações finais

Mais nesta área

“A função de tabela ADMIN_GET_TLS_CERT"

1. Porque é que o TLS é importante no Db2

2. Onde o TLS aparece no Db2

3. O que devolve ADMIN_GET_TLS_CERT

4. Primeiras queries de inspeção

5. Queries úteis de administração

6. Visibilidade sobre HADR e KMIP

7. Erros comuns que esta função ajuda a expor

Etiqueta errada configurada

Cadeia incompleta

Surpresas de expiração

SAN incompatível

Configuração inconsistente entre membros

8. Checklist prático de validação

9. Uma lab Docker num único host

9.1 Pré-requisitos

9.2 Criar a diretoria da lab

9.3 Construir uma pequena imagem derivada

9.4 Criar docker-compose.yml

9.5 Iniciar o container

9.6 Confirmar o Db2 dentro do contentor

9.7 Criar um certificado self-signed de servidor

9.8 Configurar o Db2 para TLS no contentor

9.9 Validar o listener TLS a partir do host Linux

9.10 Usar ADMIN_GET_TLS_CERT dentro da lab

10. O que esta abordámos

11. Observações finais

Mais nesta área

Artigos de Db2 LUW

3. O que devolve `ADMIN_GET_TLS_CERT`

9.4 Criar `docker-compose.yml`

9.10 Usar `ADMIN_GET_TLS_CERT` dentro da lab