Como usar a SNI com o Edge

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

A indicação de nome do servidor (SNI, na sigla em inglês) permite que vários destinos HTTPS sejam veiculados pelo mesmo IP. e porta sem exigir que esses destinos usem o mesmo certificado TLS. Quando o SNI é ativado em um cliente, o cliente passa o nome do host do endpoint de destino como parte do Handshake de TLS. Isso permite que o servidor TLS determine qual certificado TLS deve ser usado para validar da solicitação.

Por exemplo, se o destino da solicitação for https://example.com/request/path, o cliente TLS adiciona a extensão server_name ao handshake de TLS. , conforme mostrado abaixo:

O Edge oferece suporte à SNI para:

  • Solicitações de um app cliente para um proxy de API. Nesse caso, o Edge atua como o TLS servidor
  • Solicitações do Edge para o back-end. Nesse cenário, o Edge atua como o cliente TLS.

Para mais informações sobre a SNI, consulte:

Suporte a SNI para uma solicitação ao proxy de API em Borda

O suporte a SNI para solicitações de proxies de API é controlado por aliases de hosts e host.

Sobre a virtualização hosts e aliases de host

No Edge, um host virtual define o endereço IP e a porta, ou seja, o nome e a porta do DNS, que um proxy de API é exposto e, por extensão, o URL que os apps usam para acessar um proxy de API. O endereço IP/nome DNS corresponde a um roteador de borda, e o número da porta é uma porta aberta entre a VM e um Cloud Router.

Ao criar o host virtual, você também especifica o alias de host dele. Normalmente, esse é o nome DNS do host virtual. Como parte da determinação do proxy de API que processa a solicitação, o roteador compara o cabeçalho Host da solicitação recebida com o lista de aliases de host disponíveis definidos por todos os hosts virtuais.

A combinação de alias de host e número de porta para o host virtual deve ser exclusiva para todos e hosts virtuais na instalação do Edge. Isso significa que vários hosts virtuais podem usar o mesmo número de porta se tiverem aliases de host diferentes.

Um host virtual também define se o proxy de API será acessado usando o protocolo HTTP ou pelo protocolo HTTPS criptografado usando TLS. Ao configurar um host virtual para usar HTTPS, associe o host virtual a um keystore que contenha o certificado e a chave privada usados pelo host virtual durante o handshake de TLS.

Para mais informações sobre hosts virtuais, consulte:

Como a SNI funciona com aliases de host

A SNI permite que você tenha vários hosts virtuais definidos na mesma porta, cada um com diferentes Certificados e chaves TLS. Depois, o Edge determina o host virtual e o par de certificado/chave usado pelo TLS. com base no server_name na solicitação de handshake de TLS.

O Edge Router lê a extensão server_name no handshake de TLS e usa essa solicitação para pesquisar os aliases de host de todos os servidores host. Se o roteador detectar uma correspondência com um alias de host, ele usará o certificado e a chave TLS da o host virtual associado ao alias de host. Se nenhuma correspondência for encontrada, o handshake de TLS falhará.

Em vez de o handshake de TLS falhar, você pode definir um par padrão de certificado/chave, conforme descritos nas próximas seções.

Como definir um par padrão de certificado/chave no Edge para a nuvem

A Apigee fornece um certificado TLS e uma chave privada para oferecer suporte a HTTPS. Embora muitos clientes preferir usar um certificado e uma chave privada próprios no momento da implantação, poderá implantar as APIs usando o certificado e a chave da Apigee.

No Edge para a nuvem, se o roteador não puder corresponder o cabeçalho SNI a um alias de host ou se o não oferecer suporte a SNI, o roteador vai usar o certificado padrão fornecido pela Apigee, que é *.apigee.net.

Como definir um par padrão de certificado/chave no Edge para a nuvem privada

No Edge para a nuvem privada, se nenhuma correspondência for encontrada entre a extensão server_name e os aliases do host. de todos os hosts virtuais, ou se o cliente solicitante não aceitar SNI, você pode configurar o Roteador para usar o certificado/a chave de um host virtual padrão na porta. O host virtual padrão é definido por uma combinação de nome da organização, nome do ambiente e nome do host virtual no formulário:

orgName_envName_vhName

Ele usa o certificado/chave da combinação de orgName_envName_vhName que aparece primeiro na ordem alfabética. Por exemplo, se a solicitação chega na porta 443, e há dois hosts virtuais definidos para a organização example no ambiente prod:

  • nome do host virtual = default
  • nome do host virtual = test

Neste exemplo, o roteador usa o certificado/chave do host virtual chamado default porque example_prod_default vem em ordem alfabética antes de example_prod_test.

Para ativar o host virtual padrão:

  1. No primeiro nó do roteador, edite /opt/apigee/customer/application/router.properties. Se esse arquivo não existir, crie-o.
  2. Adicione a seguinte propriedade ao arquivo para permitir a definição de um host virtual padrão: 
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  3. Reinicie o roteador: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  4. Repita essas etapas em todos os outros roteadores.

Em vez de usar o certificado/chave do host virtual padrão, você pode definir explicitamente o default cert/key no roteador. Use o procedimento a seguir para definir um padrão explícito par de certificados/chaves:

  1. No primeiro nó do roteador, copie o certificado e a chave privada para um local no nó do roteador. que pode ser acessado pelos usuários da Apigee. Por exemplo, /opt/apigee/customer/application.
  2. Mude a propriedade dos arquivos para a Apigee. usuário: 
    chown apigee:apigee /opt/apigee/customer/application/myCert.pem
    chown apigee:apigee /opt/apigee/customer/application/myKey.pem
  3. Editar /opt/apigee/customer/application/router.properties. Se esse arquivo não existir, crie-o.
  4. Adicione as seguintes propriedades ao arquivo para permitir a especificação do cert/key padrão:
    conf_load_balancing_load.balancing.driver.nginx.fallback.server.default.ssl.template.enabled=true
    conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
  5. Defina as propriedades a seguir em router.properties para especificar o local. do certificado e da chave: 
    conf_load_balancing_load.balancing.driver.nginx.ssl.cert=/opt/apigee/customer/application/myCert.pem
conf_load_balancing_load.balancing.driver.nginx.ssl.key=/opt/apigee/customer/application/myKey.pem
  6. Reinicie o roteador: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  7. Repita essas etapas em todos os outros roteadores.

Suporte a SNI para solicitações do Edge a o back-end

O Edge oferece suporte ao uso de SNI de processadores de mensagens para endpoints de destino no Apigee Edge para e implantações de nuvem privada. Por padrão, a SNI é ativada em processadores de mensagens de borda para a nuvem e desativado na nuvem privada.

Usando SNI para o back-end no Edge para a nuvem privada

Para o Edge para a nuvem privada, para ser compatível com versões anteriores dos back-ends de destino atuais, A Apigee desativou o SNI por padrão. Se o back-end de destino estiver configurado para aceitar SNI, será possível ative esse recurso conforme descrito abaixo para sua versão do Edge.

Nenhuma outra configuração específica do Edge é necessária. Se o ambiente de destino estiver configurado para o SNI, o Edge oferece suporte a isso. O Edge extrai automaticamente o nome do host do URL da solicitação e o adiciona à solicitação de handshake de TLS.

Ativar SNI entre o Edge e o back-end para a versão 4.15.07.0x do Edge

Siga o procedimento abaixo para ativar a SNI:

  1. No primeiro nó do Processador de mensagens, abra o arquivo /opt/apigee4/conf/apigee/message-processor/system.properties em um editor.
  2. Defina a seguinte propriedade como verdadeira em system.properties: 
    jsse.enableSNIExtension=true
  3. Reinicie os processadores de mensagens: 
    /opt/apigee4/bin/apigee-service message-processor restart
  4. Repita essas etapas em todos os processadores de mensagens restantes.

Ativar SNI entre o Edge e o back-end para o Edge versão 4.16.01 e posterior

Siga o procedimento abaixo para ativar a SNI:

  1. No primeiro nó do processador de mensagens, edite /opt/apigee/customer/application/message-processor.properties. Se esse arquivo não existir, crie-o.
  2. Adicione a seguinte propriedade ao arquivo: 
    conf_system_jsse.enableSNIExtension=true
  3. Reinicie o processador de mensagens: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Repita essas etapas em todos os processadores de mensagens restantes.