Introdução

O Secure Sockets Layer (SSL) é um protocolo padrão do mercado, que providencia segurança nas comunicações via Internet usando mecanismos de criptografia de chave pública e simétrica. O protocolo SSL funciona sobre os protocolos TCP/IP e abaixo de protocolos de aplicativos, como o Lightweight Directory Access Protocol (LDAP) e o Hypertext Transfer Protocol (HTTP), e fornece confiança e privacidade para o transporte de dados. Durante a configuração das configurações de segurança de bancos de dados centralizados, os administradores podem desejar implementar medidas adicionais de segurança para o acesso ao banco de dados de diretório. O AIX suporta a segurança SSL no IBM Tivoli Directory Server (ITDS). Após instalar e configurar o certificado, os clientes podem se comunicar através de portas seguras (636) ou inseguras (389).

Pré-requisitos

• O pacote do conjunto de arquivos ITDS 6.0 deve ser instalado e atualizado para o nível mais atual.
• Instale o conjunto de arquivos Global Security GSKit.
• O ITDS deve ser executado com a instância padrão ldapdb2, como exibido abaixo:

  # ps -e | grep -E "[i]bmslapd|[i]bmdiradm" 503982 - 0:00 ibmdiradm 540812 pts/0 1:35 ibmslapd

  
  

Como o SSL funciona com o ITDS?

Em uma conexão LDAP normal, o cliente conecta-se à porta 389 e a troca de informações é feita em texto simples. Não há como garantir que um cliente LDAP está conectado ao servidor do LDAP correto. Os hackers podem infectar o seu DNS ou instalar um servidor próprio na máquina correta.

O uso do SSL com ITDS pode resolver o problema dessa vulnerabilidade.

Primeiramente, o SSL pode resolver o problema de verificar se você está conectado ao servidor correto. Quando ocorre a conexão entre o cliente e o servidor, eles executam um processo "aperto de mãos" do SSL, que envolve a troca de chaves de criptografia entre o servidor e o cliente, as quais são descritas usando os certificados X.509. Se o cliente deseja confirmar que está conectado ao servidor correto, ele precisa verificar o certificado do servidor, que é enviado no "aperto de mãos". Isso pode ser feito verificando se o certificado está assinado (trusted) por alguém em que você confia, e que o certificado não foi revogado. Por exemplo, o certificado do servidor pode ter sido assinado pela Verisign (www.verisign.com), e você então decide que deseja confiar na Verisign para a assinatura de certificados legítimos.

Quando o SSL está ativado, a troca de dados entre o cliente e o registro LDAP é criptografada. Ambas as autenticações de cliente e servidor são suportadas.

Configurando o SLL para a autenticação do servidor

Para a autenticação do servidor, o ITDS fornece ao cliente o certificado ITDS X.509 durante o "aperto de mãos" inicial do SSL. Se o cliente valida o certificado do servidor, como exibido na Figura 1, então um canal de comunicação seguro e criptografado é estabelecido entre o ITDS e o aplicativo do cliente.

Vamos dividir a autenticação do servidor exibida na Figura 1 em duas partes:

• Configurando o IBM Tivoli Directory Server para o acesso SSL
• Configurando o cliente IBM Tivoli Directory Server para o acesso SLL

Configurando o IBM Tivoli Directory Server para o acesso SSL

As seguintes etapas são necessárias para habilitar o suporte SSL para ITDS para a autenticação do servidor:

1. Crie um banco de dados de chaves (CMS) para armazenar os certificados do servidor, assim como as chaves públicas e privadas do servidor.

   # gsk7cmd -keydb -create -db $SRVKEY_PATH/serverkey -pw $SRVKEY_PASSWD -type cms -stash

   
   

   Ao concluir o comando acima com sucesso, quatro arquivos são criados:

   • serverkey.kdb ― Esse arquivo é o próprio banco de dados de chave.
   • serverkey.rdb ― Esse arquivo é usado para armazenar solicitações de certificados.
   • serverkey.crl ― Este arquivo é usado para manter a lista de revogação de certificados.
   • serverkey.sth ― Este arquivo armazena a versão criptografada da senha.
2. Crie um certificado autoassinado e extraia e torne-o disponível em todos os sistemas do cliente que se comunicam com segurança com o servidor.

   # gsk7cmd -cert -create -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD -label \ $SRV_LABEL -dn "CN=`hostname`,O=IBM,C= INDIA" -default_cert yes -expire 999

   
   

   Um certificado autoassinado pode ser criado e usado somente em testes ou em ambientes da Intranet. Durante a produção ou em ambientes da Internet, é necessário obter um certificado comercial de uma Certificate Authority (CA) reconhecida, como a Verisign.

   Verifique a disponibilidade do certificado SRV_CERT dentro da keydb. Observe a listagem de código abaixo.

   # gsk7cmd -cert -list -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD Certificates in database: /var/adm/ras/SSLKey_SRV/serverkey.kdb Entrust.net Global Secure Server Certification Authority Entrust.net Global Client Certification Authority Entrust.net Client Certification Authority Entrust.net Certification Authority (2048) Entrust.net Secure Server Certification Authority VeriSign Class 3 Secure Server CA VeriSign Class 3 Public Primary Certification Authority VeriSign Class 2 Public Primary Certification Authority VeriSign Class 1 Public Primary Certification Authority VeriSign Class 4 Public Primary Certification Authority - G2 VeriSign Class 3 Public Primary Certification Authority - G2 VeriSign Class 2 Public Primary Certification Authority - G2 VeriSign Class 1 Public Primary Certification Authority - G2 VeriSign Class 4 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 2 Public Primary Certification Authority - G3 VeriSign Class 1 Public Primary Certification Authority - G3 Thawte Personal Premium CA Thawte Personal Freemail CA Thawte Personal Basic CA Thawte Premium Server CA Thawte Server CA RSA Secure Server Certification Authority -->SRV_CERT

   
   

3. Após criar um certificado autoassinado, é necessário extrair a certificação para o uso dos sistemas do cliente que se comunicam com segurança com o servidor:

   # gsk7cmd -cert -extract -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD –label \ $SRV_LABEL -target $EXTRACT_PATH/ serverkey.arm –format binary

   
   
4. Quando o banco de dados de chaves está pronto com o certificado autoassinado, configure o servidor de diretório para usar esse certificado.

   Crie um LDIF, file.ldif, no seguinte formado usando um editor de texto.

   dn: cn=SSL,cn=Configuration changetype: modify replace: ibm-slapdSslAuth ibm-slapdSslAuth: serverAuth - replace: ibm-slapdSecurity ibm-slapdSecurity: SSL dn: cn=SSL,cn=Configuration changetype: modify replace: ibm-slapdSSLKeyDatabase ibm-slapdSSLKeyDatabase: /var/adm/ras/SSLKey_SRV/serverkey.kdb - replace:ibm-slapdSslCertificate ibm-slapdSslCertificate: SRV_CERT - replace: ibm-slapdSSLKeyDatabasePW ibm-slapdSSLKeyDatabasePW: key4server

   
   

   Apresente esse arquivo LDIF ao servidor de diretório abaixo.

   # idsldapmodify -D cn=admin -w admin -i file.ldif -p 389 modifying entry cn=SSL,cn=Configuration modifying entry cn=SSL,cn=Configuration

   
   

   Observe o arquivo /home/ldapdb2/idsslapd-ldapdb2/etc/ibmslapd.conf e veja a alteração nas entradas destacadas com flechas abaixo.

   dn: cn=SSL, cn=Configuration cn: SSL ibm-slapdSecurePort: 636 #ibm-slapdSecurity must be one of none/SSL/SSLOnly/TLS/SSLTLS -->ibm-slapdSecurity: SSL #ibm-slapdSslAuth must be one of serverAuth/serverClientAuth -->ibm-slapdSslAuth: serverAuth -->ibm-slapdSslCertificate: SRV_CERT ibm-slapdSslCipherSpec: AES ibm-slapdSslCipherSpec: AES-128 ibm-slapdSslCipherSpec: RC4-128-MD5 ibm-slapdSslCipherSpec: RC4-128-SHA ibm-slapdSslCipherSpec: TripleDES-168 ibm-slapdSslCipherSpec: DES-56 ibm-slapdSslCipherSpec: RC4-40-MD5 ibm-slapdSslCipherSpec: RC2-40-MD5 ibm-slapdSslFIPSProcessingMode: false -->ibm-slapdSslKeyDatabase: /var/adm/ras/SSLKey_SRV/serverkey.kdb ibm-slapdSSLKeyDatabasePW: {AES256}5+6hlNHZ8DFvhRRjmRP9GA== objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdSSL

   
   

5. É necessário parar e reiniciar o Tivoli Directory Server e o daemon de administração para que as alterações tenham efeito.

   a. Stopping directory server. # ibmslapd -k -I "instance name" b. Stopping administrator daemon # ibmdirctl -h host_name -D ldap_admin -w ldap_pw admstop c. Starting administrator daemon # ibmdiradm "instance name" d. Starting directory server # ibmslapd -n -I "instance name"

   
   

Configurando o cliente ITDS para o acesso SSL

Após habilitar o SSL no servidor do LDAP, é possível configurar o acesso SSL nos sistemas do cliente. De modo semelhante à criação de um arquivo de banco de dados de chave para o servidor, é necessário criar um arquivo de banco de dados de chaves no sistema do cliente. Observe que para o cliente autenticar o servidor do LDAP, ele precisa reconhecer a Certificate Authority (CA) responsável pela certificação para o servidor LDAP. Se o servidor do LDAP está usando um certificado autoassinado, o cliente precisa ser capaz de reconhecer o sistema que gerou o certificado do servidor do LDAP como uma raiz confiável (autoridade certificada).

Para configurar o cliente do LDAP para o acesso SSL ao servidor do LDAP, conclua as instruções abaixo na máquina do cliente:

1. Crie um arquivo de banco de dados de chaves (CMS) usando a utilidade de gerenciamento de chave GSKit.

   # gsk7cmd -keydb -create -db $CLIKEY_PATH/clientkey -pw $CLIKEY_PASSWD \ -type cms -stash

   
   
2. Copie o arquivo do certificado extraído do servidor do LDAP para a máquina do cliente.

   # rcp -r $LDAP_SERVER:$SRVKEY_PATH/EXTRACT/ $CLIKEY_PATH/

   
   
3. Importe o certificado do servidor (do CA ou um certificado autoassinado) como um assinante confiável no banco de dados de chaves do cliente. Insira um rótulo para o certificado do assinante que você está adicionando. Se o certificado foi criado por uma autoridade certificada, é possível usar o nome dessa autoridade como rótulo. Para certificados autoassinados, use o nome do servidor do LDAP como rótulo.

   # gsk7cmd -cert -add -db $CLIKEY_PATH/clientkey.kdb -pw $CLIKEY_PASSWD -label \ $LDAP_SERVER -file $CLIKEY_PATH/serverkey.arm

   
   

   Liste o certificado adicionado e faça a verificação.

   # gsk7cmd -cert -list -db $CLIKEY_PATH/clientkey.kdb -pw $CLIKEY_PASSWD Certificates in database: /var/adm/ras/SSLKey_CLI/clientkey.kdb -->fluffy01 Entrust.net Global Secure Server Certification Authority Entrust.net Global Client Certification Authority Entrust.net Client Certification Authority Entrust.net Certification Authority (2048) Entrust.net Secure Server Certification Authority VeriSign Class 3 Secure Server CA VeriSign Class 3 Public Primary Certification Authority VeriSign Class 2 Public Primary Certification Authority VeriSign Class 1 Public Primary Certification Authority VeriSign Class 4 Public Primary Certification Authority - G2 VeriSign Class 3 Public Primary Certification Authority - G2 VeriSign Class 2 Public Primary Certification Authority - G2 VeriSign Class 1 Public Primary Certification Authority - G2 VeriSign Class 4 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 2 Public Primary Certification Authority - G3 VeriSign Class 1 Public Primary Certification Authority - G3 Thawte Personal Premium CA Thawte Personal Freemail CA Thawte Personal Basic CA Thawte Premium Server CA Thawte Server CA RSA Secure Server Certification Authority CLI_CERT

   
   

4. Para testar se o acesso SSL foi ativado, insira o seguinte comando no sistema do cliente LDAP:

   # idsldapsearch -h $LDAP_SERVER -Z -K $CLIKEY_PATH/clientkey.kdb -P $CLIKEY_PASSWD \ -b "" -s base objectclass=*

   
   

   Uma vez que o ITDS permite múltiplas instâncias, será necessário especificar o número da porta se você não está usando a porta segura padrão 636. A porta segura 636 recebe solicitações SSL no servidor do LDAP. Observe o valor de 389 na saída de comando acima, uma vez que o servidor foi ativado para ambas as solicitações SSL e não SSL.

5. Para configurar o cliente para se comunicar com o servidor do LDAP usando SSL, insira:

   # mksecldap -c -h $LDAP_SERVER -a cn=admin -p admin -d o=ibm -k $CLIKEY_PATH/ \ clientkey.kdb -w $CLIKEY_PASSWD

   
   

   Nas etapas finais da configuração do cliente, o comando mksecldap inicia o daemon do lado do cliente e adiciona uma entrada no arquivo /etc/inittab de modo que o daemon é iniciado a cada reinicialização. É possível verificar se a configuração foi realizada com sucesso verificando o processo secldapclntd do daemon através do comando ls-secldapclntd.

   # ls-secldapclntd ldapservers=fluffy01 ldapport=636 ldapversion=3 userbasedn=ou=People,o=ibm groupbasedn=ou=Groups,o=ibm idbasedn=ou=system,o=ibm usercachesize=1000 usercacheused=0 groupcachesize=100 groupcacheused=0 usercachetimeout=300 groupcachetimeout=300 heartbeatT=300 numberofthread=10 connectionsperserver=10 alwaysmaster=no authtype=UNIX_AUTH searchmode=ALL defaultentrylocation=LDAP ldaptimeout=60 userobjectclass=posixaccount,account,shadowaccount,aixauxaccount, ibm-securityIdentities groupobjectclass=posixgroup,aixauxgroup

   
   

Essa etapa conclui o SSL para a autenticação do servidor.

Voltar para parte superior

Configurando o SLL para a autenticação do servidor e do cliente

Este tipo de autenticação fornece um "aperto de mãos" de duas vias entre o cliente e o servidor do LDAP. Um certificado precisa ser estabelecido no sistema do cliente, de modo que depois que o cliente autentica o servidor, o servidor solicita o certificado do cliente e usa-o para autenticar a identidade do cliente.

Para estabelecer um certificado para o sistema do cliente, faça o seguinte:

1. Crie um arquivo de banco de dados de chaves (CMS) no cliente.

   # gsk7cmd -keydb -create -db $CLIKEY_PATH/clientkey -pw $CLIKEY_PASSWD -type cms -stash

   
   
2. Crie um certificado pessoal e sua chave privada no banco de dados de chaves. Esse certificado pessoal representa a identidade do sistema do cliente do Tivoli Directory Server durante as comunicações SSL.

   # gsk7cmd -cert -create -db $CLIKEY_PATH/clientkey.kdb -pw $CLIKEY_PASSWD -label \ $CLI_LABEL -dn "CN=`hostname`,O=IBM,C=INDIA"

   
   Liste os certificados de keydb.

   # gsk7cmd -cert -list -db $CLIKEY_PATH/clientkey.kdb -pw $CLIKEY_PASSWD Certificates in database: /var/adm/ras/SSLKey_CLI/clientkey.kdb fluffy01 Entrust.net Global Secure Server Certification Authority Entrust.net Global Client Certification Authority Entrust.net Client Certification Authority Entrust.net Certification Authority (2048) Entrust.net Secure Server Certification Authority VeriSign Class 3 Secure Server CA VeriSign Class 3 Public Primary Certification Authority VeriSign Class 2 Public Primary Certification Authority VeriSign Class 1 Public Primary Certification Authority VeriSign Class 4 Public Primary Certification Authority - G2 VeriSign Class 3 Public Primary Certification Authority - G2 VeriSign Class 2 Public Primary Certification Authority - G2 VeriSign Class 1 Public Primary Certification Authority - G2 VeriSign Class 4 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 2 Public Primary Certification Authority - G3 VeriSign Class 1 Public Primary Certification Authority - G3 Thawte Personal Premium CA Thawte Personal Freemail CA Thawte Personal Basic CA Thawte Premium Server CA Thawte Server CA RSA Secure Server Certification Authority -->CLI_CERT

   
   
3. Após criar o certificado autoassinado, é necessário extraí-lo para o uso no sistema do servidor do LDAP que irá se comunicar com segurança com o cliente.

   # gsk7cmd -cert -extract -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD –label $SRV_LABEL -target $EXTRACT_PATH/ serverkey.arm –format binary

   
   

   Uma vez que o certificado do cliente tiver sido extraído para um arquivo, esse arquivo precisa ser disponibilizado no Tivoli Directory Server.

4. Agora, adicione o certificado do cliente extraído dentro do banco de dados de chaves no sistema do servidor como um assinante confiável.

   Envie o certificado do cliente via FTP para a máquina do servidor.

   # gsk7cmd -cert -add -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD \ -label $CLI_NAME -file $PATH/clientkey.arm

   
   Insira um rótulo para o certificado que você está criando. Se você está usando um certificado autoassinado, use o nome do cliente por motivos de exclusividade.

   Liste os certificados dentro da keydb do servidor e verifique o certificado do cliente.

   # gsk7cmd -cert -list -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD Certificates in database: /var/adm/ras/SSLKey_SRV/serverkey.kdb -->charleston01 Entrust.net Global Secure Server Certification Authority Entrust.net Global Client Certification Authority Entrust.net Client Certification Authority Entrust.net Certification Authority (2048) Entrust.net Secure Server Certification Authority VeriSign Class 3 Secure Server CA VeriSign Class 3 Public Primary Certification Authority VeriSign Class 2 Public Primary Certification Authority VeriSign Class 1 Public Primary Certification Authority VeriSign Class 4 Public Primary Certification Authority - G2 VeriSign Class 3 Public Primary Certification Authority - G2 VeriSign Class 2 Public Primary Certification Authority - G2 VeriSign Class 1 Public Primary Certification Authority - G2 VeriSign Class 4 Public Primary Certification Authority - G3 VeriSign Class 3 Public Primary Certification Authority - G3 VeriSign Class 2 Public Primary Certification Authority - G3 VeriSign Class 1 Public Primary Certification Authority - G3 Thawte Personal Premium CA Thawte Personal Freemail CA Thawte Personal Basic CA Thawte Premium Server CA Thawte Server CA RSA Secure Server Certification Authority -->SRV_CERT

   
   
5. Depois que o servidor do LDAP reconhecer a autoridade de certificação que criou o certificado pessoal do cliente, teste o acesso SSL usando o seguinte comando no cliente do LDAP.

   # idsldapsearch -h server_name -Z -K $CLIKEY_PATH/clientkey.kdb -P \ $CLIKEY_PASSWD -N $CLI_LABEL -b "" -s base objectclass=*

   
   

Com isso, a configuração do SSL está completa.

Voltar para parte superior

Manutenção do certificado e do banco de dados de chaves

Ao criar um novo banco de dados de chaves, você especifica uma senha para esse banco de dados. Essa senha protege a chave privada e é a única chave que pode assinar documentos ou decriptografar mensagens criptografadas com a chave pública. É uma boa prática trocar a senha do banco de dados de chaves frequentemente.

Como atualizar uma senha expirada do banco de dados de chaves

Para trocar a senha do banco de dados, digite:

#  gsk7cmd -keydb -changepw -db $SRVKEY_PATH/serverkey.kdb -pw $SRVKEY_PASSWD \
   -new_pw newpassw0rd -stash
    

Também é necessário atualizar a senha dentro do arquivo ibmslapd.conf.

Procure pela seguinte palavra-chave dentro de /home/ldapdb2/idsslapd-ldapdb2/etc/ibmslapd.conf e a substitua com a nova senha em formato de texto.

 ibm-slapdSSLKeyDatabasePW: newpassw0rd 

É necessário reiniciar o processo ibmslapd para que a nova senha entre em vigor.

#  ibmslapd -k; ibmslapd -n

Listando certificados expirados

O código abaixo mostra como exibir uma lista de certificados em um banco de dados de chaves, junto com suas dadas de expiração:

#  gsk7cmd -cert -list -expiry -db $CLIKEY_PATH/clientkey.kdb -pw \
   $CLIKEY_PASSWD -type cms
   Certificates in database: /var/adm/ras/SSLKey_CLI/clientkey.kdb
   COFFEE
      Validity
      Not Before: Wed Nov 28 02:43:42 CST 2007
      Not After: Fri Nov 30 02:43:42 CST 2007
   VeriSign Class 2 OnSite Individual CA
      Validity
      Not Before: Mon May 18 19:00:00 CDT 1998
      Not After: Mon Oct 12 18:59:59 CDT 2009
   VeriSign International Server CA - Class 3
      Validity
      Not Before: Wed Apr 16 19:00:00 CDT 1997
      Not After: Mon Oct 24 18:59:59 CDT 2011
   Verisign Class 3 Public Primary Certification Authority - G2
      Validity
      Not Before: Sun May 17 19:00:00 CDT 1998
      Not After: Tue Aug 01 18:59:59 CDT 2028
   Verisign Class 2 Public Primary Certification Authority - G2
      Validity
      Not Before: Sun May 17 19:00:00 CDT 1998
      Not After: Tue Aug 01 18:59:59 CDT 2028

A especificação do número de dias com -expiry é opcional, embora, quando usada, ela apresente todos os certificados que irão expirar dentro do número de dias especificado. Para listar os certificados que já expiraram, insira o valor 0.

Exibindo todo o certificado

Para exibir toda a entrada da chave, digite o seguinte:

#  gsk7cmd -cert -details -showOID -db $CLIKEY_PATH/clientkey.kdb \
   -pw $CLIKEY_PASSWD -label COFFEE 
     

Resolvendo um certificado expirado

Siga as seguintes etapas caso o certificado tenha expirado:

• Crie um novo certificado no servidor do LDAP.
• Remova o certificado expirado do seu armazenamento de chaves.
• Configure o servidor do LDAP para usar o novo certificado.
• Reinicie os processos ibmdiradm e ibmslapd.
• Extraia o certificado e forneça o novo certificado para todos os armazenamentos de chaves do cliente.

Voltar para parte superior

Depuração básica

O IBM Tivoli Directory Server conta com várias ferramentas além das ferramentas sistema operacional para ajudá-lo a determinar a causa dos problemas que você encontra.

Logs de erros

Os logs de erros registram as mensagens de erro que ocorrem durante o processamento do servidor de diretório. O IBM Tivoli Directory Server detecta e salva essas mensagens de erro em um arquivo de texto.

Por padrão, todos os logs estão localizados em:

      "instance home"/idsslapd-"instance name"/logs

Para a instância ldapdb2, os logs e o arquivo de configuração estão localizados aqui:

#  /home/ldapdb2/idsslapd-ldapdb2/etc/ibmslapd.conf
#  /home/ldapdb2/idsslapd-ldapdb2/logs/
   adminaudit.log        bulkload.log       db2clicmds.log     ibmslapd.log
   lostandfound.log    audit.log             db2cli.log         ibmdiradm.log
   idstools.log              traceibmslapd.log
     

Este é um exemplo do que se parecem os logs:

   11/16/07 06:50:30 GLPCTL115I Maximum data segment limit for the process (in bytes):
   '1073741312'(Soft limit) and '-1'(Hard limit).
   11/16/07 06:50:30 GLPCTL116I Maximum physical memory limit for the process 
   (in bytes):  '1073741312'(Soft limit) and '-1'(Hard limit).
   11/16/07 06:50:30 GLPSRV009I IBM Tivoli Directory (SSL), 6.0    Server started.
   11/16/07 06:50:30 GLPSRV048I Started 15 worker threads to handle client requests.
    

Verificação dos certificados e repositórios do armazenamento de chaves

Alguns dos problemas comuns dos certificados são discutidos abaixo.

• Problema 1:

  GLPCOM003I Non-SSL port initialized to 389. GLPCOM004I SSL port initialized to 636. GLPSSL002E File I/O error on opening SSL key database file $SRVKEY_PATH/serverkey.kdb. GLPSRV004I Terminating server.

  
  

  Se o banco de dados de chaves usado pelo diretório do LDAP e pelos servidores de administração não puder ser lido ou não estiver disponível, o erro acima ocorrerá. Verifique o nome e o caminho para o seu arquivo do banco de dados de chaves e atualize o arquivo ibmslapd.conf para que ele reflita o caminho correto e totalmente qualificado para o arquivo do banco de dados de chaves. Reinicie o servidor.

• Problema 2:

  # idsldapsearch -h `hostname` -Z -K SRVKEY_PATH/serverkey.kdb -P badpassw0rd \ -b "" -s base objectclass=* ldap_ssl_client_init failed! rc == 113, failureReasonCode == 408 Bad keyfile password

  
  

  Nesse caso, verifique a senha do seu banco de dados de chaves.

• Problema 3:

  # idsldapsearch -h `hostname` -Z -K $CLIKEY_PATH/badkey.kdb -P $CLIKEY_PASSWD \ -b "" -s base objectclass=* ldap_ssl_client_init failed! rc == 113, failureReasonCode == 202 Keyring file open error

  
  

  Verifique o nome do banco de dados de chaves do cliente. Ou o banco de dados do cliente especificado não existe.

• Problema 4:

  # idsldapsearch -h `hostname` -Z -K $CLIKEY_PATH/clientkey.kdb -P \ $CLIKEY_PASSWD -b "" -s base objectclass=* ldap_ssl_client_init failed! rc == 113, failureReasonCode == 102 Keyfile I/O error

  
  

  O banco de dados de chaves do cliente errado foi especificado. O certificado do cliente não consegue encontrar o banco de dados de chaves interno.

• Problema 5:

  # mksecldap -c -h coffee -a cn=admin -p admin -d o=ibm -k $CLIKEY_PATH/clientkey.kdb \ -w $CLIKEY_PASSWD Cannot contact LDAP server coffee. client presetup check failed.

  
  

  O processo ibmslapd não está em execução no lado do servidor. Inicie-o usandoibmslapd -n e tente novamente.

Voltar para parte superior

Resumo

Durante a configuração das configurações de segurança para o diretório do LDAP no AIX, os administradores podem desejar implementar medidas adicionais de segurança para o acesso aos ITDS. O AIX fornece a segurança SSL, um mecanismo de autenticação baseado em certificados sobre LDAP. Este artigo lhe dá uma visão geral da configuração do SSL para o ITDS 6.0 no sistema operacional AIX 5L. Um procedimento de configuração via linha de comando é explicado passo a passo para a criação de bancos de dados de chaves SSL, criação e extração de certificados, entendimento dos mecanismos de autenticação SSL, solução de problemas de SSL e métodos para serem usados em relação à comunicação cliente-servidor do LDAP.

Recursos

Aprender

• Consulte o IBM Tivoli Directory Server Messages Guide para obter uma lista de todas as mensagens de erro, avisos e informações associadas com o IBM Tivoli Directory Server 6.1.
  
  
• O suporte do IBM Tivoli Directory Server fornece informações técnicas de autoajuda para ajudá-lo na solução de problemas técnicos com o Tivoli
  
  
• Consulte o guia de consulta para a programação de plug-ins do cliente do LDAP a respeito de possíveis códigos de erro estendidos resultantes dos códigos de função SSL do LDAP.
  
  
• O IBM Global Security Kit Secure Sockets Layer Introduction and iKeyman User's Guide fornece informações para administradores de segurança de sistemas ou redes que instalam, administram e usam sistemas baseados em SSL.
  
  
• Leia o artigo do developerWorks LDAP configuration management and troubleshooting on AIX.
  
  
• AIX Wiki: descubra um ambiente colaborativo para obter informações técnicas relacionadas com o AIX.
  
  

Discutir

• Participe dos fóruns AIX e UNIX:
  • AfIX 5L ― fórum técnico
  • Fórum AIX for Developers
  • Cluster Systems Management
  • IBM Support Assistant
  • Performance Tools ― técnico
  • Virtualization ― técnico
  • Mais fóruns AIX e UNIX
  
  

Sobre o autor

Chethan Jain é Staff Software Engineer no escritório de Bangalore da IBM na equipe AIX UPT Release. Chethan está envolvido com testes do AIX há mais de dois anos. Ele é especializado na instalação e configuração de Secure Sockets Layer (SSL), IBM Tivoli Directory Server (ITDS) e Tivoli Access Manager para componentes de sistemas operacionais (TAMOS) em AIX. É possível entrar em contato com ele através do e-mail chetjain@in.ibm.com.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Pré-requisitos
• Como o SSL funciona com o ITDS?
• Configurando o SLL para a autenticação do servidor
• Configurando o SLL para a autenticação do servidor e do cliente
• Manutenção do certificado e do banco de dados de chaves
• Depuração básica
• Resumo
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais