Os listeners HTTPS usam certificados SSL para habilitar o acesso criptografado e a autenticação de identidade. Este tópico descreve o fluxo completo de uso de certificados no CLB, incluindo seleção e preparação de formato, criação, associação a um listener HTTPS, substituição e renovação após expiração.
Seleção e preparação de certificados
Modos de autenticação
O CLB suporta autenticação unidirecional e mútua:
Autenticação unidirecional: o CLB exige apenas um certificado de servidor. O cliente verifica a identidade do servidor.
Autenticação mútua: o CLB requer um certificado de servidor e um certificado de CA. Servidor e cliente autenticam-se mutuamente.
A maioria dos sites públicos precisa apenas de autenticação unidirecional. Configure a autenticação mútua somente quando precisar verificar a identidade do cliente, como em sistemas corporativos internos ou na autenticação de chamadores de API.
Origens de certificados
O CLB aceita certificados de duas origens:
Alibaba Cloud Certificate Management Service: selecione diretamente um certificado adquirido no Alibaba Cloud Certificate Management Service. Esse método facilita o gerenciamento centralizado e oferece lembretes de expiração e renovação com um clique. Suporta apenas certificados de servidor e não aceita certificados de CA de cliente.
Certificado de terceiros: faça upload de um certificado emitido por outro provedor ou autoassinado. Nesse método, envie manualmente os arquivos de chave pública e chave privada do certificado. Há suporte tanto para certificados de servidor quanto para certificados de CA de cliente.
Um certificado de CA de cliente só pode ser adicionado mediante upload do conteúdo, não sendo possível selecioná-lo no Alibaba Cloud Certificate Management Service. Caso precise criar sua própria CA e emitir certificados de cliente, consulte Generate a CA certificate by using OpenSSL .
Requisitos de formato de certificado
O CLB aceita exclusivamente certificados no formato PEM. Antes de criar um certificado, verifique se o certificado, a cadeia de certificados e a chave privada atendem aos requisitos de formato abaixo. Converta previamente para PEM os certificados em outros formatos. Para mais detalhes, consulte Convert the certificate format.
Tipo de certificado suportado: certificados padrão internacional (RSA).
Algoritmos de chave pública suportados: RSA 1024, RSA 2048 e RSA 4096.
Não é possível fazer upload de arquivos PEM que contenham o campo
BEGIN DH PARAMETERS. As suítes de criptografia ECDHE usadas pelos listeners HTTPS já oferecem perfect forward secrecy, tornando desnecessários os arquivos de parâmetros de aprimoramento de segurança exigidos pelas suítes DHE.
Os requisitos de formato para certificados de chave pública variam conforme a autoridade emissora. Consulte as exigências correspondentes à origem do seu certificado:
Certificado emitido por uma CA raiz
Se o certificado for emitido por uma CA raiz, você recebe um único certificado, sem necessidade de certificados adicionais. Assim, o site configurado torna-se confiável para dispositivos de acesso, como navegadores.
O formato do certificado deve atender aos seguintes requisitos:
Deve começar com
-----BEGIN CERTIFICATE-----, -----END CERTIFICATE-----e terminar com a mesma sequência.Cada linha contém 64 caracteres, exceto a última, que pode ter menos.
O conteúdo do certificado não pode conter espaços.
Certificado emitido por uma CA intermediária
Quando o certificado é emitido por uma CA intermediária, o arquivo obtido contém múltiplos certificados. Combine o certificado do servidor com o certificado intermediário antes de fazer o upload.
O formato da cadeia de certificados deve obedecer aos seguintes critérios:
O certificado do servidor vem primeiro, seguido pelo certificado intermediário, sem linhas em branco entre eles.
O conteúdo do certificado não pode conter espaços.
Não deve haver linhas em branco entre os certificados, e cada linha precisa conter 64 bytes. Para mais informações, consulte RFC1421.
O certificado deve estar em conformidade com o formato exigido. Geralmente, a CA intermediária fornece instruções específicas ao emitir o certificado, e este deve seguir os requisitos de formato definidos pela CA.
O exemplo a seguir ilustra uma cadeia de certificados emitida por uma CA intermediária:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----Requisitos de formato de chave privada RSA
Ao fazer upload de um certificado de servidor, também envie a chave privada correspondente.
O formato da chave privada RSA deve cumprir os seguintes requisitos:
Deve iniciar com
-----BEGIN RSA PRIVATE KEY-----, -----END RSA PRIVATE KEY-----e finalizar com a mesma sequência. Envie esse conteúdo juntamente com a chave.Não pode haver linhas em branco entre as strings. Cada linha deve ter 64 caracteres, podendo a última ter menos. Para mais detalhes, consulte RFC1421.
Caso sua chave privada esteja criptografada — por exemplo, se começar e terminar com -----BEGIN PRIVATE KEY-----, -----END PRIVATE KEY----- ou -----BEGIN ENCRYPTED PRIVATE KEY-----, -----END ENCRYPTED PRIVATE KEY-----, ou ainda se contiver Proc-Type: 4,ENCRYPTED — execute o comando abaixo para convertê-la:
openssl rsa -in old_server_key.pem -out new_server_key.pemEm versões mais recentes do OpenSSL, o comandoopenssl rsagera saída em PKCS#8 por padrão, o que causa falha na conversão. Utilizeopenssl rsa -in old_server_key.pem -out new_server_key.pem -traditionalpara converter corretamente.
Conversão de formato de certificado
Se o seu certificado não estiver no formato PEM, use o OpenSSL para convertê-lo antes de fazer o upload.
DER para PEM
O formato DER é comum na plataforma Java. Os arquivos de certificado geralmente possuem extensão .der, .cer ou .crt.
-
Execute o comando a seguir para converter o certificado:
openssl x509 -inform der -in certificate.cer -out certificate.pem -
Execute o comando abaixo para converter a chave privada:
openssl rsa -inform DER -outform PEM -in privatekey.der -out privatekey.pem
P7B para PEM
O formato P7B é tipicamente utilizado no Windows Server e no Tomcat.
Execute o seguinte comando para converter o certificado:
openssl pkcs7 -print_certs -in incertificate.p7b -out outcertificate.cerPFX para PEM
O formato PFX é frequentemente usado no Windows Server.
-
Execute o comando a seguir para extrair o certificado:
openssl pkcs12 -in certname.pfx -nokeys -out cert.pem -
Execute o comando abaixo para extrair a chave privada:
openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes
Lógica de correspondência de certificados em cenários multidomínio
Um listener HTTPS aceita apenas um certificado padrão. Para usar certificados distintos para vários nomes de domínio no mesmo listener HTTPS, utilize o recurso de domínio adicional.
Ao receber uma solicitação do cliente, o CLB usa o Server Name Indication (SNI) para identificar o domínio requisitado: primeiramente, aplica o certificado configurado para o domínio adicional correspondente; caso não haja correspondência, recorre ao certificado padrão do listener.
Quando um listener usa múltiplos certificados curinga, apenas aquele configurado primeiro corresponde automaticamente a todos os subdomínios associados. Certificados curinga configurados posteriormente não fazem essa correspondência automática. Adicione um domínio adicional para cada subdomínio específico e especifique o certificado curinga correspondente.
Por exemplo, se você configurar primeiro um certificado *.example.com e depois um certificado *.test.com, o comportamento de correspondência será diferente:
|
Domínio acessado pelo cliente |
Correspondência automática de certificado |
Operação necessária |
|
|
Sim. Corresponde automaticamente ao certificado |
Nenhuma configuração adicional necessária. |
|
|
Não. Por padrão, não corresponde automaticamente ao certificado |
Adicione um domínio adicional para |
Observe os pontos abaixo ao usar domínios adicionais:
Entre as instâncias de CLB baseadas em especificação, apenas as guaranteed-performance specifications suportam SNI, sendo estas as únicas compatíveis com domínios adicionais.
O domínio adicional inserido deve corresponder exatamente ao nome de domínio presente no certificado de servidor selecionado.
Um domínio adicional só entra em vigor quando combinado com uma regra de encaminhamento, e o nome de domínio definido nessa regra deve ser idêntico ao domínio adicional.
Por padrão, um listener HTTPS suporta até 3 domínios adicionais, limite que pode ser ampliado para no máximo 10.
Para obter o procedimento de configuração e a descrição completa sobre domínios adicionais, consulte CLB additional domain names.
Limites
Somente listeners HTTPS permitem a associação de certificados. Listeners HTTP transmitem dados em texto simples, enquanto listeners de camada 4, como TCP e UDP, não aceitam associação de certificados. Para habilitar transmissão criptografada nesses casos, implante o certificado diretamente nos servidores de backend.
Certificados não podem ser compartilhados entre regiões ou contas diferentes. Para usar um certificado em várias regiões, selecione todas as regiões desejadas durante a criação. Para uso em múltiplas contas, primeiro Download an SSL certificate na conta onde o certificado foi criado e, em seguida, upload it na conta de destino.
Criar um certificado
Console
-
Conclua as preparações:
Usar certificado emitido pela Alibaba Cloud: garanta que o certificado de servidor necessário já foi adquirido ou enviado no SSL Certificates Service console.
Usar certificado de terceiros: prepare os arquivos de chave pública e chave privada do certificado de servidor no formato PEM. Para autenticação mútua, prepare também o arquivo de chave pública do certificado de CA em formato PEM.
Acesse o CLB console. No painel de navegação à esquerda, escolha CLB > Certificates e clique em Add Certificate.
-
No painel Add Certificate, preencha as configurações conforme a origem do certificado e clique em Create.
Selecione Alibaba Cloud Certificates, escolha o certificado SSL desejado na lista Certificates e defina a Region.
-
Escolha Third-party Certificates e realize as configurações a seguir:
-
Certificate Type: selecione o tipo de certificado a ser enviado. A página exibirá os campos de configuração correspondentes ao tipo escolhido.
Ao optar por Server Certificate, envie o certificado de chave pública e a chave privada, e selecione a Region.
Caso selecione CA Certificate, envie o certificado de chave pública da CA do cliente (usado para verificar a identidade do cliente na autenticação mútua) e escolha a Region.
O conteúdo do certificado enviado é compatível com o formato NGINX. Clique em View Sample para consultar o correct format .
-
API
Chame UploadServerCertificate para enviar um certificado de servidor. Ao usar um certificado emitido pela Alibaba Cloud, passe
AliCloudCertificateIdpara especificar o certificado. Para certificados de terceiros, envie o conteúdo do certificado e a chave privada por meio deServerCertificateePrivateKey.Chame UploadCACertificate para enviar um certificado de CA de cliente, passando o conteúdo do certificado através de
CACertificate.
Associar um certificado a um listener HTTPS
Após a criação, o certificado só entra em vigor quando associado a um listener HTTPS. A seleção do certificado ocorre durante a adição do listener HTTPS. As seções a seguir abordam apenas os itens de configuração relacionados a certificados. Para o processo completo de configuração do listener, consulte Add an HTTPS listener.
Os listeners HTTPS realizam a descriptografia no CLB e encaminham as requisições aos servidores de backend via HTTP, não HTTPS. Portanto, os servidores de backend devem oferecer serviços por HTTP, e configurações como verificações de integridade e portas de backend devem estar alinhadas ao protocolo HTTP (por exemplo, a porta de backend geralmente é a 80).
Console
No assistente de configuração Certificate Management Service, selecione o certificado de servidor criado anteriormente.
-
Opcional: clique em Modify ao lado de Advanced Settings e configure a autenticação mútua e a política de segurança TLS conforme necessário.
Ative a opção Mutual Authentication e selecione o certificado de CA enviado. Se estiver usando uma CA própria para emitir certificados de cliente, consulte Generate a CA certificate by using OpenSSL.
Escolha uma TLS Security Policy. Entre as instâncias de CLB baseadas em especificação, apenas as guaranteed-performance specifications permitem a seleção de uma política de segurança TLS. Para verificar as versões do protocolo TLS e as suítes de criptografia suportadas por cada política, consulte TLS security policies.
Siga o assistente para concluir configurações como servidores de backend e verificações de integridade e envie. Após a criação do listener, o certificado entrará em vigor.
API
Chame CreateLoadBalancerHTTPSListener para associar um certificado ao criar um listener HTTPS. Especifique o certificado de servidor por meio de
ServerCertificateId. Para autenticação mútua, indique o certificado de CA através deCACertificateId.Chame SetLoadBalancerHTTPSListenerAttribute para modificar o certificado associado a um listener HTTPS existente.
Substituir um certificado
Quando um certificado está prestes a expirar, há necessidade de trocar a autoridade emissora ou o certificado apresenta configuração incorreta, substitua-o. O CLB oferece dois métodos de substituição. Escolha aquele adequado ao escopo de impacto. Independentemente do método escolhido, recomendamos que você Verify that the certificate takes effect após concluir a substituição.
|
Item de comparação |
Método 1: Substituir o certificado do listener |
Método 2: Substituir via gerenciamento de certificados |
|
Escopo de impacto |
Apenas o certificado padrão do listener HTTPS atual. |
Todos os listeners e domínios adicionais associados ao certificado. |
|
Cenário indicado |
Necessidade de substituir o certificado de apenas um listener, ou quando também for preciso ajustar a autenticação mútua ou a política de segurança TLS. |
Mesmo certificado usado por múltiplos listeners ou domínios adicionais, com necessidade de substituição simultânea. |
|
Pré-requisito |
Nenhum. |
O certificado deve estar associado a pelo menos um listener ou domínio adicional. |
Ao substituir um certificado, o CLB atualiza a configuração do listener. Durante esse processo, pode ocorrer uma breve interrupção nas conexões HTTPS (cerca de alguns segundos, manifestada como erro de conexão SSL), seguida de recuperação automática. Recomendamos executar essa operação fora dos horários de pico. Caso ocorra alguma anomalia após a substituição, reverta a alteração trocando o certificado do listener de volta para o original.
Método 1: Substituir o certificado do listener
Console
Acesse o CLB console e clique no ID da instância alvo. Na aba Listener, localize o listener HTTPS desejado. Na coluna Operations, clique em Manage Certificate.
No painel Manage Certificate, selecione um novo certificado de servidor na lista suspensa Server Certificate (Default Certificate). Caso também precise ajustar a autenticação mútua ou a política de segurança TLS, modifique-as em Advanced Settings e clique em OK.
Este método substitui apenas o certificado padrão do listener, sem afetar os certificados dos domínios adicionais. Se o listener possuir domínios adicionais configurados, update the certificates of the additional domains separadamente ou use o método a seguir para substituir todos os objetos associados ao certificado de uma só vez.
API
Chame UploadServerCertificate para enviar o novo certificado e obter o respectivo ID.
Chame SetLoadBalancerHTTPSListenerAttribute e passe o novo
ServerCertificateIdpara atualizar o certificado do listener HTTPS.-
Se o listener tiver domínios adicionais configurados, chame SetDomainExtensionAttribute para cada domínio adicional a fim de atualizar seus certificados individualmente.
Atualizar apenas o certificado do listener não atualiza simultaneamente os certificados dos domínios adicionais. Se algum domínio adicional for esquecido, o certificado antigo continuará sendo usado quando o nome de domínio correspondente for acessado.
Método 2: Substituir via gerenciamento de certificados
Ao substituir um certificado pelo gerenciamento de certificados, os certificados de todos os listeners e domínios adicionais associados também são substituídos automaticamente.
Somente certificados associados a pelo menos um listener ou domínio adicional podem ser substituídos.
Acesse o CLB console. No painel de navegação à esquerda, escolha CLB > Certificates.
-
Na página Certificates, localize o certificado que deseja substituir. Na coluna Operations, clique em Change Certificates. Na página Replace Server Certificate, conclua a configuração e clique em Change Certificates.
-
Selecione Create and Replace Certificate.
Escolha Alibaba Cloud Certificates e selecione o novo certificado na lista Certificates.
Opte por Third-party Certificates e cole o conteúdo da chave pública e da chave privada do novo certificado.
Escolha Replace with Existing Certificate e selecione, na lista de certificados existentes, o certificado de servidor que será usado na substituição.
-
Clique em Go to Certificate List. Na página Certificates, confirme que os listeners e domínios adicionais associados foram atualizados com o novo certificado.
Verificar se o certificado entrou em vigor
Acesse o site pelo navegador e verifique o período de validade nos detalhes do certificado. Recomendamos usar o modo anônimo para evitar que o cache influencie a validação.
Caso existam domínios adicionais configurados, valide cada nome de domínio individualmente para confirmar que todos retornam o certificado esperado.
Expiração e renovação de certificados
Após a expiração de um certificado, os clientes que acessarem o site receberão avisos de que o certificado expirou ou é inseguro. Por isso, conclua a substituição antes que o certificado expire.
Ao usar um certificado emitido pelo Alibaba Cloud Certificate Management Service, você se beneficia de lembretes de expiração e renovação com um clique. Recomendamos acompanhar as notificações de expiração nesse service.
Antes que o certificado expire, obtenha um novo certificado (renove ou reemita no Alibaba Cloud Certificate Management Service, ou solicite um novo certificado a uma autoridade emissora terceirizada) e, em seguida, substitua e valide o certificado no CLB conforme descrito nas seções anteriores.
Após renovar ou reemitir um certificado no Certificate Management Service, o certificado usado pelo listener do CLB não é atualizado automaticamente. Ainda é necessário executar a operação de substituição de certificado no CLB.
Mais informações
Cotas
|
Nome da cota |
Descrição |
Valor padrão |
Ajustável |
|
slb_quota_certs_num |
Quantidade de certificados de servidor que podem ser enviados em cada região. |
100 |
|
|
slb_quota_ca_certs_num |
Quantidade de certificados de CA de cliente que podem ser enviados em cada região. |
100 |