Executar aplicações JIRA em SSL ou HTTPS

As aplicações Atlassian permitem o uso de SSL dentro de nossos aplicativos. Entretanto, o suporte da Atlassian não fornece assistência para configurá-lo. Consequentemente, a Atlassian não pode garantir o fornecimento de suporte para ele.

  • Caso seja necessário obter assistência para conversões de certificados, consulte o fornecedor do certificado.
  • Caso seja necessário obter assistência para a configuração, crie uma pergunta no Atlassian Answers.

Saiba que a função SHA-1 está sendo descontinuada devido a fraquezas conhecidas.

As instruções desta página descrevem como executar as aplicações JIRA por SSL ou HTTPS configurando o Apache Tomcat com HTTPS. Esse procedimento abrange apenas os tipos de instalação comuns do JIRA. Não é de forma alguma um guia definitivo ou abrangente para a configuração de HTTPS e pode não se aplicar à sua configuração específica.

Por que é recomendável executar o JIRA por SSL ou HTTPS? Quando as aplicações da web são acessadas pela Internet, sempre há a possibilidade de interceptação de nomes de usuário e senhas por parte de intermediários entre seu computador e o provedor de internet/empresa. Costuma ser uma boa ideia ativar o acesso via HTTPS (HTTP por SSL) e tornar isso um requisito para as páginas quando houver o envio de senhas. Observe que, como consequência, o uso de HTTPS pode resultar em um desempenho mais lento.

Antes de começar

Observe o seguinte antes de começar:

  • O suporte da Atlassian indicará o suporte a SSL à autoridade de certificação (AC) que emite o certificado. As instruções relacionadas a SSL desta página são fornecidas apenas como referência.
  • Para instalações do JIRA feitas usando o Windows Installer:

Se você estiver hospedando o JIRA usando um proxy reverso, como o Apache, consulte Integrar o JIRA ao Apache usando SSL para obter mais informações.

Gerar o Java KeyStore

Nesta seção, você criará um Java KeyStore (JKS), que conterá seus certificados SSL. Os certificados SSL são necessários para que o SSL funcione no JIRA. No mundo do SSL, os certificados se encaixam em duas categorias principais:

CertificadoDescriçãoQuando usarPassos
Autoassinados

São certificados que não foram assinados digitalmente por uma AC, que é um método de confirmar a identidade do certificado que está sendo entregue pelo servidor da web. Eles são assinados por conta própria, daí o nome autoassinados.

Apenas servidores de teste, desenvolvimento ou internos.

1–13
Assinados por ACUm certificado que teve sua identidade digitalmente assinada por uma autoridade de certificação (AC). Permite que os navegadores e clientes confiem no certificado.Servidores de produção.1–21

Os certificados digitais que são emitidos por ACs (autoridades de certificação) terceirizadas e de confiança fornecem a confirmação de que seu site representa de fato sua empresa, verificando, assim, a identidade da sua empresa. Muitas ACs simplesmente verificam o nome do domínio e emitem o certificado. Outras ACs, como a VeriSign, verificam a existência da sua empresa, a propriedade do nome do domínio e sua autoridade para aplicar o certificado, fornecendo um padrão mais alto de autenticação.

Você pode encontrar uma lista de ACs aqui. Algumas das ACs mais conhecidas são:

Recomendamos usar certificados assinados por uma AC.

Se você não puder instalar o Portecle no servidor ou preferir a linha de comando, consulte a seção Instalação por linha de comando abaixo.

  1. Baixe e instale a aplicação Portecle no servidor que executa o JIRA.
    (warning) É uma aplicação terceirizada, sem suporte por parte da Atlassian.
  2. Execute a aplicação como administrador, para que ela tenha as devidas permissões. Além disso, certifique-se de que a variável <JAVA_HOME> esteja apontando para a mesma versão do Java que o JIRA usa. Consulte Setting JAVA_HOME (Definir JAVA_HOME) para obter mais informações.
    (info) Se você estiver executando em um servidor Linux/UNIX, precisará encaminhar o X11 ao se conectar ao servidor (para que possa usar a GUI), conforme abaixo:

    ssh -X user@server
  3. Selecione a opção Criar um novo repositório de chaves:
  4. Selecione o tipo JKS e clique em OK:
  5. Selecione o botão Gerar par de chaves:
  6. Selecione o algoritmo RSA e o tamanho de chave 2048:
  7. Certifique-se de que o Algoritmo de assinatura seja "SHA1withRSA" e, em seguida, edite os detalhes do certificado de acordo com o exemplo abaixo e clique em OK:

    (warning) O Nome comum PRECISA corresponder ao URL do servidor; caso contrário, serão exibidos erros no navegador.
    (info) Se você quiser usar SHA256withRSA, use o algoritmo de assinatura adequado e consulte: Ferramentas de segurança relatam que as cifras SSL padrão são fracas demais.
  8. Escolha um alias para o certificado, por exemplo, jira.
  9. Insira uma senha para o repositório de chaves (a senha padrão usada costuma ser changeit).
  10. Aparecerá uma confirmação de geração bem-sucedida do par de chaves, conforme o exemplo abaixo:
  11. Salve o repositório de chaves em<JIRA_HOME>/jira.jks, com a mesma senha do passo 11. Isso pode ser feito com Arquivo > Salvar Repositório de chaves.

    Se você estiver usando um certificado autoassinado, siga para Configuração do servidor da web usando a ferramenta de configuração do JIRA. Do contrário, siga em frente.

  12. Precisamos gerar a solicitação de assinatura do certificado (CSR) para que a AC assine e confirme a identidade do certificado. Para fazer isso, clique com o botão direito do mouse no certificado e escolha Gerar CSR. Salve-o em <JIRA_HOME>/jira.csr.
  13. Envie a CSR para uma autoridade de certificação para que o certificado seja assinado. Eles fornecerão um certificado assinado (resposta da AC) e um conjunto de certificados de AC de raiz/intermediários.
  14. Importe os certificados de AC de raiz e/ou intermediários com Importar certificado de confiança, repetindo este passo para cada certificado.
  15. Importe o certificado assinado clicando com o botão direito do mouse no certificado jira e selecionando Importar resposta da AC:
  16. Selecione o certificado fornecido pela AC, que deve ser jira.crt. A resposta será "Importação bem-sucedida da resposta da AC".
  17. Verifique isso em Ferramentas > Relatório do repositório de chaves. O certificado deve ser exibido como filho dos certificados de raiz.
  18. Salve o repositório de chaves e siga para a próxima seção.

Configurar o servidor da web usando a ferramenta de configuração do JIRA

Nesta seção, você terminará de configurar a criptografia SSL para o JIRA configurando seu servidor web por meio da ferramenta de configuração do JIRA. Para obter mais informações sobre a ferramenta de configuração do JIRA, consulte Usar a ferramenta de configuração do JIRA.

  1. Execute a ferramenta de configuração do JIRA da seguinte forma:
  2. Clique na guia Servidor da web.
    Captura de tela: Ferramenta de configuração do JIRA — guia Servidor da web
  3. Preencha os campos da seguinte maneira:

    CampoValor
    Porta de controleDeixe como padrão. Você pode alterar o número da porta se quiser. Consulte Changing JIRA's TCP ports (Alterar portas TCP do JIRA).
    PerfilUm perfil é uma configuração predefinida de servidor da web. Você deve escolher um destes quatro valores:
    • Desativado
    • Apenas HTTP 
    • HTTP e HTTPS (redirecionar HTTP para HTTPS)
    • Apenas HTTPS

    Para executar o JIRA por HTTPS, você precisa escolher "HTTP e HTTPS" ou "HTTPS".
    Escolha "HTTP e HTTPS" se quiser executar o JIRA por HTTPS, mas tiver usuários que acessam o JIRA via HTTP. Se você escolher "HTTP e HTTPS", os usuários que tentarem acessar o JIRA via HTTP serão redirecionados para o endereço HTTPS.

    Porta HTTPDeixe como padrão (8080). Você pode alterar o número da porta se quiser. Consulte Changing JIRA's TCP ports (Alterar portas TCP do JIRA).
    Será desativada se você configurar o Perfil como "Apenas HTTPS".
    Porta HTTPSDeixe como padrão (8443). Você pode alterar o número da porta se quiser. Consulte Changing JIRA's TCP ports (Alterar portas TCP do JIRA).
    Caminho do repositório de chavesEspecifique a localização do repositório de chaves do seu certificado. É a localização escolhida quando você salvou o repositório de chaves no passo 13. Deve ser <JIRA_HOME>/jira.jks.
    Senha do repositório de chavesEspecifique a senha do seu repositório de chaves. Se você tiver gerado um certificado autoassinado, é a senha que você especificou para a chave e o repositório de chaves ao gerar o certificado no passo 13.
    Alias do repositório de chavesCada entrada do repositório de chaves é identificada por um alias. Recomendamos usar jira para esse certificado, como no passo 10.
  4. Clique no botão Verificar certificado no repositório de chaves para:
    • Testar se o certificado pode ser encontrado no repositório de chaves.
    • Testar se a senha do repositório de chaves funciona.
    • Testar se a chave pode ser encontrada usando o alias da chave.
  5. Clique no botão Salvar para salvar as alterações.

Configuração avançada

Executar mais de uma instância no mesmo host

Ao executar mais de uma instância no mesmo host, é importante especificar o atributo endereço no arquivo /conf/server.xml, pois, por padrão, o conector escutará em todas as interfaces de rede disponíveis. Assim, especificar o endereço evitará conflitos com conectores sendo executados na mesma porta padrão. Veja a documentação do Tomcat Connector para saber mais sobre a configuração do atributo endereço na documentação The HTTP Connector do Apache Tomcat.

Instalação por linha de comando

Passo 1. Criar o repositório de chaves

  1. Gere o Java KeyStore:

    <JAVA_HOME>/keytool -genkey -alias jira -keyalg RSA -keystore <JIRA_HOME>/jira.jks

    (info)Em vez de nome e sobrenome, insira o URL do servidor, excluindo "https://" (por exemplo, jira.atlassian.com).

  2. Insira uma senha.
  3. Crie a CSR para assinatura usando a senha do passo 2.
  4. Envie a CSR para a AC para que o certificado seja assinado. Eles fornecerão um certificado assinado e uma AC de raiz e/ou intermediária.
    (warning) Se o certificado não precisar ser assinado, vá para o passo 7.
  5. Importe a AC de raiz e/ou intermediária:

    <JAVA_HOME>/keytool -import -alias rootCA -keystore <JIRA_HOME>/jira.jks -trustcacerts -file root.crt
  6. Importe o certificado assinado (fornecido pela AC):

    <JAVA_HOME>/keytool -import -alias jira -keystore <JIRA_HOME>/jira.jks -file jira.crt
  7. Verifique se o certificado existe dentro do repositório de chaves:

    <JAVA_HOME>/keytool -list -alias jira -keystore <JIRA_HOME>/jira.jks

    Deve ser uma PrivateKeyEntry; do contrário, a configuração do certificado não foi concluída com sucesso. Por exemplo:

    jira, Jan 1, 1970, PrivateKeyEntry,
    Certificate fingerprint (MD5): 73:68:CF:90:A8:1D:90:5B:CE:2A:2F:29:21:C6:B8:25

Passo 2. Atualize o Tomcat com o repositório de chaves

  1. Crie um backup do <JIRA_INSTALL>/conf/server.xml antes de editá-lo.
  2. Edite o conector HTTPS para que ele tenha os parâmetros que apontam para o repositório de chaves:

    <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
                  maxHttpHeaderSize="8192" SSLEnabled="true"
                  maxThreads="150" minSpareThreads="25"
                  enableLookups="false" disableUploadTimeout="true"
                  acceptCount="100" scheme="https" secure="true"
                  sslEnabledProtocol="TLSv1.2"
                  clientAuth="false" sslProtocol="TLSv1.2" useBodyEncodingForURI="true"
                  keyAlias="jira" keystoreFile="<JIRA_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

    (info) Coloque o caminho adequado no lugar de <JIRA_HOME> e altere a porta conforme necessário.

    Se a organização não tiver suporte para a versão mais recente do TLS, você pode utilizar a versão 1.0. Substitua:

    sslEnabledProtocol="TLSv1.2"

    Por:

    sslEnabledProtocol="TLS"
  3. Edite o conector HTTP para que ele redirecione para o conector HTTPS:

    <Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="8080" protocol="HTTP/1.1" redirectPort="&lt;PORT_FROM_STEP_1&gt;" useBodyEncodingForURI="true"/>

    (info) Certifique-se de que a <PORT_FROM_STEP_1> foi alterada e apresenta o valor adequado. Neste exemplo, seria 8443.

  4. Salve as alterações no arquivo server.xml.
  5. Se o redirecionamento para HTTPS for usado (o que é recomendado), edite o arquivo <JIRA_INSTALL>/WEB-INF/web.xml e adicione a seguinte seção no final do arquivo, antes de fechar </web-app>. Neste exemplo, todos os URLs, exceto anexos, são redirecionados de HTTP para HTTPS.

    <security-constraint>
    	<web-resource-collection>
    		<web-resource-name>all-except-attachments</web-resource-name>
    		<url-pattern>*.jsp</url-pattern>
    		<url-pattern>*.jspa</url-pattern>
    		<url-pattern>/browse/*</url-pattern>
    		<url-pattern>/issues/*</url-pattern>
    	</web-resource-collection>
    	<user-data-constraint>
    		<transport-guarantee>CONFIDENTIAL</transport-guarantee>
    	</user-data-constraint>
    </security-constraint>
  6. Reinicie o JIRA depois de salvar as alterações.

Você também pode redirecionar os usuários de URLs HTTP para URLs HTTPS escolhendo o perfil "HTTP e HTTPS" na ferramenta de configuração do JIRA. Isso redirecionará todos os URLs HTTP para URLs HTTPS.

Se você quiser redirecionar apenas algumas páginas para HTTPS, precisará fazer isso manualmente. Para isso, selecione o perfil "Apenas HTTPS" na ferramenta de configuração do JIRA e salve a configuração. Em seguida, crie um arquivo htaccess no servidor da web para redirecionar manualmente URLs HTTP para URLs HTTPS correspondentes.

Solucionar problemas

Apresentamos aqui algumas dicas para solução de problemas se você estiver usando uma chave autoassinada criada pelo Portecle, conforme descrito acima.

Ao inserir "https://localhost:" em seu navegador, se receber uma mensagem similar a "Não foi possível estabelecer uma conexão com o servidor no localhost:8443", veja se há mensagens de erro no arquivo de log logs/catalina.out . Veja abaixo alguns dos possíveis erros e suas explicações.

Click here to expand...
  • Problemas SSL + Apache + IE: algumas pessoas já relataram erros ao fazer upload de anexos por SSL usando o IE. Isso se deve a um bug do IE e pode ser resolvido no Apache configurando:

    BrowserMatch ".MSIE." \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
    

    O Google tem muito mais informações sobre isso.

  • Não é possível encontrar o repositório de chaves:

    java.io.FileNotFoundException: /home/user/.keystore (O arquivo ou diretório não existe)
    

    Isso indica que o Tomcat não conseguiu encontrar o repositório de chaves. O utilitário de repositório de chaves cria o repositório de chaves como um arquivo chamado .keystore no diretório inicial do usuário atual. Para Unix/Linux, o diretório inicial provavelmente será /home/<username>. Para Windows, provavelmente será C:\Documents And Settings\<UserName>.

    Certifique-se de que está executando o JIRA como o mesmo usuário que criou o repositório de chaves. Se não for esse o caso, ou se você estiver executando o JIRA no Windows como um serviço, precisará especificar onde o arquivo do repositório de chaves está no arquivo conf/server.xml. Adicione o seguinte atributo à tag do conector do qual você removeu o comentário:

    keystoreFile="<location of keystore file>"
    

    Isso também pode acontecer ("Não foi possível encontrar /root/.keystore") se você adicionar um atributo keystoreFile ao conector http no arquivo server.xml, em vez do conector https.

  • A resposta do certificado e o certificado no repositório de chaves são idênticos:

    keytool error: java.lang.Exception: Certificate reply and certificate in keystore are identical
    

    Esse erro acontecerá se você tiver nomes ou digitais idênticas, que é o resultado da tentativa de recriar o certificado em seu repositório de chaves existente. Caso seja necessário recriar ou atualizar o certificado, você pode remover o repositório de chaves existente e criar um novo repositório de chaves do zero. Nesse caso, criar um novo repositório de chaves e adicionar os certificados relacionados resolverá o problema. O caminho padrão para eles nessa documentação é $JAVA_HOME/jre/lib/security/cacerts

  • Senha incorreta:

    java.io.IOException: Keystore was tampered with, or password was incorrect

    Você usou uma senha diferente de "changeit". Você precisa usar "changeit" tanto para a senha do repositório de chaves quanto para a senha da chave para o Tomcat, ou, se quiser usar uma senha diferente, precisa especificá-la usando o atributo keystorePass da tag do conector, conforme descrito acima.

  • As senhas não são iguais:

    java.io.IOException: Cannot recover key
    

    Você especificou valores diferentes para a senha do repositório de chaves e para a senha da chave para o Tomcat. As duas senhas precisam ser iguais.

  • Certificado errado:

    javax.net.ssl.SSLException: No available certificate corresponds to the SSL cipher suites which are enabled.
    

    Se o repositório de chaves tiver mais de um certificado, o Tomcat usará o primeiro retornado, a menos que especificado de outra maneira no conector SSL no arquivo conf/server.xml.

    Adicione o atributo keyAlias à tag do conector do qual você removeu o comentário, com o alias relevante, por exemplo:

     <Connector port="8443" maxHttpHeaderSize="8192"
    maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
    enableLookups="false" disableUploadTimeout="true" useBodyEncodingForURI="true"
    acceptCount="100" scheme="https" secure="true"
    clientAuth="false" sslProtocol="TLS"
    keystoreFile="/opt/local/.keystore"
    keystorePass="removed"
    keyAlias="tomcat"/>
  • Usar o Apache Portable Runtime (APR):

    O APR usa um sistema SSL diferente, e você verá uma exceção como esta em seus logs:

     SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
    LifecycleException:  Protocol handler initialization failed: java.lang.Exception: No Certificate file specified or invalid file format

    O motivo disso é o fato de o conector do APR usar OpenSSL e não poder usar o repositório de chaves da mesma maneira. É possível corrigir isso de duas formas:


    • Use o Http11NioProtocol para identificar conexões SSL. Edite o arquivo server.xml para que a tag do conector SSL da qual você acabou de remover o comentário especifique o Http11NioProtocol ao invés do protocolo APR.

      <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
        maxHttpHeaderSize="8192" SSLEnabled="true" keystoreFile="${user.home}/.keystore"
        maxThreads="150" enableLookups="false" disableUploadTimeout="true"
        acceptCount="100" scheme="https" secure="true"
        clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>
    • Configure o conector para que use o protocolo APR. Isso só será possível se você tiver certificados e chaves privadas com codificação PEM. Se você usou OpenSSL para gerar a chave, então terá esses arquivos com codificação PEM. Para todos os outros casos, entre em contato com o fornecedor de certificados para obter assistência.

      <Connector
        port="8443" maxThreads="200"
        scheme="https" secure="true" SSLEnabled="true"
        SSLCertificateFile="${user.home}/certificate.pem"
        SSLCertificateKeyFile="${user.home}/key.pem"
        clientAuth="optional" SSLProtocol="TLSv1"/>
      
  • Habilitar a autenticação de cliente: para habilitar a autenticação de cliente no Tomcat, certifique-se de que o valor do atributo clientAuth em seu elemento Connector do arquivo server.xml do Tomcat seja true.

    <Connector
    	...
    	clientAuth="true"
    	... />

    Para obter mais informações sobre os parâmetros de elemento do Connector consulte a documentação do Tomcat 8 sobre como usar a configuração do SSL.

Last modified on Mar 27, 2017

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.