Integrar o JIRA ao Apache usando SSL

Integrar o JIRA ao Apache

On this page

Related content

Still need help?

The Atlassian Community is here for you.

Ask the community

As aplicações Atlassian permitem o uso de proxies reversos nos nossos produtos. Entretanto, o suporte da Atlassian não fornece assistência para configurá-los. Consequentemente, a Atlassian não pode garantir o fornecimento de suporte para eles.

Caso seja necessário obter assistência para a configuração, crie uma pergunta no Atlassian Answers.

Esta página descreve como integrar o servidor Apache HTTP (também chamado de httpd) ao JIRA utilizando mod_proxy e mod_ssl para que o Apache opere como proxy reverso em HTTPS. Se for necessária configuração de HTTP, consulte nossa documentação do Integrar o JIRA ao Apache. Configurar o Apache permite executar o JIRA em uma porta HTTP não padrão (como 8080), e os usuários poderão acessar o JIRA usando HTTPS padrão, uma vez que seu tráfego será roteado pelo proxy e criptografado fora da rede.

O Apache pode ser configurado para permitir acesso ao JIRA por qualquer um dos métodos a seguir:

Isso significa que o certificado SSL será gerenciado no Apache, e não no Tomcat. Além disso, a conexão entre o Apache e o Tomcat não será criptografada. Porém, a conexão entre o navegador e a rede externa será criptografada. Isso é adequado a configurações em que o servidor JIRA está dentro da mesma rede que o servidor Apache e conforme ilustrado abaixo.

Navegador cliente -> HTTPS -> Proxy do Apache -> HTTP -> Tomcat (JIRA)

Nesta página:

Essa é uma configuração comum para redes com vários certificados SSL e/ou aplicações web, uma vez que eles todos são gerenciados em um local (Apache).

Se houver necessidade de uma solução mais complicada, consulte a documentação da versão do servidor Apache HTTP, consulte o SME do Apache na sua organização e, se necessário, registre sua pergunta em Atlassian Answers ou entre em contato com um de nossos parceiros Atlassian.

Expanda para obter um exemplo de uma configuração comum do Apache
  1. O JIRA está em execução na porta 8080 em um servidor na LAN que não pode ser acessado externamente (o roteador/firewall não está encaminhado a porta 8080 para ele).
  2. O Apache está configurado em outro servidor (ou no mesmo servidor que o JIRA), que pode ser acessado externamente em HTTPS (443).
  3. O Apache então é acessado por HTTPS no URL adequado URL (VirtualHost), roteando o tráfego de e para o servidor JIRA.

Antes de começar

(warning) Espera-se que o certificado SSL tenha sido assinado por uma CA (Autoridade de Certificação) e esteja no formato PEM antes da configuração do Apache. Para obter assistência ao preparar e gerar o certificado SSL, consulte um fornecedor de SSL (por exemplo, GoDaddy, Verisign, RapidSSL).

Identificar se é melhor usar um domínio, um subdomínio ou um caminho de contexto depende amplamente do tipo de certificado SSL fornecido e também de quaisquer regras de negócio relacionadas às configurações do site. Para o SSL funcionar sem erro, o domínio deve corresponder ao CN (Nome Comum) do certificado.

Expanda para obter mais informações sobre a configuração de FQDN para que corresponda ao CN do certificado

Essa tabela indica que URLs funcionarão com o CN do certificado e também recomenda que URL usar.

FQDN do JIRANome comumVálidoFQDN do JIRA recomendado
https://jira.atlassian.comjira.atlassian.com(tick)https://jira.atlassian.com 
https://jira.atlassian.com *.atlassian.com(tick)https://jira.atlassian.com 
https://jira.atlassian.com atlassian.com(error)https://atlassian.com/jira
https://atlassian.comatlassian.com(tick)https://atlassian.com/jira
https://atlassian.comjira.atlassian.com(error)https://jira.atlassian.com

Um certificado que tenha um CN com asterisco (*) é um certificado curinga e pode dar suporte a qualquer subdomínio daquele domínio. Se você não tiver certeza sobre qual URL usar, consulte o administrador do sistema e o fornecedor de SSL que concedeu o certificado.

Etapa 1: Configurar o Tomcat

  1. Pare o JIRA.

  2. (Opcional: se o JIRA não exigir um caminho de contexto, ignore essa etapa.)

    Edite o server.xml do Tomcat para incluir o caminho de contexto do JIRA necessário. O exemplo a seguir usa path="jira", isso significa que o JIRA está acessível em http://jiraserver:8080/jira, considerando que a porta padrão do JIRA seja usada.

     <Engine defaultHost="localhost" name="Catalina">
            <Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
                <Context docBase="${catalina.home}/atlassian-jira" path="/jira" reloadable="false" useHttpOnly="true">

                    <!--
                     ====================================================================================
                     Note, you no longer configure your database driver or connection parameters here.
                     These are configured through the UI during application setup.
                     ====================================================================================
                    -->
                    <Resource auth="Container" factory="org.objectweb.jotm.UserTransactionFactory" jotm.timeout="60" name="UserTransaction" type="javax.transaction.UserTransaction"/>
                    <Manager pathname=""/>
                </Context>
            </Host>

    (info) Garanta que o valor de path seja definido precedido por uma barra (/). Por exemplo, path="/jira", em vez de path="jira".

  3. Edite o server.xml do Tomcat para incluir um conector separado para fazer proxy das solicitações. Isso requer os atributos scheme, proxyName e proxyPort.  Substitua-os pelo domínio e a porta adequada do proxy, conforme o exemplo a seguir:

    <Service name="Catalina">
&nbsp;
	<!-- Apache Proxy Connector with values for scheme, proxyName and proxyPort -->
        <Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="8080" protocol="HTTP/1.1" redirectPort="8443" useBodyEncodingForURI="true"&nbsp;
            scheme="https" proxyName="jira.atlassian.com" proxyPort="443" />&nbsp;

	<!-- Standard HTTP Connector -->
        <Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="8081" protocol="HTTP/1.1" redirectPort="8443" useBodyEncodingForURI="true" />
  4. Desabilite quaisquer redirecionamentos no Tomcat para HTTPS se tiverem sido habilitados, por exemplo, as alterações para WEB-INF/web.xml in Executar aplicações JIRA em SSL ou HTTPS causarão erros ao usar o Apache.
  5. Inicie o JIRA.
  6. Teste se o JIRA está acessível no conector normal, usando um caminho de contexto, se aplicável. Por exemplo, http://jiraserver:8081/jira.
  7. Teste se o novo conector está em vigor acessando o JIRA no conector proxy adequado. O comportamento varia conforme o caminho do contexto:
    1. Se o caminho de contexto for vazio ou raiz (/), acessar o JIRA por meio do conector proxy (por exemplo, http://jiraserver:8080/) deve levá-lo ao JIRA com um aviso:
    2. Se o caminho de contexto for diferente de vazio ou raiz (/), por exemplo, /jira, visitar o JIRA por meio do conector proxy (por exemplo, http://jiraserver:8080/jira) deverá redirecioná-lo ao proxy configurado (por exemplo, https://jira.atlassian.com/jira). 

Usamos dois conectores do Tomcat diferentes de modo que o teste possa ser feito no JIRA, ignorando o proxy quando necessário, o que é uma etapa útil na resolução de problemas. É esperado que o conector padrão não tenha acesso externo de fora da rede (o firewall não encaminhará nenhuma porta a ele).

Etapa 2: Configurar o servidor Apache HTTP

A instalação do Apache e a configuração de um DNS não são abordadas nesta documentação. Além disso, presume-se que o Apache 2.2 tenha sido instalado e as entradas DNS tenham sido configuradas para o domínio do JIRA. Uma vez que a configuração do Apache é específica para o sistema operacional utilizado, somente algumas distribuições e suas configurações são documentadas no momento.

2.1 Habilitar os módulos proxy

Debian/Ubuntu
Expanda para ver as instruções do Debian/Ubuntu

  1. Habilite o módulo com o seguinte:

    $ sudo a2enmod proxy_http ssl
Considerando proxy de dependência para proxy_http:
Habilitar o módulo proxy.
Habilitar o módulo proxy_http.
Habilitar o módulo ssl.
Consulte /usr/share/doc/apache2.2-common/README.Debian.gz para saber sobre como configurar SSL e criar certificados autoassinados.
Para ativar a nova configuração, é preciso executar:
  service apache2 restart
  2. Reinicie o Apache.
Windows/outro sistema operacional
Expanda para ver as instruções do Windows/outro sistema operacional

  1. Localize e edite o arquivo httpd.conf, adicionando as linhas abaixo, se ainda não existirem:

    LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so 
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule ssl_module modules/mod_ssl.so
  2. Reinicie o Apache.

2.2. Configure o Apache para usar esses módulos

Debian/Ubuntu
Expanda para ver as instruções do Debian/Ubuntu
  1. Mude para o usuário root.
  2. Faça backup da instância existente ou crie uma nova. A criação de uma nova instância não é abordada nesta documentação (copiar o padrão deve ser suficiente).
  3. Modifique a instância existente em $APACHE_INSTALL/sites-available, por exemplo, default-ssl.

  4. Adicione o seguinte em VirtualHost, substituindo jiraserver pelo nome de host do servidor JIRA e também modificando a porta, se necessário.

    No próprio domínio ou subdomínio:
    # Configuração de proxy do JIRA:
<Proxy *>
        Order deny,allow
        Allow from all
</Proxy>

SSLProxyEngine          On
ProxyRequests           Off
ProxyPreserveHost       On
ProxyPass               /       http://jiraserver:8080/
ProxyPassReverse        /       http://jiraserver:8080/

    (info) A ausência da barra no final do URL causará erros de – garanta que ela esteja lá!

    Usar um caminho de contexto:
    # Configuração de proxy do JIRA:
<Proxy *>
        Order deny,allow
        Allow from all
</Proxy>

SSLProxyEngine          On
ProxyRequests           Off
ProxyPreserveHost       On
ProxyPass               /jira       http://jiraserver:8080/jira
ProxyPassReverse        /jira       http://jiraserver:8080/jira

    (info) O caminho usado deve ser idêntico ao caminho de contexto do Tomcat. Por exemplo, não é possível encaminhar /jira para /jira520 sem regras de regravação consideráveis, que nem sempre são confiáveis.

  5. Habilite a instância com o seguinte:

    # a2ensite default-ssl
Enabling site default-ssl.
Para ativar a nova configuração, é preciso executar:
  service apache2 reload
  6. Copie o certificado e a chave privada para os diretórios adequados.

  7. Inclua-os na configuração do Apache no VirtualHost conforme abaixo:

    SSLCertificateFile    /etc/ssl/certs/jira.crt
SSLCertificateKeyFile /etc/ssl/private/jira.key

  8. (OPCIONAL): A configuração do SSLCertificateChainFile conterá os certificados intermediários concedidos pelo fornecedor AC que o assinou. Em seguida, consulte o fornecedor AC para verificar se isso é necessário.

    SSLCertificateChainFile /etc/ssl/certs/jiraintermediate.crt
  9. Recarregue a configuração do Apache.
  10. Teste acessando o JIRA por meio do Apache, por exemplo, http://jira.com ou http://atlassian.com/jira.
Windows/outro sistema operacional
Expanda para ver as instruções do Windows/outro sistema operacional
  1. Localize e edite o arquivo httpd.conf.

  2. Adicione o seguinte em VirtualHost, substituindo jiraserver pelo nome de host do servidor JIRA e também modificando a porta, se necessário.

    No próprio domínio ou subdomínio:

    # Configuração de proxy do JIRA:
<Proxy *>
        Order deny,allow
        Allow from all
</Proxy>

SSLProxyEngine          On
ProxyRequests           Off
ProxyPreserveHost       On
ProxyPass               /       http://jiraserver:8080/
ProxyPassReverse        /       http://jiraserver:8080/

    (info) A ausência da barra no final do URL causará erros de – garanta que ela esteja lá!

    Usar um caminho de contexto:

    # Configuração de proxy do JIRA:
<Proxy *>
        Order deny,allow
        Allow from all
</Proxy>

SSLProxyEngine          On
ProxyRequests           Off
ProxyPreserveHost       On
ProxyPass               /jira       http://jiraserver:8080/jira
ProxyPassReverse        /jira       http://jiraserver:8080/jira

    (info) O caminho usado deve ser idêntico ao caminho de contexto do Tomcat. Por exemplo, não é possível encaminhar /jira para /jira520 sem regras de regravação consideráveis, que nem sempre são confiáveis.

  3. Copie o certificado e a chave privada para os diretórios adequados.

  4. Inclua-os na configuração do Apache no VirtualHost conforme abaixo:

    SSLCertificateFile      /etc/ssl/certs/jira.crt
SSLCertificateKeyFile   /etc/ssl/private/jira.key

  5. (OPCIONAL): A configuração do SSLCertificateChainFile conterá os certificados intermediários concedidos pelo fornecedor AC que o assinou. Em seguida, consulte o fornecedor AC para verificar se isso é necessário.

    SSLCertificateChainFile /etc/ssl/certs/jiraintermediate.crt
  6. Reinicie o Apache.
  7. Teste acessando o JIRA por meio do Apache, por exemplo, http://jira.com ou http://atlassian.com/jira.

2.3 Redirecionar HTTP para HTTPS

Isso pode ser feito com uma das opções a seguir:

  • Configurar o VirtualHost HTTP para encaminhar ao mesmo Tomcat Connector. O Tomcat redirecionará para HTTPS usando os parâmetros scheme, proxyName e proxyPort.  Isso pode ser feito como em nossa documentação de Integrar o JIRA ao Apache.

  • Usando mod_rewrite (esse módulo pode exigir habilitação), adicione o seguinte ao VirtualHost HTTP:

    RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Etapa 3: Configurar o JIRA

  1. Defina Usar compactação gzip como OFF, como em Configurar opções do JIRA. Sabe-se que a compactação GZIP causa problemas de desempenho usando um proxy reverso, especialmente se o proxy também estiver compactando o tráfego.
  2. Defina o URL de base como sendo o FQDN em que o JIRA será acessado, por exemplo, https://jira.atlassian.com. Isso também está localizado em Configurar as opções do JIRA.
    (warning) O JIRA pode ser configurado somente para responder a um único URL, e o URL de base (como em Configurar opções do JIRA) deve corresponder ao URL que os usuários finais estão acessando. A configuração incorreta desse item pode causar problemas significativos no JIRA, como falha no funcionamento correto do fluxo de atividade e dos gadgets do painel.
  3. Teste acessando o JIRA no FQDN (por exemplo: https://jira.atlassian.com), garantindo que o JIRA esteja acessível e todos os gadgets sejam exibidos corretamente.

Solucionar problemas

  • Sessões sequestradas: Alguns usuários relataram problemas de sequestro de sessões de usuário quando o módulo mod_cache estava ativado. Se esses problemas forem encontrados, tente desabilitar o módulo mod_cache.  
    (info) Esse módulo é habilitado por padrão em algumas distribuições do servidor Apache HTTP versão 2.
  • Erros de permissão negada habilitando mod_proxy (e mod_jk) em distribuições Linux que usam SELinux: Os usuários relataram erros de "permissão negada" ao tentarem fazer mod_proxy (e mod_jk) funcionar. Desabilitar o SELinux (/etc/selinux/config) aparentemente corrige isso.

  • Executar o Mac OS X: Desabilite webperfcache, que faz a porta 80 de proxy por padrão. Um usuário relatou isso como a causa provável de problemas de sessão do JIRA na forma de mistura das identidades de usuários, conforme abaixo.
    (warning) Além disso, não recomendamos usar Max OS X, uma vez que ele não tem suporte, como em nossas Plataformas com suporte.

Os servidores OSX habilitam o webperfcache por padrão para hosts virtuais, o que seria ótimo para conteúdo estático, porém, para instâncias dinâmicas (como TODAS as nossas instâncias), ele é inadequado e causará muitos problemas. 
É importante lembrar que, recentemente, houve um problem de sessões no JIRA. Consulte também: -
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/webperfcache.8.html
Infelizmente, mesmo que você desative webperfcache para uma instância, se houver uma única instância habilitada, ainda todas as instâncias terão o proxy por meio de webperfcache, resultando em problemas na sessão.

  • Redirecionamentos em excesso: Tanto Tomcat quanto Apache estão redirecionando, quando apenas um deveria estar. Desabilite o redirecionamento no Tomcat (reverta quaisquer alterações como em Executar o JIRA por SSL ou HTTPS) e verifique se há somente uma direção no Apache.
  • Problemas gerais:
    1. Limpe o cache do navegador e tente novamente.
    2. Verifique se o JIRA funciona conforme o esperado ao executá-lo diretamente do Tomcat e ignorando o Apache. Por exemplo, acessando http://jiraserver:8080, em vez de http://jira.atlassian.com.
    3. Aumente o LogLevel para o Apache a fim de depurar e reinicie-o.
    4. Tente acessar o JIRA e consulte os  Arquivos de registro do Apache para verificar se há algum erro.
    5. Faça uma pergunta em Atlassian Answers para obter assistência.
  • Erro 403 Proibido: 

    • Adicione a linha RequestHeader unset Authorization à página de configuração do Apache para desabilitar os cabeçalhos de autorização.

      <Location /jira>
  RequestHeader unset Authorization
  ProxyPreserveHost On
  ProxyPass http://jiraserver/jira
  ProxyPassReverse http://jiraserver/jira
</Location>

Consulte também

Last modified on Mar 27, 2017

Was this helpful?

Yes
No
Provide feedback about this article

Related content

Powered by Confluence and Scroll Viewport.