Ativar o suporte HTTPS para a Cache Ligada da Microsoft no Linux

Este artigo fornece instruções passo a passo para ativar o suporte HTTPS na Cache Ligada da Microsoft para nós Empresariais em execução num computador anfitrião Linux.

O processo de configuração requer a geração de um Pedido de Assinatura de Certificado (CSR) no seu computador anfitrião, a assinatura do CSR através de PKI empresarial ou pública e, em seguida, a importação para o computador anfitrião.

Pré-requisitos

Antes de configurar a funcionalidade HTTPS, certifique-se de que os seguintes requisitos são cumpridos:

  • O nó de cache está na versão de software ga

    1. Abra portal do Azure e navegue para o recurso Cache Ligada para Empresas que aloja os nós de cache.
    2. Em Gestão de Nós de Cache, localize o nó de cache no qual pretende ativar HTTPS.
    3. Verifique se o nó está na versão de DISPONIBILIDADE – deve mostrar "Sim" ou "N/D" na coluna Migrado .
    4. Se não estiver na versão ga ("Não" na coluna Migrado ), selecione o nó de cache, navegue para o separador Implementação e siga as instruções para reimplementar a Cache Ligada.

  • Acesso a uma Autoridade de Certificação (AC)

    Precisará de acesso à sua PKI empresarial ou a uma AC pública. Se utilizar a PKI empresarial, marcar os requisitos da sua organização para submeter um CSR à AC.

  • Documentar métodos de ligação de cliente

    Tenha em atenção o endereço IP ou o nome do anfitrião (FQDN) que os seus clientes utilizam para ligar ao servidor de Cache Ligada. Este valor será utilizado como uma entrada de Nome Alternativo do Requerente (SAN) durante o processo de geração de um CSR.

  • Garantir a disponibilidade da porta 443

    Para estabelecer uma ligação HTTPS com a Cache Ligada, a porta 443 tem de estar disponível no computador anfitrião. Execute o seguinte comando para marcar:

    sudo ss -tulpn | grep :443

    Reveja o resultado:

    • Sem saída — a porta 443 não está a ser utilizada. Prossiga com a configuração de HTTPS.
    • O resultado contém LISTEN (por exemplo, tcp LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=6))) — A porta 443 já está a ser utilizada por outro serviço. Identifique e pare o serviço em conflito antes de a Cache Ligada poder utilizar a porta 443.

    Dica

    O ss resultado mostra o nome do processo e o PID na última coluna. No exemplo acima, nginx (PID 1234) está a utilizar a porta 443. Pare ou reconfigure o serviço em conflito antes de continuar. Por exemplo, execute sudo systemctl stop nginx para parar o nginx.

  • Verificar a configuração da firewall

    Se a firewall ou o proxy empresarial intercetar o tráfego HTTPS para o servidor de Cache Ligada (por exemplo, através da inspeção TLS), a validação do certificado falhará sempre independentemente da configuração do certificado.

Para obter mais informações sobre qualquer um dos pré-requisitos, consulte a página de referência HTTPS no Linux.

Gerar um Pedido de Assinatura de Certificado (CSR)

Importante

Cada nó de cache precisa do seu próprio CSR/certificado (não pode partilhar):

  • Utilize nomes consistentes: mcc-node1.company.com, mcc-node2.company.com, etc.
  • Documentar que certificado pertence a que nó
  • Os certificados de caráter universal não funcionarão. O CSR/certificado utilizado para a ligação HTTPS à Cache Ligada está exclusivamente associado a cada nó de cache para fins de segurança.

  1. Abra um terminal e navegue para a pasta que contém o pacote de implementação extraído.

  2. Adicione permissões de execução ao script de geração de CSR:

    sudo chmod +x ./generateCsr.sh

  3. Configure os parâmetros para generateCsr.sh e execute o script com os valores especificados.

    Sintaxe básica

    sudo ./generateCsr.sh [Required Parameters] [Subject Parameters] [SAN Parameters]

    Parâmetros Necessários

    Parâmetro Tipo Descrição
    -algo String Algoritmo de certificado: RSA, , ECED25519ouED448
    -keySizeOrCurve String Para RSA: tamanho da chave (2048, 3072, 4096). Para EC: nome da curva (prime256v1, secp384r1)
    -csrName String Nome do ficheiro CSR gerado

    Parâmetros do Requerente

    Parâmetro Obrigatório Descrição Exemplo
    -subjectCommonName Sim Nome comum do certificado "localhost", "example.com"
    -subjectCountry Não Código de país de duas letras "US", "CA", "GB"
    -subjectState Não Estado ou província "WA", "TX", "Ontario"
    -subjectOrg Não Nome da organização "MyCompany", "ACME Corp"

    Aviso

    A configuração do Nome Alternativo do Requerente (SAN) é fundamental para a validação de certificados. O certificado tem de corresponder exatamente à forma como os clientes se ligam à Cache Ligada, caso contrário, os clientes ignoram o nó de cache.

    Por exemplo, se os seus clientes se ligarem através do endereço 192.168.1.100 IP, mas o certificado tiver apenas -sanDns "server.local", a validação do certificado falhará.

    Parâmetros SAN (pelo menos um necessário)

    Parâmetro Descrição Exemplo
    -sanDns Nomes DNS (separados por vírgulas) "localhost,example.com,api.example.com"
    -sanIp Endereços IP (separados por vírgulas) "127.0.0.1,192.168.1.100"
    -sanUri URIs (separados por vírgulas) "https://example.com,http://localhost"
    -sanEmail Email endereços (separados por vírgulas) "admin@example.com,user@domain.com"
    -sanRid IDs registados (separados por vírgulas)
    -sanDirName Nomes de diretórios (separados por vírgulas)
    -sanOtherName Outros nomes (separados por vírgulas)

    Para obter mais detalhes e exemplos baseados em cenários em parâmetros de script CSR, veja a página de referência HTTPS no Linux.

  4. Confirme que o processo de geração de CSR foi concluído com êxito.

    Se encontrar erros, localize o ficheiro com carimbo GenerateCsr.log de data/hora na pasta especificada na saída do script. Procure a linha de saída que começa com "Pode encontrar registos aqui: ..."

    • Formato de ficheiro: GenerateCsr_YYYYMMDD-HHMMSS.log
    • Exemplo: GenerateCsr_20251201_143022.log é um ficheiro criado a 1 de dezembro de 2025 às 14:30:22

  5. Localize o ficheiro CSR gerado na pasta Certificados no seu computador anfitrião e, se necessário, transfira-o.

    A localização da pasta Certificados é especificada na saída do script, começando com "Ficheiro CSR criado em: ...". O diretório termina com (...\Certificates\certs).

Assinar o CSR

  1. Selecione uma Autoridade de Certificação (AC) para assinar o CSR.

    Importante

    A assinatura da AC tem de corresponder a um certificado de raiz no arquivo de raiz fidedigna do cliente.

    • PKI Empresarial: a maioria dos clientes utiliza a infraestrutura PKI interna da organização para assinar o CSR. Contacte a equipa de TI ou de segurança sobre o processo da sua organização para submeter um CSR à sua AC interna.

    • AC pública: se não tiver um PKI empresarial, pode utilizar uma AC pública. Os seguintes recursos podem ajudá-lo a começar:

  2. Submeta o CSR para a AC escolhida e guarde o certificado assinado.

    O certificado assinado tem de estar no formato .crt com codificação X.509. Se a sua AC fornecer outros formatos, marcar página de referência HTTPS no Linux sobre como converter em formato .crt.

    Observação

    Atualmente, a Cache Ligada não suporta formatos protegidos por palavra-passe (.pfx, .p12, .p7b). O suporte será adicionado assim que fizer parte do nosso mapa de automatização de certificados.

  3. Verifique se o certificado assinado está no formato correto.

    Confirme a codificação PEM:

    grep "BEGIN CERTIFICATE" xxxx.crt

    Resultado esperado com êxito:

    -----BEGIN CERTIFICATE-----

  4. Mova o certificado assinado para a pasta Certificados no computador anfitrião Linux.

    Esta será a mesma pasta onde encontrou inicialmente o CSR depois de ter sido gerado.

    Cuidado

    Não partilhe chaves privadas, a Cache Ligada só requer o certificado assinado.

Importar certificado TLS assinado

  1. Abra um terminal e navegue para a localização do instalador da Cache Ligada.

  2. Adicione permissões de execução ao script de importação de certificados:

    sudo chmod +x ./importCert.sh

  3. Configure os parâmetros para importCert.sh e execute o script com os valores especificados.

    Sintaxe básica

    sudo ./importCert.sh [Required Parameters]

    Parâmetros Necessários

    Parâmetro Tipo Descrição
    -certName String Nome de ficheiro completo do certificado TLS assinado (com ou sem extensão .crt)

    Exemplo

    sudo ./importCert.sh -certName "myTlsCert.crt"

  4. Confirme que o processo de importação foi concluído com êxito.

    Se encontrar erros, localize o ficheiro com carimbo ImportCert.log de data/hora na pasta especificada na saída do script. Procure a linha de saída que começa com "Pode encontrar registos aqui: ..."

    • Formato de ficheiro: ImportCert_YYYYMMDD-HHMMSS.log
    • Exemplo: ImportCert_20251201_143022.log é um ficheiro criado a 1 de dezembro de 2025 às 14:30:22

  5. Verifique se o certificado correto foi importado ao executar o ShowCertDetails.sh script.

    Observação

    O ShowCertDetails.sh script está disponível a partir de Linux pacote de implementação v1.10.

    Adicione permissões de execução ao script:

    sudo chmod +x ./ShowCertDetails.sh

    Execute o script:

    sudo ./ShowCertDetails.sh

    Este script apresenta o thumbprint do certificado e a data de expiração do certificado TLS atualmente importado para o nó de cache.

Para obter instruções sobre como validar ainda mais a importação do certificado, veja a página HTTPS na Linux validação.

Desativar o suporte https

Se precisar de reverter a sua Cache Ligada à comunicação apenas HTTP, siga estes passos. Este processo não elimina nada na pasta Certificados – ficheiros CSR, certificados ou registos.

  1. No anfitrião Linux, abra um terminal e navegue para a pasta que contém o pacote de implementação extraído.

  2. Adicione permissões de execução ao script de desativação do TLS:

    sudo chmod +x ./disableTls.sh

  3. Execute o script de desativação (não são necessários parâmetros):

    sudo ./disableTls.sh

  4. Confirme que o processo de desativação foi concluído com êxito.

  5. Depois de o HTTPS ser desativado, os pedidos HTTP devem funcionar enquanto os pedidos HTTPS devem falhar. Veja a página HTTPS no Linux validação para obter instruções sobre como testar isto.

Próximas etapas

  • Last updated on