Se não for possível estabelecer uma conexão TLS ou SSL com o servidor, verifique:
keyrng em um prompt de comandos. A sintaxe é:
keyrng x connect server_name:port_number ftp
em que:
x é um nome de classe genérico.server_name é o nome do servidor Host On-Demand.port_number é a porta na qual o servidor
está atendendo. Para conexões não-FTP, o padrão é 443. Para conexões do FTP,
o padrão é 990. ftp indica que uma conexão está sendo feita
com um servidor FTPPressione Enter no prompt de senha. Uma lista com todos os certificados do banco de dados conjunto de chaves do servidor é exibida.
keyrng, para verificar o certificado correto e as datas de validade. Por exemplo:
keyrng CustomizedCAs verify
keyrng, para conectar-se ao servidor na porta SSL 12173. Por exemplo:
keyrng x connect servername:12173
Se não for possível estabelecer uma conexão SSH ou SSL com o servidor, verifique o seguinte:
Consulte as seguintes mensagens de erro COMM para obter informações adicionais:
Ao iniciar o IKEYMAN em um servidor Host On-Demand do Windows 2000, ocorre uma mensagem de erro ao carregar o slbck.dll durante a inicialização. Uma leitora de smart card Schlumberger deve ser instalada primeiro e depois desinstalada. Algumas entradas do Schlumberger podem permanecer no registro. Para se livrar dessa mensagem, o usuário deve limpar todas as entradas Schlumberger do registro ou editar um arquivo no Host On-Demand.
O Gerenciador de Certificados do Host On-Demand utiliza a interface PKCS11 para acessar funções do smartcard. Essa interface é utilizada na maioria das vezes para criar certificados auto-assinados em smartcards ou para fazer download de um certificado em um arquivo .pfx ou .p12 para um smartcard.
Antes que o smartcard possa ser acessado, pode ser necessário fazer configurações adicionais. Quando o Host On-Demand é instalado, ele determina se algum smartcard está presente no sistema. Atualmente, o Host On-Demand reconhece o IBM Security Card e as leitoras Schlumberger Reflex instaladas com o Cryptoflex Security Kit V3.0c.
O IBM Certificate Management lê todos esses parâmetros em um arquivo de inicialização denominado ikminit_hod.properties que é armazenado em hostondemand\bin. Se o Host On-Demand reconhecer o IBM Security Card, a seguinte linha será exibida no arquivo de propriedades:
DEFAULT_CRYPTOGRAPHIC_MODULE=w32pk2ig.dll
Isso informa ao IBM Certificate Manager para carregar esse dll, quando as funções do smartcard forem necessárias.
Se o Host On-Demand reconhece uma placa Schlumberger, uma linha semelhante à seguinte aparece no arquivo de propriedades:
DEFAULT_CRYPTOGRAPHIC_MODULE=C:\\Program Files\\Schlumberger\\Smart Cards and Terminals\\Common Files\\slbck.dll
Esses são os únicos dispositivos de segurança que foram testados com o IBM Certificate Management. Se houver um outro dispositivo de segurança que implemente a interface PKCS11 por meio de um dll, o dispositivo de segurança pode ser testado alterando o nome e o local do dll no arquivo ikminit_hod.properties.
Se o dispositivo de segurança for removido do sistema, o IBM Certificate Management relatará o seguinte erro na inicialização:
Falha na inicialização do token de criptografia.
Para evitar esse erro, remova a instrução DEFAULT_CRYPTOGRAPHIC_MODULE do arquivo ikminit_hod.properties.
A instalação de mais de um smartcard no mesmo computador pode fazer com que o suporte ao smartcard do Host On-Demand funcione incorretamente.
Por exemplo, se o IBM Security Card não puder ser aberto pelo Gerenciador de Certificados do Host On-Demand e um smartcard Schlumberger foi instalado anteriormente em seu computador, pode haver valores deixados em seu registro que talvez façam com que os drivers do IBM Security Card funcionem incorretamente.
Para resolver o problema, faça um backup do registro e exclua cuidadosamente quaisquer das seguintes chaves que permaneceram depois que você desinstalou o cartão Schlumberger:
Quando o cliente Host On-Demand entra em contato com um servidor SSL que solicita um certificado do cliente, como o Communications Server para Windows NT, o Communications Server para AIX ou o Communications Server para OS/390 em modo de autenticação de cliente, o cliente Host On-Demand pode invocar a interface MSCAPI, para solicitar todos os certificados de clientes disponíveis. O MSCAPI retornará todos os certificados registrados, quer eles estejam armazenados completamente no banco de dados MSCAPI ou estejam associados por meio do MSCAPI com algum dispositivo de segurança, como o smartcard ou a leitora thumbprint. A lista de certificados que estão registrados atualmente no banco de dados MSCAPI pode ser exibida da seguinte maneira:
Qualquer smartcard ou dispositivo de segurança que seja reconhecido pelo MSIE pode ser utilizado pelo Host On-Demand para autenticação de cliente. Os certificados geralmente são obtidos, visitando-se uma página da Web com o navegador MSIE, preenchendo um formulário na página da Web e, em seguida, armazenando o novo certificado no banco de dados do navegador ou em um dispositivo de segurança.
Por exemplo, carregue http://freecerts.entrust.com/webcerts/ag_browser_req.htm no navegador MSIE. Preencha as informações solicitadas, pressione Continuar na Etapa 2 e, em seguida, Continuar na Etapa 3. Na parte inferior desta página há uma lista suspensa que permite que você especifique o local do certificado.
A escolha do Microsoft Base Cryptographic Provider 1.0 colocará o certificado no banco de dados MSCAPI. Nenhum hardware extra será necessário para acessá-lo.
A escolha do Schlumberger Cryptographic Service Provider ou do Gemplus GemSAFE Card CSP v1.0 colocará o certificado em um smartcard. Se você escolher esse destino, o nome do certificado aparecerá na janela Certificados do MSIE; exatamente como um certificado que foi colocado no banco de dados MSCAPI. No entanto, o certificado será acessível apenas se você tiver ligado o smartcard pelo qual foi feito o download do certificado.
O certificado obtido do freecerts.entrust.com deve ser utilizado apenas para objetivos de teste. Depois de fazer o download do certificado, vá para a janela Certificados MSIE clique na guia Autoridades de Certificação de Raiz Confiável. Percorra a lista até localizar um certificado emitido para Entrust PKI Demonstration Certificates. Destaque esse certificado e exporte-o para um arquivo. Em seguida, inclua o arquivo exportado na lista de confiáveis de seu servidor SSL de autenticação de clientes. Com essa configuração, o servidor SSL deve confiar no certificado Entrust, se ele for retornado pelo cliente Host On-Demand. Esse exercício deve ser utilizado apenas para fins de teste e o Entrust PKI Demonstration Certificate deverá ser removido de qualquer servidor de produção.
O Gerenciador de Certificados do Host On-Demand utiliza a interface PKCS11 para acessar funções do smartcard. Essa interface é utilizada na maioria das vezes para criar certificados auto-assinados em smartcards ou para fazer download de um certificado em um arquivo .pfx ou .p12 para um smartcard. (Nota: O IBM Security Card suporta a criação de um certificado auto-assinado, mas não o download de um certificado existente em um arquivo .pfx ou .p12.)
Antes que o smartcard possa ser acessado, pode ser necessário fazer configurações adicionais. Quando o Host On-Demand é instalado, ele tenta determinar se algum smartcard está presente no sistema. Atualmente, os únicos smartcards reconhecidos são o IBM Security Card e as leitoras Schlumberger Reflex instaladas com o Cryptoflex Security Kit V3.0c.
O IBM Certificate Management lê todos esses parâmetros em um arquivo de inicialização denominado ikminit_hod.properties que é armazenado no diretório hostondemand\bin. Se o IBM Security Card for reconhecido, a seguinte linha será exibida no arquivo de propriedades:
DEFAULT_CRYPTOGRAPHIC_MODULE=w32pk2ig.dll
Isso informa ao IBM Certificate Manager para carregar esse dll, quando as funções do smartcard forem necessárias.
Se nenhum IBM Security Card for detectado, mas for detectado um cartão Schlumberger, a linha será semelhante a:
DEFAULT_CRYPTOGRAPHIC_MODULE=C:\\Program Files\\Schlumberger\\Smart Cards and Terminals\\Common Files\\slbck.dll
Esses são os únicos dispositivos de segurança que foram testados com o IBM Certificate Management. Se houver um outro dispositivo de segurança que implemente a interface PKCS11 por meio de um dll, o dispositivo de segurança pode ser testado alterando o nome e o local do dll no arquivo ikminit_hod.properties. Se os smartcards forem removidos do sistema, essas linhas devem ser removidas do ikminit_hod.properties.
Com essa configuração, um certificado auto-assinado pode ser criado no smartcard com as seguintes etapas:
Os cartões BM Security Card e Schlumberger podem criar certificados auto-assinados. O cartão Schlumberger também pode ter um certificado em um arquivo .p12 ou .pfx importado no cartão.
Se cartões auto-assinados forem criados, a parte pública dos certificados deve ser extraída (não exportada) e incluída na lista confiável do servidor SSL que solicitará o certificado.
Se um certificado auto-assinado for criado no IBM Security Card, ele deverá ser registrado com o MSCAPI. Para fazer isso, inicie a GemSAFE Card Details Tool. Ela verificará o cartão para ver se o certificado no cartão não foi registrado com o MSCAPI e perguntará se você deseja registrá-lo.
Em nosso teste, nem todas as leitoras suportavam todas as operações em todas as plataformas. A seguir, apresentamos uma tabela das leitoras e das plataformas testadas.
| Confiável | Auto-assinado | Incluir .p12 | Sistema Operacional Windows 98/NT | Sistema Operacional Windows 2000 | |
|---|---|---|---|---|---|
| IBM Security Card Leitora PCMCIA | X | X | X | ||
| IBM Security Card Leitora Serial | X | X | |||
| Leitora Schlumberger Reflex 20 | X | X | X | X | X |
| Leitora Schlumberger Reflex 72 | X | X | X | X | |
| Schlumberger Reflex Lite | X | X | X | X |
O Host On-Demand e seus utilitários não lerão arquivos PKCS12 exportados utilizando o utilitário gskkyman do z/OS. O problema é que o gskkyman utiliza o formato PFX v1 para arquivos PKCS12, enquanto que o Host On-Demand e seus utilitários utilizam o formato PFX v3 para arquivos PKCS12.
Aqui está um exemplo de um cenário em falha:
A senha do certificado estava incorreta ou o certificado localizado no <caminho do arquivo PKCS12> estava corrompido. (ECL0034) Outro cenário em falha pode ser que o certificado não pode ser lido por nenhum dos utilitários de certificados do Host On-Demand.
A correção é converter o arquivo PKCS12 para o formato PFX v3 antes de enviar o arquivo PKCS12 a um usuário e antes de utilizar o arquivo PKCS12 com qualquer utilitário ou sessão do Host On-Demand. Para converter o formato, siga as seguintes etapas:
Nos sistemas operacionais Windows, depois de fazer o upgrade do Host On-Demand para um novo nível, o painel Assistente para Certificado pode não aparecer quando o Assistente para Certificado for iniciado.
Esse problema é causado pelo fato dos processos de programas associados ao Assistente para Certificado terem sido deixados em execução durante o upgrade. Nos sistemas operacionais Windows 2000, esses processos de programas são:
Como solução alternativa temporária, você pode utilizar o Gerenciador de Certificados.
Para realmente corrigir esse problema utilizando o sistema operacional Windows 2000, siga estas etapas:
O Keytool.exe é um executável binário para Windows incluído com o JRE instalado com o Host On-Demand. Ao executar o keytool.exe, existem erros de tradução para o idioma da República Tcheca.
Para resolvee esse problema, faça upgrade para o IBM JRE mais recente no Web site do Host On-Demand Service Key.
O utilitário de gerenciamento de certificados em AIX requer o JRE 1.1.8. Se estiver executando o JVM 1.3, você receberá a seguinte mensagem de erro:
Exceção no encadeamento "main" java.lang.VerifyError
Para utilizar o utilitário de gerenciamento de certificados no AIX com o JRE 1.1.8, defina a variável de ambiente JAVA_HOME para apontar para a instalação do Java 1.1.8 antes de executar o script "CertificateManagement".
Ao utilizar produtos de segurança de outros fornecedores que travam ou sobrescrevem arquivos, como o Mission Control do Netscape, esteja ciente que os arquivos de configuração editados do cliente podem causar problemas ao fazer uppgrade para versão mais recente do Host On-Demand.
Por exemplo, se o arquivo signed.db está travado ou sobrescrito, a versão anterior do certificado assinado do Host On-Demand é apresentado. Conseqüentemente, como a versão incorreta do certificado continua a ser apresentada, os usuários são solicitados a conceder ou negar acesso aos applets da versão mais recente do Host On-Demand cada vez que tentarem efetuar login. Selecionando a caixa de opções "Lembrar esta Decisão" não tem efeito. Outros sintomas incluem linhas em branco ou informações de certificado hexadecimal não definidas na lista de Certificados Java/Javascript do Netscape.
Para resolver isso, siga as instruções do programa de segurança sobre como recapturar a configuração para utilizar a versão mais recente do certificado assinado do Host On-Demand antes de distribuir aos usuários.
