Configure o HTTPS para a documentação do ONLYOFFICE no Docker.

Para uma conexão direta com o ONLYOFFICE Docs, publique a porta 443 do contêiner, mantenha os arquivos de certificado no diretório de dados montado e direcione o contêiner para esses arquivos. Se um proxy reverso já fornecer HTTPS, mantenha o TLS nesse proxy e encaminhe o host e o protocolo originais para o ONLYOFFICE, em vez de habilitar um segundo endpoint TLS por padrão.

Por exemplo, se o nome de host público for docs.example.com, primeiro determine se ele aponta diretamente para o Document Server ou para um proxy. Use apenas a configuração correspondente abaixo.

1. Decida onde termina o HTTPS

O TLS termina onde o HTTPS é descriptografado: seja no contêiner ONLYOFFICE ou em um proxy reverso. Escolha o componente que receberá a conexão pública.

• Acesso direto: os clientes se conectam à https://docs.example.comporta 443 do host, que é mapeada para a porta 443 do contêiner. O contêiner do Servidor de Documentos precisa de um certificado e sua respectiva chave privada.
• Acesso via proxy: os clientes se conectam ao proxy por meio de HTTPS; o proxy encaminha o tráfego para o Servidor de Documentos pela rede interna. Nessa configuração, o certificado normalmente pertence ao proxy. As diretrizes de proxy da ONLYOFFICE exigem os cabeçalhos `Authorization` X-Forwarded-Protoe X-Forwarded-Host`Authorization` para que o aplicativo possa identificar o esquema de solicitação pública e o nome do host.

O mapeamento de portas 443:443não cria HTTPS; ele apenas mapeia portas. Para acesso direto, o contêiner também precisa ler o certificado e a chave. Se o proxy for o proprietário da URL pública, use as instruções oficiais de proxy reverso da ONLYOFFICE .

2. Configure o HTTPS direto no Docker Compose.

Use este caminho quando o contêiner servir HTTPS diretamente. Para acesso público, use um certificado confiável pelos clientes para o nome de host público. Um certificado autoassinado pode criptografar o tráfego, mas os clientes exibirão avisos sobre a identidade, a menos que sejam configurados separadamente para confiar nele.

/var/www/onlyoffice/Data/certsPor padrão, a documentação do ONLYOFFICE armazena os certificados abaixo , e sua configuração atual do Docker lista `certificate` e `key` tls.crtcomo tls.keyos caminhos padrão para certificados e chaves. Os exemplos da documentação nem sempre usaram nomes de arquivo idênticos, portanto, este exemplo define ambos os caminhos explicitamente.

services:
  documentserver:
    # Keep your existing image, environment, networks, and other settings.
    ports:
      - "443:443"
    volumes:
      - ./documentserver-data:/var/www/onlyoffice/Data
    environment:
      SSL_CERTIFICATE_PATH: /var/www/onlyoffice/Data/certs/tls.crt
      SSL_KEY_PATH: /var/www/onlyoffice/Data/certs/tls.key

Este é um excerto, não uma definição de serviço substituta. Mantenha as configurações existentes de imagem, JWT, rede e volume. Em relação ao arquivo Compose, coloque o certificado em ./documentserver-data/certs/tls.crte sua chave correspondente em ./documentserver-data/certs/tls.key. Inclua a cadeia de certificados fornecida pelo seu provedor e certifique-se de que o certificado cubra docs.example.com.

A montagem de diretórios mantém os arquivos fora de um contêiner substituível. Restrinja o acesso à chave privada, garantindo que o contêiner possa lê-la; caso contrário, o HTTPS pode não iniciar. Nunca compartilhe a chave em uma solicitação de suporte.

3. Aplique a alteração sem substituir acidentalmente a implantação.

1. Faça backup do arquivo Compose e do diretório de certificados e, em seguida, confirme se o certificado e a chave correspondem ao nome de host público.
2. Faça as alterações de porta, volume e caminho no serviço existente. Não inicie um segundo contêiner com a mesma porta do host nem descarte os volumes existentes para aplicar o TLS.
3. Recrie o serviço se você alterou suas portas, pontos de montagem ou ambiente. Com o Compose, execute o comando docker compose up -d documentservera partir do diretório que contém o arquivo Compose, substituindo o nome real do seu serviço. Se você apenas substituiu arquivos de certificado em um diretório já montado, reinicie o contêiner existente para que o servidor recarregue os arquivos: docker restart <container_name>.
4. Verifique os registros de inicialização se o HTTPS não funcionar: docker logs <container_name>. Procure por erros de arquivo ausente, permissão ou certificado/chave antes de alterar configurações não relacionadas.

Reiniciar o serviço não adiciona uma montagem nem altera as portas publicadas; recrie o serviço para realizar essas alterações. Substituir arquivos em uma montagem persistente existente não requer uma alteração no Compose.

4. Mantenha o TLS em um proxy reverso quando ele já estiver servindo o domínio.

Se um proxy reverso já estiver encerrado https://docs.example.com, mantenha sua chave privada no proxy. Encaminhe o tráfego por uma rede controlada e defina o parâmetro X-Forwarded-Proto: https`plus` X-Forwarded-Hostpara o nome de host público. Use o exemplo oficial do seu software de proxy.

O cadeado do navegador protege a conexão do cliente ao proxy, e não necessariamente todos os saltos internos. O uso de HTTP em uma rede Docker controlada pode ser adequado para algumas implementações; proteja o salto do proxy para o contêiner se ele atravessar uma rede não confiável.

Outra limitação: alterar o TLS não corrige um JWT inválido, uma porta de firewall bloqueada ou um endereço público incorreto do Servidor de Documentos nas configurações de integração. Se o certificado for válido, mas o carregamento ou a edição de documentos ainda falhar, verifique os logs relevantes do aplicativo e do proxy em vez de regenerar os certificados repetidamente.

Verifique o resultado

A partir de um cliente que consiga acessar o serviço público, abra https://docs.example.come inspecione os detalhes do certificado do navegador. Confirme se o nome do host corresponde, se o certificado está dentro do período de validade e se o navegador não reporta uma autoridade emissora não confiável ou incompatibilidade de nome. Você também pode inspecionar o handshake TLS a partir de um terminal com o comando curl -Iv https://docs.example.com`ls -l`; revise o certificado e a saída da conexão em vez de confiar apenas no carregamento da página.

Por fim, abra um documento a partir do aplicativo de integração. O sucesso do navegador confirma o endpoint público, não todas as configurações de integração ou rotas internas. Para avisos de certificado, verifique novamente o nome do host, a cadeia de certificados, os caminhos, as permissões e a terminação TLS. Se o HTTPS for verificado, mas a edição falhar, verifique os logs e as configurações de autenticação ou roteamento.

Para obter detalhes sobre os caminhos do Docker suportados, variáveis ​​de certificado e opções integradas do Let's Encrypt, consulte a documentação de instalação do Docker e HTTPS do ONLYOFFICE . O comando exato para atualizar uma implantação existente depende de como ela foi criada originalmente; preserve os volumes e as configurações de integração atuais dessa implantação ao aplicar as alterações de TLS relevantes.