Você está visualizando a documentação do Apigee Edge.
Acesse a
documentação da
Apigee X. info
A Server Name Indication (SNI) permite que várias destinações HTTPS sejam veiculadas pelo mesmo endereço IP e porta, sem exigir que elas usem o mesmo certificado TLS. Quando a SNI é ativada em um cliente, ele transmite o nome do host do endpoint de destino como parte do handshake inicial de TLS. Isso permite que o servidor TLS determine qual certificado TLS deve ser usado para validar a solicitação.
Por exemplo, se o destino da solicitação for https://example.com/request/path
,
o cliente TLS vai adicionar a extensão server_name
à solicitação de
handshake TLS, conforme mostrado abaixo:
O Edge oferece suporte a SNI para:
- Solicitações de um app cliente para um proxy de API. Nesse cenário, o Edge atua como o servidor TLS.
- Solicitações do Edge para o back-end. Nesse cenário, o Edge atua como o cliente TLS.
Para mais informações sobre SNI, consulte:
- https://en.wikipedia.org/wiki/Server_Name_Indication
- http://blog.layershift.com/sni-ssl-production-ready/
Suporte a SNI para uma solicitação de proxy de API no Edge
O suporte a SNI para solicitações de proxies de API é controlado por aliases de host e hosts virtuais.
Sobre hosts virtuais e aliases de host
Com o Edge, um host virtual define o endereço IP e a porta, ou o nome e a porta do DNS, em 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 no roteador.
Ao criar o host virtual, você também especifica o alias do host virtual.
Geralmente, é 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 de entrada com a
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 do host virtual precisa ser exclusiva para todos os 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 da API é acessado usando o protocolo HTTP ou o protocolo HTTPS criptografado usando TLS. Ao configurar um host virtual para usar HTTPS, associe o host a um keystore que contenha o certificado e a chave privada usados pelo host durante o handshake de TLS.
Para mais informações sobre hosts virtuais, consulte:
- Sobre hosts virtuais
- Como configurar o acesso TLS a uma API para a nuvem particular
- Keystores e Truststores
Como o SNI funciona com aliases de host
O SNI permite que você tenha vários hosts virtuais definidos na mesma porta, cada um com certificados e chaves TLS diferentes. O Edge determina o host virtual e o par de certificado/chave usado pelo TLS,
com base na extensão server_name
na solicitação de handshake do TLS.
O Edge Router lê a extensão server_name
na solicitação de handshake
TLS e a usa para pesquisar os aliases de host de todos os hosts
virtuais. Se o roteador detectar uma correspondência com um alias de host, ele vai usar o certificado e a chave TLS do
host virtual associado ao alias. Se nenhuma correspondência for encontrada, o handshake do TLS vai falhar.
Em vez de falhar na negociação TLS, você pode definir um par de certificado/chave padrão, conforme descrito nas próximas seções.
Como definir um par de chave/certificado padrão no Edge para a nuvem
A Apigee fornece um certificado TLS e uma chave privada para oferecer suporte a HTTPS. Embora muitos clientes prefiram usar o próprio certificado e a chave privada no momento da implantação, você pode implantar suas APIs usando o certificado e a chave da Apigee.
No Edge para a nuvem, se o roteador não conseguir associar o cabeçalho SNI a um alias de host ou se o cliente não oferecer suporte a SNI, o roteador vai usar o certificado padrão fornecido pela Apigee, que é *.apigee.net.
Como definir um par de chave/certificado padrão no Edge para a nuvem privada
No Edge para a nuvem privada, se não houver correspondência entre a extensão server_name
e os aliases de host de todos os hosts virtuais ou se o cliente solicitante não oferecer suporte a SNI, será possível configurar o Router para usar o certificado/chave de um host virtual padrão na porta. O host virtual padrão é
definido por uma combinação do nome da organização, do ambiente e do host virtual, no
formato:
orgName_envName_vhName
O roteador usa o certificado/chave da combinação de orgName_envName_vhName que
aparece primeiro em ordem alfabética. Por exemplo, 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 antes de example_prod_test
em ordem alfabética.
Para ativar o host virtual padrão:
- No primeiro nó do roteador, edite
/opt/apigee/customer/application/router.properties
. Se esse arquivo não existir, crie-o. - Adicione a propriedade a seguir ao arquivo para definir um host virtual padrão:
conf_load_balancing_load.balancing.driver.nginx.fallback.conf.enabled=true
- Reinicie o roteador:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- Repita essas etapas em todos os roteadores restantes.
Em vez de usar o certificado/chave do host virtual padrão, defina explicitamente o certificado/chave padrão no roteador. Use o procedimento abaixo para definir um par de chave/certificado padrão explícito:
- No primeiro nó do roteador, copie o certificado e a chave privada para um local no nó do roteador que seja acessível pelo usuário da apigee. Por exemplo,
/opt/apigee/customer/application
. - Mude a propriedade dos arquivos para "apigee. user:
chown apigee:apigee /opt/apigee/customer/application/myCert.pem
chown apigee:apigee /opt/apigee/customer/application/myKey.pem
- Editar
/opt/apigee/customer/application/router.properties
. Se esse arquivo não existir, crie-o. - Adicione as propriedades a seguir ao arquivo para especificar o certificado/chave 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 - 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
- Reinicie o roteador:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- Repita essas etapas em todos os roteadores restantes.
Suporte a SNI para solicitações do Edge para o back-end
O Edge oferece suporte ao uso de SNI de processadores de mensagens para segmentar endpoints no Apigee Edge para implantações de nuvem e nuvem privada. Por padrão, o SNI é ativado nos processadores de mensagens de borda para a nuvem e desativado na nuvem privada.
Como usar SNI no back-end no Edge para a nuvem privada
Para que o Edge for Private Cloud seja compatível com versões anteriores dos back-ends de destino, a Apigee desativou o SNI por padrão. Se o back-end de destino estiver configurado para oferecer suporte ao SNI, será possível ativar 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 SNI, o Edge será compatível com ele. O Edge extrai automaticamente o nome de host do URL da solicitação e o adiciona à solicitação de handshake de TLS.
Ativar o SNI entre o Edge e o back-end para a versão 4.15.07.0x do Edge
Use o procedimento a seguir para ativar o SNI:
- No primeiro nó do processador de mensagens, abra o arquivo
/opt/apigee4/conf/apigee/message-processor/system.properties
em um editor. - Defina a seguinte propriedade como verdadeira em
system.properties
:jsse.enableSNIExtension=true
- Reinicie os processadores de mensagens:
/opt/apigee4/bin/apigee-service message-processor restart
- Repita essas etapas em todos os outros processadores de mensagens.
Ativar o SNI entre o Edge e o back-end para a versão 4.16.01 e mais recentes do Edge
Use o procedimento a seguir para ativar o SNI:
- No primeiro nó do processador de mensagens, edite
/opt/apigee/customer/application/message-processor.properties
. Se esse arquivo não existir, crie-o. - Adicione a seguinte propriedade ao arquivo:
conf_system_jsse.enableSNIExtension=true
- Reinicie o processador de mensagens:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Repita essas etapas em todos os outros processadores de mensagens.