Comunicações Seguras Usando o SSL (Secure Sockets Layer)

O protocolo SSL (Secure Sockets Layer) fornece a segurança da camada de transporte, incluindo autenticidade, assinatura de dados e criptografia de dados para garantir uma conexão segura entre um cliente e um servidor que utiliza oWebSphere Application Server. A tecnologia de base para SSL é criptografia de chave pública, a qual garante que, quando uma entidade criptografa dados usando sua chave pública, apenas entidades com a chave privada correspondente poderão decriptografar estes dados.

O WebSphere Application Server utiliza o JSSE (Java™ Secure Sockets Extension) como a implementação de SSL para conexões seguras. O JSSE faz parte da especificação do J2SE (Java 2 Standard Edition) e está incluído na implementação IBM® do JRE (Java Runtime Extension). O JSSE manipula os recursos de negociação e proteção do protocolo de reconhecimento que são fornecidos pelo SSL para garantir uma conectividade segura na maioria dos protocolos. O JSSE conta com pares de chaves assimétricas, baseadas no certificado X.509, para proteção de conexão segura e alguma criptografia de dados. Os pares de chaves criptografam efetivamente as chaves secretas baseadas em sessão que criptografam blocos maiores de dados. A implementação SSL gerencia os certificados X.509.

O WebSphere Application Server envia o Java SE7. Por padrão, o Java SE 7 ativa o Server Name Indication (SNI). SNI é uma extensão do protocolo TLS. A SNI permite que um cliente especifique o nome do host ao qual está tentando se conectar. São emitidas exceções se o certificado retornado não corresponde ao nome de host esperado.

Em alguns ambientes de proxy, isso causará erros. O cliente espera receber o certificado do proxy mas, em vez disso, recebe o certificado do servidor de terminal.

Gerenciando Certificados X.509

As comunicações seguras para o WebSphere Application Server requerem certificados X.509 assinados digitalmente. O conteúdo de um certificado X.509, como seu nome distinto e expiração, é assinado por uma CA (autoridade de certificação), assinado por um certificado raiz no NodeDefaultRootStore ou DmgrDefaultRootStore, ou é auto-assinado. Quando um CA confiável assina um certificado X.509, o WebSphere Application Server identifica o certificado e o distribui livremente. Um certificado deve ser assinado por uma CA porque ele representa a identidade de uma entidade para o público geral. As portas do servidor que aceitam conexões do público geral devem usar certificados assinados pela CA. A maioria dos clientes ou navegadores já possuem o certificado de signatário que pode validar o certificado X.509 para que a troca de signatário não seja necessária para uma conexão bem-sucedida.

Só será possível confiar na identidade de um certificado X.509 auto-assinado apenas se um ponto em um ambiente controlado, como comunicações de rede interna, aceitar a assinatura do signatário. Para concluir um protocolo de reconhecimento confiável, é necessário primeiro enviar uma cópia do certificado de entidade para cada ponto conectado à entidade.

Os certificados CA, em cadeia e autoassinados X.509 residem em keystores do Java. O JSSE fornece uma referência para o armazenamento de chaves no qual um certificado reside. É possível selecionar entre vários tipos de armazenamentos de chaves, inclusive armazenamentos de chaves baseados em JCE (Java Cryptographic Extension) e baseados em hardware. Geralmente, cada configuração JSSE tem duas referências de armazenamento de chaves Java : um armazenamento de chaves e um armazenamento confiável. A referência do armazenamento de chaves representa um objeto de armazenamento de chaves Java que mantém os certificados pessoais. A referência do armazenamento confiável representa um objeto de armazenamento de chaves Java que mantém os certificados do signatário.

Um certificado pessoal sem uma chave privada é um certificado X.509 que representa a entidade que o possui durante um protocolo de reconhecimento. Os certificados pessoais contêm chaves públicas e privadas. Um certificado de signatário é um certificado X.509 que representa uma entidade de ponto ou ele próprio. Os certificados de signatário contêm apenas a chave pública e verificam a assinatura da identidade recebida durante um protocolo de reconhecimento de ponta a ponta.

Para obter informações adicionais, consulte Adding the correct SSL Signer certificates to the plug-in keystore

Para obter mais informações sobre keystores, consulte Configurações de Keystore para SSL.

Troca de Signatário

Ao configurar uma conexão SSL, você pode trocar signatários para estabelecer confiança em um certificado pessoal de uma entidade específica. A troca de signatário permite extrair o certificado X.509 do armazenamento de chaves do ponto e incluí-lo no armazenamento de confiança de outra entidade para que as duas entidades do ponto possam se conectar. O certificado do signatário também pode se originar de um CA como um certificado de signatário raiz ou um certificado de signatário raiz do certificado encadeado ou um certificado de signatário intermediário. Também é possível extrair um certificado de signatário diretamente de um certificado auto-assinado, que é o certificado X.509 com a chave pública.

A figura 1 ilustra uma configuração hipotética de armazenamento de chaves e de armazenamento de confiança. Uma configuração de SSL determina quais entidades podem se conectar com outras entidades e as conexões de ponto que são confiáveis por um protocolo de reconhecimento SSL. Se você não tiver o certificado de signatário necessário, o protocolo de reconhecimento falhará porque o ponto não pode ser confiável.
Figura 1. Troca de Signatário
A Figura 1 ilustra uma configuração de keystore e truststore hipotética. Uma configuração de SSL determina quais entidades podem se conectar com outras entidades, e as conexões de ponto que são confiáveis por um handshake SSL. Se você não tiver o certificado de signatário necessário, o handshake falhará porque o ponto não pode ser confiável.

Neste exemplo, o armazenamento de confiança para a Entidade A contém três signatários. A entidade A pode se conectar a qualquer ponto contanto que um dos três signatários valide seu certificado pessoal. Por exemplo, a Entidade A pode se conectar à Entidade B ou C porque os signatários podem confiar em ambos os certificados pessoais assinados. O armazenamento de confiança para a Entidade B contém um signatário. A entidade B pode se conectar apenas à Entidade C e apenas quando o terminal de ponto está utilizando o certificado Entity-C Cert 1 como sua identidade. As portas que utilizam o outro certificado pessoal para a Entidade C não são confiáveis pela Entidade B. A Entidade C pode se conectar apenas à Entidade A.

No exemplo, a configuração de auto-assinado parece representar um relacionamento um-para-um entre o signatário e o certificado. Entretanto, quando uma CA assina um certificado, normalmente ela assina vários de uma vez. A vantagem de usar um único signatário de CA é que ele pode validar os certificados pessoais gerados pela CA para serem utilizados pelos pontos. Entretanto, se o signatário for uma CA pública, você deverá estar ciente de que os certificados assinados podem ter sido gerados para uma empresa diferente de sua entidade de destino. Para sua comunicação interna, as CAs privadas e os certificados auto-assinados são preferíveis às CAs públicas, porque eles permitem isolar as conexões que você deseja que ocorram e impedir aquelas que não deseja que ocorram.

Configurações de SSL

Uma configuração de SSL abrange um conjunto de atributos de configuração que podem ser associados a um terminal ou um conjunto de terminais na topologia do WebSphere Application Server. A configuração de SSL permite criar um objeto SSLContext, que é o objeto JSSE fundamental que o servidor utiliza para obter depósitos de informações de soquete SSL. Os seguintes atributos de configuração podem ser gerenciados:
  • Um alias para o objeto SSLContext
  • Uma versão de protocolo de reconhecimento
  • Uma referência de armazenamento de chaves
  • Uma referência de armazenamento de confiança
  • Um gerenciador de chaves
  • Um ou mais gerenciadores de confiança
  • Uma seleção no nível de segurança de um agrupamento de conjuntos de criptografia ou uma lista específica de conjuntos de criptografia
  • Uma opção de alias de certificado para conexões do cliente e do servidor
Para compreender as particularidades de cada atributo de configuração de SSL, consulte Configurações de SSL.
Nota: O WebSphere não permite que os conjuntos de cifras RC4 na lista de cifras HIGH mantenham o servidor mais seguro por padrão. É possível que uma cifra RC4 estivesse sendo usada por padrão em handshakes SSL antes dessa mudança. Com a remoção das cifras RC4, é provável que uma cifra AES seja usada em seu lugar. Os usuários podem se deparar com uma diminuição no desempenho com o uso de cifras AES mais seguras.

Selecionando Configurações de SSL

Em releases anteriores do WebSphere Application Server, você pode se referir a uma configuração de SSL somente selecionando o alias de configuração de SSL diretamente. Cada terminal seguro era indicado por um atributo de alias que fazia referência a uma configuração válida de SSL em um repertório de configurações de SSL. Ao fazer uma única mudança na configuração, você tinha que reconfigurar muitas referências de alias nos vários processos. Embora o release atual ainda suporte a seleção direta, essa abordagem não é mais recomendada.

O release atual fornece recursos aprimorados para gerenciar configurações de SSL e mais flexibilidade ao selecionar configurações de SSL. Neste release, é possível selecionar a partir de várias abordagens:
Seleção Programática
É possível definir uma configuração de SSL no encadeamento em execução anterior a uma conexão de saída. O WebSphere Application Server garante que a maioria dos protocolos de sistema, inclusive IIOP (Internet Inter-ORB Protocol), JMS(Java Message Service), HTTP (Hyper Text Transfer Protocol) e LDAP (Lightweight Directory Access Protocol), aceita a configuração. Consulte Programmatically specifying an outbound SSL configuration using JSSEHelper API
Seleção Dinâmica
É possível associar uma configuração de SSL dinamicamente com um host, uma porta ou um protocolo de saída de destino específico, utilizando critérios de seleção predefinidos. Quando estabelece a conexão, o WebSphere Application Server verifica se o host de destino e a porta correspondem a um critério predefinido que inclua a parte do domínio do host. Além disso, você pode predefinir o protocolo para uma seleção específica de configuração de SSL de saída e alias de certificado. Consulte Dynamic outbound selection of Secure Sockets Layer configurations para obter maiores informações.

A seleção de saída dinâmica de configurações de Secure Sockets Layer baseia-se nas informações de conexão disponíveis no servidor de modo que o servidor possa corresponder o protocolo de saída, o host ou a porta quando a criação do soquete do cliente ocorrer no com.ibm.websphere.ssl.protocol.SSLSocketFactory. Para conectores de administração do WebSphere como o SOAP e a Chamada de Método Remoto (RMI), as informações de conexão são colocadas no encadeamento e ficam disponíveis até que ocorra a seleção de saída dinâmica. O processo de seleção de saída dinâmica responde às informações de conexão que estão sendo configuradas quando as propriedades SSL são recuperadas de forma semelhante ao que é descrito em Programmatically specifying an outbound SSL configuration using JSSEHelper API.

Quando a conexão de saída estiver sendo feita a partir de aplicativos gravados pelo cliente, partes das informações de conexão podem não estar disponíveis. Alguns desses aplicativos fazem as chamadas de API para um protocolo fazerem a conexão. Por fim, a API chama um dos métodos createSocket() em com.ibm.websphere.ssl.protocol.SSLSocketFactory para concluir o processo. gotcha: Todas as informações de conexão para seleção de saída dinâmica podem não estar disponíveis e talvez você tenha de ajustar o filtro de conexão de seleção de saída dinâmica e preencher com asteriscos (*) a parte ausente das informações de conexão. Como um exemplo, a chamada openConnection() em um objeto da URL chama, por fim, createSocket(soquete java.net.Socket, host de sequência, porta int, autoClose booleano). As informações de conexão podem ser criadas com o host e a porta fornecidos, mas não há protocolo fornecido. Nesse caso, um caractere curinga, um asterisco (*), deve ser usado para a parte do protocolo das informações de conexão de seleção dinâmica.

A maioria dos métodos createSocket() usa um host ou um endereço IP e uma porta como parâmetros. O filtro de conexão de seleção de saída dinâmica pode ser construído com o host e a porta. O método padrão, createSocket(), sem nenhum parâmetro não contém nenhuma informação para construir o filtro de conexão de seleção de saída, a menos que o socket factory tenha sido instanciado com informações de conexão. Se não houver informações disponíveis, então considere o uso de um dos outros métodos de seleção de uma configuração SSL descritos neste tópico. "Seleção Programática" pode ser uma boa opção.

Seleção Direta
É possível selecionar uma configuração de SSL utilizando um alias específico, como em releases anteriores. Esse método de seleção é mantido para retrocompatibilidade porque vários aplicativos e processos dependem das referências de alias.
Seleção de Escopo
É possível associar uma configuração de SSL e seu alias de certificado, que está localizado no armazenamento de chave associado a essa configuração de SSL, com um escopo de gerenciamento do WebSphere Application Server. Essa abordagem é recomendada para gerenciar configurações de SSL centralmente. Os terminais podem ser gerenciados mais eficazmente porque estão localizados em uma visualização de topologia da célula. O relacionamento de herança entre os escopos reduz o número de designações de configuração de SSL que devem ser configuradas.
Toda vez que você associa uma configuração de SSL com um escopo da célula, o escopo do nó na célula herda as propriedades de configuração automaticamente. Entretanto, quando você designa uma configuração de SSL a um nó, a configuração do nó substitui aquela que o nó herda da célula. De modo semelhante, todos os servidores de aplicativos para um nó herdam automaticamente a configuração de SSL para esse nó, a não ser que essas designações sejam substituídas. A menos que você substitua uma configuração específica, a topologia depende das regras de herança do nível de célula até o nível de terminal para cada servidor de aplicativos.
Nota: Se seus aplicativos dependerem das configurações de SSL, definidas como configurações individuais para cada configuração SSL na topologia, mas seus servidores de aplicativos tiverem herdado a configuração de SSL conforme implementado do nível de célula até o nível de terminal, haverá a possibilidade de erros de comunicação ocorrerem entre os servidores (por exemplo, erros de protocolo de reconhecimento). É necessário garantir que seus aplicativos estejam operando de maneira consistente com o gerenciamento central das configurações de SSL.
A visualização de topologia exibe uma árvore de entrada e uma árvore de saída. É possível fazer diferentes seleções de configuração de SSL para cada lado da conexão SSL dependendo com qual o servidor se conectará como uma conexão de saída e com qual o servidor se conectará como uma conexão de entrada. Consulte Central management of SSL configurations para obter maiores informações.
O tempo de execução utiliza uma ordem de precedência para determinar a configuração de SSL a ser escolhida, pois há muitas maneiras de selecionar as configurações de SSL. Considere a seguinte ordem de precedência quando você selecionar uma abordagem de configuração:
  1. Seleção programática. Se um aplicativo definir uma configuração de SSL no encadeamento em execução utilizando a API (Interface de Programação de Aplicativo) com.ibm.websphere.ssl.JSSEHelper, a configuração de SSL será asseguradamente a precedência mais alta.
  2. Critérios de seleção dinâmica para o host de saída e a porta ou o protocolo.
  3. Seleção direta.
  4. Seleção de escopo. A herança de escopo garante que o terminal selecionado esteja associado a uma configuração de SSL e seja herdado por todos os escopos sob ele que não substituam essa seleção.

Configuração do Certificado Encadeado Padrão

Por padrão, o WebSphere Application Server cria um certificado encadeado exclusivo para cada nó. O certificado encadeado é assinado com uma raiz, um certificado auto-assinado armazenado no DmgrDefaultRootStore ou no NodeDefaultRootStore. O WebSphere Application Server não depende mais de um certificado auto-assinado ou o certificado padrão ou fictício enviado com o produto. O armazenamento de chaves padrão key.p12 e o armazenamento de confiança trust.p12 estão armazenados no repositório de configuração no diretório do nó. O certificado raiz padrão é armazenado no root-key.p12 no repositório de configuração sob o diretório do nó.

Todos os nós colocam seus certificados de signatário a partir do certificado raiz padrão neste armazenamento confiável (trust.p12). Além disso, depois da federação de um nó, a configuração de SSL padrão é automaticamente modificada para apontar para o armazenamento de confiança comum, que está localizado no diretório da célula. Agora o nó pode se comunicar com todos os outros servidores na célula.

Todas as configurações contêm um armazenamento de chaves com o sufixo de nome DefaultKeyStore, um armazenamento confiável com o sufixo de nome DefaultTrustStore e um armazenamento de raiz com o sufixo de nome DefaultRootStore. Esses sufixos padrão instruem o tempo de execução do WebSphere Application Server para incluir o signatário raiz do certificado pessoal no armazenamento confiável. Se um armazenamento confiável não terminar com o DefaultKeyStore, os certificados do signatário raiz do armazenamentos de chaves não serão incluídos no armazenamento confiável quando você federar o servidor. É possível alterar a configuração de SSL, mas deve assegurar que a confiança correta seja estabelecida para as conexões administrativas, entre outras.

Para obter informações adicionais, consulte Configuração de Certificado em Cadeia Padrão em SSL [AIX Solaris HP-UX Linux Windows] e [AIX Solaris HP-UX Linux Windows]Web server plug-in default configuration in SSL.

Monitoramento de Expiração de Certificado

O monitoramento do certificado assegura que o certificado encadeado padrão para cada nó não tenha permissão para expirar. A função de monitoramento de expiração de certificado emite um aviso antes dos certificados e signatários serem configurados para expiração. Esses certificados e signatários localizados nos armazenamentos de chaves gerenciados pela configuração do WebSphere Application Server podem ser monitorados. É possível configurar o monitor de expiração para substituir automaticamente um certificado. Um certificado encadeado será recriado com base nos mesmos dados da criação inicial e os assinará com o mesmo certificado raiz que assinou o certificado original. Um certificado auto-assinado ou encadeado também é recriado com base nos mesmos dados utilizados para a criação inicial.

O monitor também pode substituir automaticamente os signatários antigos pelos signatários dos novos certificados encadeados ou auto-assinados nos armazenamentos de chaves gerenciados pelo WebSphere Application Server. As trocas de signatários existentes que ocorreram pelo tempo de execução durante a federação e pela administração são preservados. Para obter mais informações, consulte Certificate expiration monitoring in SSL.

O monitor de expiração é configurado para substituir certificados pessoais encadeados que são assinados por um certificado raiz em DmgrDefaultRootStore ou NodeDefaultRootStore. O certificado é renovado utilizando o mesmo certificado raiz utilizado para assinar o certificado original.

O monitor também pode substituir automaticamente os signatários antigos pelos signatários dos novos certificados nos armazenamentos de chaves gerenciados pelo WebSphere Application Server. As trocas de signatários existentes que ocorreram pelo tempo de execução durante a federação e pela administração são preservados. Para obter mais informações, consulte Certificate expiration monitoring in SSL.

Clientes do WebSphere Application Server: requisitos de troca de signatário

Um novo certificado encadeado é gerado para cada nó durante sua inicialização inicial. Para garantir a confiança, os clientes devem receber os signatários raiz para estabelecer uma conexão. A introdução de certificados encadeados no release atual torna esse processo mais simples. Em vez de trocar o signatário de um certificado auto-assinado de ativação breve, você poderá trocar o signatário raiz de ativação longa que permitirá a confiança preservada nas renovações do certificado pessoal. Além disso, é possível obter acesso aos certificados do signatário de vários nós aos quais o cliente deve se conectar com qualquer uma das seguintes opções (para obter informações adicionais, consulte Instalação segura para recuperação de assinante do cliente em SSL):
  • Um prompt de troca de signatário permite importar certificados de signatário que ainda não estão presentes nos armazenamentos de confiança durante uma conexão com um servidor. Por padrão, esse prompt é ativado para conexões administrativas e pode ser ativado para qualquer configuração de SSL do cliente. Quando esse prompt é ativado, qualquer conexão feita com um servidor no qual o signatário ainda não existe oferece o signatário do servidor juntamente com as informações do certificado e uma compilação HSA (Secure Hash Algorithm) do certificado para verificação. Uma opção é fornecida ao usuário para aceitar essas credenciais. Se as credenciais forem aceitas, o signatário será incluído no armazenamento de confiança do cliente até que o signatário seja explicitamente removido. O prompt de troca de signatário não ocorre novamente ao conectar com o mesmo servidor, a menos que o certificado pessoal seja alterado.
    Atenção: Não é seguro confiar em um prompt de troca de signatário sem verificar a compilação SHA. Um prompt não verificado pode se originar de um navegador quando um certificado não é confiável.
  • É possível executar um script administrativo retrieveSigners de um cliente antes de estabelecer conexões com os servidores. Para fazer download de signatários, nenhuma autoridade administrativa é necessária. Para fazer upload de signatários, você precisa ter autoridade com função de Administrador. O script faz download de todos os signatários de um armazenamento de confiança do servidor especificado para o armazenamento de confiança do cliente especificado e pode ser chamado para fazer download apenas de um alias específico de um armazenamento de confiança. Também é possível chamar o script para fazer upload de signatários para armazenamentos de confiança do servidor. Quando você seleciona o armazenamento de confiança CellDefaultTrustStore como o armazenamento de confiança do servidor especificado e o armazenamento de confiança comum para uma célula, todos os signatários dessa célula são transferidos por download para o armazenamento de confiança do cliente especificado, que é geralmente ClientDefaultTrustStore. Para obter mais informações, consulte retrieveSigners command.
  • É possível distribuir fisicamente aos clientes o armazenamento de confiança comum trust.p12 localizado no diretório da célula do repositório de configuração. Ao fazer essa distribuição, porém, é necessário assegurar-se de que a senha correta tenha sido especificada no arquivo de configuração de SSL do cliente ssl.client.props. A senha padrão para esse armazenamento de confiança é WebAS. Altere a senha padrão antes da distribuição. A distribuição física não é tão eficaz quanto as opções anteriores. Quando são feitas mudanças nos certificados pessoais no servidor, a troca automatizada pode falhar.

Mudanças na Configuração Dinâmica de SSL

O tempo de execução de SSL para o WebSphere Application Server mantém os listeners par a maioria das conexões de SSL. Uma mudança nas configurações de SSL faz com que os listeners de conexão de entrada criem um novo objeto SSLContext. As conexões existentes continuam a usar o objeto SSLContext atual. As conexões de saída utilizam automaticamente as novas propriedades de configuração quando elas são tentadas.

Faça mudanças dinâmicas na configuração de SSL fora das horas de atividade máxima, para reduzir a possibilidade de problemas relacionados à cronometragem e para evitar a possibilidade de reinicialização do servidor. Se você ativar o tempo de execução para aceitar mudanças dinâmicas, altere a configuração de SSL e salve o arquivo security.xml. Suas mudanças são efetivadas quando o novo arquivo security.xml alcança cada nó.

Nota: Se as mudanças na configuração causarem falhas no protocolo de reconhecimento SSL, também poderão ocorrer falhas de conectividade administrativa que podem resultar em interrupções. Neste caso, é necessário reconfigurar as conexões SSL e, em seguida, executar a sincronização manual dos nós para corrigir o problema. Você deve concluir com cuidado quaisquer alterações dinâmicas. É altamente recomendável desempenhar mudanças nas configurações SSL em um ambiente de teste antes de fazê-las em um sistema de produção. Para obter mais informações, consulte Dynamic configuration updates in SSL.

Gerenciamento de Certificados Integrado

O gerenciamento de certificados, que é comparável à funcionalidade do iKeyMan, está, agora, integrado aos painéis de gerenciamento do armazenamento de chaves do console administrativo. Utilize o gerenciamento de certificados integrado para gerenciar certificados pessoais, pedidos de certificados e certificados de signatário localizados nos armazenamentos de chaves. Além disso, é possível gerenciar remotamente os armazenamentos de chaves. Por exemplo, é possível gerenciar um armazenamento de chaves baseado em arquivo que esteja localizado fora do repositório de configuração em qualquer nó do gerenciador de implementação. Também é possível gerenciar remotamente os armazenamentos de chaves de criptografia de hardware do gerenciador de implementação.

Com o gerenciamento de certificado integrado, é possível substituir um certificado encadeado ou auto-assinado juntamente com todos os certificados de signatário espalhados por muitos armazenamentos confiáveis e recuperar um signatário de uma porta remota conectando-se ao host e à porta remotos e interceptando o signatário durante o protocolo de reconhecimento. O certificado é validado primeiro de acordo com a compilação SHA do certificado e, em seguida, o administrador deve aceitar o certificado validado antes que ele possa ser colocado em um armazenamento de confiança.

Quando você faz um pedido de certificado, é possível enviá-lo para uma CA (Autoridade de Certificação). Quando o certificado é retornado, você pode aceitá-lo no console administrativo. Para obter informações adicionais, consulte o Certificate management in SSL.
Dica: Embora a funcionalidade iKeyMan ainda seja enviada com o WebSphere Application Server, configure os armazenamentos de chaves a partir do console administrativo utilizando a funcionalidade de gerenciamento de certificado integrada. O iKeyMan ainda é uma opção quando não é conveniente usar o console administrativo. Para obter mais informações, consulte Gerenciamento de Certificado Usando iKeyman Antes de SSL.

Gerenciamento de Configuração de AdminTask

Os painéis de gerenciamento de configuração de SSL no console administrativo dependem principalmente das tarefas administrativas, que são mantidas e aprimoradas para suportar a função do console administrativo. É possível usar os comandos wsadmin a partir de um prompt de console Java para automatizar o gerenciamento de armazenamentos de chaves, configurações SSL, certificados, etc.

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_sslsecurecom
Nome do arquivo: csec_sslsecurecom.html