CDN:Guia de solução de problemas de HTTPS

Vários erros podem ocorrer ao fazer upload de um certificado SSL personalizado no console do CDN. Tipos comuns de erros e soluções:

• Formato de certificado inválido: O CDN suporta apenas certificados no formato PEM. Certifique-se de que o conteúdo do certificado comece com -----BEGIN CERTIFICATE----- e termine com -----END CERTIFICATE-----, e que cada linha contenha tipicamente 64 caracteres. Se o seu certificado estiver nos formatos DER, P7B ou PFX, converta-o primeiro para o formato PEM.

• Formato de chave privada inválido: O cabeçalho do arquivo de chave privada deve corresponder ao algoritmo da chave: -----BEGIN RSA PRIVATE KEY----- (formato PKCS#1) para chaves RSA, e -----BEGIN EC PRIVATE KEY----- para chaves ECC/SM2. Se sua chave privada começar com -----BEGIN PRIVATE KEY----- (formato PKCS#8), converta-a antes de fazer o upload: execute openssl rsa -in old_server_key.pem -out new_server_key.pem para chaves RSA, ou openssl ec -in old_server_key.pem -out new_server_key.pem para chaves ECC/SM2. Além disso, a chave privada não pode ser protegida por senha. Para saber como remover a proteção por senha, consulte Remover proteção por senha de um arquivo de chave privada.

  Nota

  Para executar o comando openssl ec mencionado acima em uma chave SM2 (criptografia nacional chinesa), você deve usar OpenSSL 1.1.1 ou posterior (SM2 foi introduzido na versão 1.1.1) compilado com suporte ao algoritmo SM2. Caso contrário, o comando reportará um erro diretamente, que pode ser atribuído equivocadamente ao próprio arquivo de chave privada.

  Se o seu OpenSSL não suportar SM2, recomendamos usar a ferramenta de certificado SM2 fornecida pelo Alibaba Cloud Certificate Management Service ou hospedar o certificado diretamente no console.

• Incompatibilidade entre certificado e chave privada: O certificado e a chave privada enviados devem formar um par. Para chaves RSA, execute os seguintes comandos para comparar se os valores do módulo são idênticos:

  openssl x509 -noout -modulus -in your_cert.pem | openssl md5
  openssl rsa -noout -modulus -in your_key.pem | openssl md5

  Chaves ECC/SM2 não possuem módulo. Compare as chaves públicas executando os seguintes comandos respectivamente. Se as saídas forem idênticas, o certificado e a chave privada correspondem:

  openssl x509 -pubkey -noout -in your_cert.pem
  openssl ec -pubout -in your_key.pem

  Se não tiver certeza sobre o tipo de chave, use o método genérico abaixo, aplicável tanto a RSA quanto a ECC. Se os valores MD5 das duas linhas de saída forem idênticos, o certificado e a chave privada correspondem:

  openssl x509 -pubkey -noout -in your_cert.pem | openssl md5
  openssl pkey -pubout -in your_key.pem | openssl md5

• Incompatibilidade de nome de domínio do certificado: O CN ou SAN do certificado deve incluir o nome de domínio acelerado. Comando de verificação: openssl x509 -in cert.pem -noout -text | grep -E -A1 "Subject:|Subject Alternative Name"

• Certificado ou chave privada muito longos: O console impõe um limite de tamanho para o conteúdo enviado. Verifique o seguinte: se a cadeia de certificados contém linhas em branco extras, caracteres invisíveis ou cabeçalho BOM (exiba caracteres invisíveis em um editor de texto e remova-os); se o certificado da CA raiz foi colado na cadeia de certificados por engano (envie apenas o certificado do servidor e os certificados intermediários); se a chave privada foi colada no campo de certificado (ou vice-versa).

• Certificado expirado: Execute openssl x509 -in your_cert.pem -noout -dates para verificar o período de validade do certificado.

Para requisitos específicos de formato e métodos de conversão, consulte Formato de certificado.

Se uma chave privada for protegida por senha, um erro de formato inválido será reportado durante o upload. É necessário remover a proteção por senha primeiro:

1. Verifique se a chave privada é protegida por senha

   Para uma chave privada criptografada com RSA, execute o seguinte comando usando OpenSSL. Se for solicitada a mensagem Enter pass phrase for <encrypted private key file>:, a chave está criptografada. Se as informações da chave privada forem exibidas diretamente, a chave não está criptografada. Se um erro for reportado, a chave privada não é um arquivo criptografado com RSA:

   openssl rsa -in <encrypted private key file> -text -noout

   Para uma chave privada criptografada com ECC/SM2, execute o seguinte comando para verificar:

   openssl ec -in <encrypted private key file> -text -noout

2. Descriptografe a chave privada

   Se o algoritmo de criptografia do certificado for RSA, execute o seguinte comando para descriptografar a chave privada:

   openssl rsa -in <encrypted private key file> -passin pass:<private key password> -out <decrypted private key file>

   Se o algoritmo de criptografia do certificado for ECC ou SM2, execute o seguinte comando para descriptografar a chave privada:

   openssl ec -in <encrypted private key file> -passin pass:<private key password> -out <decrypted private key file>

Possíveis causas e soluções:

1. O certificado curinga foi implantado em outros nomes de domínio: Após a implantação de um certificado curinga em outros nomes de domínio do CDN, se um novo nome de domínio precisar reutilizar o mesmo certificado, ele não poderá ser selecionado diretamente na lista padrão de certificados. Você deve implantá-lo usando o método de upload personalizado no console do CDN. Depois disso, poderá usar o recurso de implantação de certificado no console do Certificate Management Service.

2. O nome de domínio vinculado ao certificado difere do nome de domínio acelerado: Verifique se o nome de domínio vinculado ao certificado corresponde ao nome de domínio acelerado atual do CDN. Observe a diferença entre dois casos: um certificado de domínio único (como um vinculado apenas a example.com) não pode ser usado para o subdomínio image.example.com, sendo necessário solicitar um certificado separado para esse subdomínio; já um certificado curinga (como *.example.com) corresponde a todos os subdomínios no mesmo nível (como image.example.com e api.example.com).

3. Incompatibilidade de conta: Certifique-se de que o certificado e o nome de domínio do CDN pertençam à mesma conta Alibaba Cloud.

4. O certificado gratuito não inclui o prefixo www: Ao solicitar um certificado SSL gratuito, o prefixo www não é adicionado automaticamente. Você deve inserir manualmente o nome de domínio completo para solicitar.

5. O formato do nome de domínio impede a correspondência automática: Se a correspondência automática falhar devido ao formato do nome de domínio (como domínio raiz versus subdomínio), recomendamos criar uma tarefa de implantação no console do Certificate Management Service para implantar o certificado no CDN, ou baixar o arquivo de certificado e configurá-lo usando o método de upload personalizado.

Se o certificado ainda não aparecer na lista de recursos, solucione o problema na seguinte ordem:

1. Confirme se o nome de domínio foi adicionado ao CDN. Faça login no console do CDN, acesse a página Domain Names e verifique se o nome de domínio alvo está na lista. A lista de nomes de domínio associados do service de certificado exibe apenas nomes de domínio que foram adicionados ao CDN. A lista estará vazia se o novo nome de domínio não tiver sido adicionado.

2. Confirme se o nome de domínio vinculado ao certificado abrange o nome de domínio acelerado. Um certificado curinga (como *.example.com) abrange todos os subdomínios no mesmo nível, mas não cobre subdomínios de níveis mais profundos (como a.b.example.com) ou o próprio nome de domínio pai (como example.com). Se o nome de domínio vinculado ao certificado não corresponder ao nome de domínio acelerado, o certificado não aparecerá na lista selecionável.

3. Execute as operações em ordem: primeiro configure um certificado HTTPS para o nome de domínio no console do CDN (selecione um certificado existente ou faça upload de um personalizado). Após isso, realize o gerenciamento subsequente por meio do recurso de implantação de product cloud no console de certificados. O recurso de implantação de product cloud no console de certificados depende da configuração no lado do console do CDN, portanto, a configuração do certificado no console do CDN deve ser concluída primeiro.

Para as operações específicas de configuração de um certificado HTTPS, consulte Configurar um certificado HTTPS.

Ao fazer upload de um certificado do tipo Custom Certificate (Certificate+Private Key), se o sistema reportar que o certificado é duplicado, significa que o mesmo conteúdo de certificado já existe no sistema. Por exemplo, o mesmo certificado pode ter sido enviado anteriormente para outro nome de domínio. Soluções:

• Reutilize o certificado existente (recomendado): Não é necessário fazer o upload novamente. Na página de configuração de HTTPS do console do CDN, alterne a source do certificado para Existing Certificate, pesquise e selecione o certificado na lista e implante-o diretamente.

• Upload novamente é realmente necessário: Altere o nome do certificado e faça o upload novamente.

Sintoma: Após fazer upload de um certificado curinga para o nome de domínio acelerado, o navegador reporta um erro de certificado ao acessar nomes de domínio de terceiro nível ou mais profundos.

Possível causa: De acordo com a especificação de correspondência de nomes de domínio de certificados HTTPS (RFC 6125), um certificado curinga corresponde apenas aos nomes de domínio do próximo nível em relação ao nível onde o curinga reside. Por exemplo, o certificado *.abc.com corresponde a a.abc.com e b.abc.com, mas não corresponde ao nome de domínio pai abc.com ou ao nome de domínio de terceiro nível x.a.abc.com.

Solução:

• Para nomes de domínio de níveis mais profundos, solicite um certificado curinga do nível correspondente. Por exemplo, se precisar acelerar nomes de domínio de terceiro nível como 1.cdn.abc.com e 2.cdn.abc.com, use o certificado curinga *.cdn.abc.com.

• Se também for necessário cobrir o nome de domínio pai abc.com, solicite um certificado separado para o domínio pai ou use um certificado SAN (Subject Alternative Name) que inclua tanto abc.com quanto *.abc.com.

Sintoma: Ao configurar um certificado gratuito para um nome de domínio no console do CDN, o sistema exibe o prompt "Check whether the domain name is on Alibaba Cloud CDN" e não é possível prosseguir com a configuração.

Causa: Configurar um certificado gratuito exige que o nome de domínio acelerado do CDN esteja resolvido corretamente para o valor CNAME. Se o nome de domínio não estiver resolvido corretamente para o CNAME atribuído pelo CDN, o sistema não consegue detectar que o domínio está no Alibaba Cloud CDN e reporta esse erro.

1. Faça login no console do seu provedor de service DNS, verifique o registro DNS do nome de domínio acelerado e confirme se ele está resolvido corretamente para o valor CNAME atribuído pelo CDN.

2. A resolução de DNS leva algum tempo para entrar em vigor. Após confirmar que a resolução está correta, tente configurar o certificado gratuito no console do CDN novamente.

3. Se o nome de domínio estiver resolvido corretamente, mas o erro persistir, use ferramentas como dig ou nslookup para confirmar que a resolução entrou em vigor, limpe o cache do navegador e tente novamente.

Se a mesma mensagem aparecer ao configurar um certificado gratuito para um nome de domínio DCDN (Dynamic Route for CDN), a solução é a mesma.

ERR_SSL_PROTOCOL_ERROR geralmente indica que um certificado SSL não está configurado corretamente nos nós do CDN ou que o certificado é inválido. Execute as seguintes etapas para solucionar o problema:

1. Verifique a configuração de HTTPS no console do CDN. Certifique-se de que um certificado foi enviado e ativado, e que está em status normal (não expirado).

2. Se usar um certificado personalizado, garanta que o formato do certificado esteja correto (formato PEM) e que a chave privada não seja protegida por senha.

3. Assegure-se de que o certificado corresponda à chave privada e que o nome de domínio vinculado ao certificado corresponda ao nome de domínio acelerado.

4. Execute o seguinte comando para verificar se o certificado realmente retornado pelo nó do CDN está correto:

   openssl s_client -connect <accelerated domain name>:443 -servername <accelerated domain name> < /dev/null 2>/dev/null | openssl x509 -noout -subject -dates

5. Se ainda não tiver configurado um certificado HTTPS, configure um no console do CDN primeiro. Antes que a configuração seja concluída, você pode acessar temporariamente o nome de domínio via HTTP (remova o "s" da URL).

Sintoma: O navegador reporta ERR_SSL_VERSION_OR_CIPHER_MISMATCH (Chrome) ou SSL_ERROR_NO_CIPHER_OVERLAP (Firefox), e a conexão é bloqueada diretamente. Estas são duas mensagens de erro diferentes reportadas pelos dois navegadores para o mesmo tipo de falha de negociação.

Possível causa: Se o cliente e o nó do CDN não conseguirem negociar uma versão de protocolo TLS ou conjunto de cifras mutuamente suportados, o navegador bloqueia diretamente a conexão. Esse tipo de erro é um problema da camada de protocolo TLS e não é exibido como um aviso de risco de certificado. Não o solucione como um problema de cadeia de confiança de certificado. Pressupondo que o certificado esteja configurado corretamente, esse erro não tem relação com a validade do certificado (pode ocorrer mesmo se o certificado estiver totalmente correto). No entanto, se nenhum certificado estiver configurado no lado do CDN, todos os conjuntos de troca de chaves que dependem do certificado também ficarão indisponíveis, o que aciona o mesmo erro. Portanto, confirme primeiro se há um certificado configurado.

Etapas de solução de problemas:

1. Confirme se há um certificado configurado: Verifique o status do certificado HTTPS no console do CDN para descartar a possibilidade de ausência de certificado.

2. Confirme as versões de protocolo TLS e conjuntos de cifras suportados pelo cliente: Clientes desatualizados podem suportar apenas versões anteriores de protocolo, como TLSv1.0, ou conjuntos de cifras legados.

3. Verifique as versões TLS e conjuntos de cifras ativados no lado do CDN: Confirme se há sobreposição com as capacidades do cliente. O console do Alibaba Cloud CDN suporta a configuração de TLSv1.0, TLSv1.1, TLSv1.2 e TLSv1.3. Recomendamos ativar TLSv1.2 e TLSv1.3. Para conjuntos de cifras, recomendamos suites com algoritmos de criptografia AEAD, como AES-128-GCM e AES-256-GCM, com ECDHE_RSA ou ECDHE_ECDSA (pareado com certificados ECC) como mecanismo de troca de chaves. Evite conjuntos de cifras legados com baixa força de criptografia. Para o método de configuração, consulte Configurar versões TLS e conjuntos de cifras.

4. Mantenha compatibilidade com clientes legados: Se o seu negócio precisar suportar clientes legados que aceitam apenas versões anteriores de protocolo, você pode ativar temporariamente a versão correspondente no lado do CDN. Versões anteriores de protocolo apresentam riscos de segurança e são recomendadas apenas como solução transitória. Atualize os clientes o mais rápido possível.

1. Certifique-se de que o certificado foi implantado corretamente: Faça login no console do CDN e confirme nas configurações de HTTPS que o novo certificado está selecionado ou que o novo conteúdo do certificado foi enviado.

2. Verifique a correspondência do nome de domínio: Garanta que o nome de domínio vinculado ao certificado corresponda exatamente ao nome de domínio acelerado do CDN (incluindo o prefixo www).

3. Aguarde a alteração entrar em vigor e limpe o cache local: A implantação do novo certificado em todos os nós do CDN leva algum tempo (geralmente de 1 a 10 minutos). Aguarde e teste novamente. A entrega do certificado não tem relação com o cache de recursos do CDN. Limpe o cache do navegador ou use uma janela anônima para verificação.

4. Verifique o certificado no nó via linha de comando: Contorne a interferência do cache do navegador e visualize diretamente o certificado atualmente implantado no nó do CDN:

   curl -vI https://<accelerated domain name> 2>&1 | grep -E "subject:|expire date:|issuer:"

5. Atualizações de certificado no servidor de origem não são sincronizadas automaticamente: Se o certificado no servidor de origem for atualizado, o lado do CDN não será sincronizado automaticamente. Você deve atualizar manualmente o certificado no console do CDN.

Um certificado HTTPS foi configurado para o nome de domínio no console do CDN, mas um aviso de risco de certificado ainda aparece ao acessar o site usando um navegador. Possíveis causas e soluções:

• Causa 1: A cadeia de certificados está incompleta

  A cadeia completa de certificados intermediários não foi incluída quando o certificado foi enviado. Alguns dispositivos (especialmente dispositivos iOS e alguns Android) têm requisitos mais rigorosos quanto à integridade da cadeia de certificados e exibem diretamente um aviso de risco. Recomendamos usar uma ferramenta online (como myssl.com) para verificar a integridade da cadeia de certificados, completar os certificados intermediários e enviar o certificado novamente. Você também pode verificar via linha de comando:

  openssl s_client -connect <accelerated domain name>:443 -servername <accelerated domain name> < /dev/null 2>&1 | grep -i "verify"

  Se a saída contiver verify error ou unable to get local issuer certificate, a cadeia de certificados está incompleta.

• Causa 2: O certificado expirou

  É necessário renovar o certificado. Após a renovação bem-sucedida, atualize o certificado no console do CDN em tempo hábil. Para saber como atualizar o certificado, consulte Configurar um certificado HTTPS.

• Causa 3: Foi usado um certificado HTTPS autoassinado

  Um certificado gerado por você mesmo, em vez de emitido por uma CA, é chamado de certificado autoassinado. Certificados autoassinados não constam na lista de certificados raiz confiáveis dos navegadores e são vulneráveis a falsificações e ataques man-in-the-middle, acionando um aviso de risco que não pode ser resolvido completando a cadeia de certificados. Recomendamos substituí-lo por um certificado HTTPS emitido por uma CA confiável.

• Causa 4: A página web contém recursos HTTP (conteúdo misto)

  Se a página web carregar recursos (como imagens, arquivos JS e CSS) via HTTP, o navegador exibirá um aviso de conteúdo misto. Navegadores modernos bloqueiam por padrão conteúdo misto ativo carregado via HTTP, como scripts e iframes, e exibem avisos apenas para conteúdo passivo, como imagens. Solução: Altere os links de recursos HTTP na página para HTTPS ou use URLs relativas ao protocolo (//domain/path).

• Causa 5: A hora do sistema está incorreta

  Verifique se a hora do sistema do seu computador está correta. Uma hora do sistema incorreta faz com que o navegador considere o certificado expirado ou ainda não válido, acionando um aviso de risco de certificado. Corrija a hora do sistema e tente navegar no site novamente.

• Causa 6: O cache HSTS impede o retorno para HTTP

  Se o site configurou anteriormente o cabeçalho de resposta HSTS (HTTP Strict Transport Security), o navegador força o acesso HTTPS dentro do período especificado. Se o certificado expirar ou for removido nesse momento, o navegador bloqueia diretamente o acesso sem fornecer uma opção de "continuar assim mesmo". Solução: Corrija o problema do certificado o mais rápido possível. Se precisar limpar temporariamente o cache HSTS local, no Chrome você pode visitar chrome://net-internals/#hsts para excluir o registro HSTS do nome de domínio correspondente. Para saber como configurar o HSTS, consulte Configurar HSTS.

Sintoma: Um certificado HTTPS está configurado para o nome de domínio acelerado e o acesso direto via HTTPS funciona normalmente. No entanto, o acesso HTTP não é redirecionado para HTTPS, e o conteúdo ainda é retornado via HTTP.

Causa: Configurar um certificado HTTPS apenas habilita o nó do CDN a lidar com solicitações HTTPS. Isso não altera a forma como as solicitações HTTP são tratadas. O redirecionamento de HTTP para HTTPS deve ser configurado separadamente usando o redirecionamento de protocolo.

Solução:

1. Ative o redirecionamento de protocolo para o nome de domínio acelerado no console do CDN e selecione o modo de redirecionamento forçado de HTTP para HTTPS. Para o método de configuração, consulte Configurar redirecionamento HTTP/S.

2. Após a configuração entrar em vigor, limpe o cache do navegador e teste novamente. Execute o seguinte comando. Normalmente, um código de status 301 ou 302 é retornado, e o cabeçalho de resposta Location é um endereço que começa com https:

   curl -I http://<accelerated domain name>

Sintoma: A maioria dos dispositivos consegue acessar o nome de domínio acelerado via HTTPS sem problemas, mas alguns clientes mais antigos ou configurados especificamente não conseguem acessá-lo, ou a validação do certificado falha.

Causa: O CDN depende do Server Name Indication (SNI) ao processar solicitações HTTPS. O SNI é uma extensão do protocolo TLS que permite ao cliente especificar o nome de host que deseja acessar ao iniciar uma solicitação de conexão HTTPS. Alguns clientes mais antigos ou configurados especificamente (como sistemas operacionais legados ou bibliotecas TLS de cliente sem manutenção há anos, e alguns dispositivos IoT) podem não suportar SNI ou não enviar informações SNI ao iniciar solicitações HTTPS. Nesse caso, o nó do CDN não consegue determinar o site exato que o cliente deseja acessar e, portanto, não pode fornecer o certificado SSL/TLS correto, causando falha na conexão HTTPS.

Distinga o tipo de problema primeiro: Se o acesso HTTPS ou a validação do certificado falhar em todos os dispositivos e navegadores, o problema geralmente é de cadeia de certificados. Siga a seção "Solução de problemas de cadeia de certificados" abaixo. Se a falha ocorrer apenas em dispositivos legados específicos ou clientes específicos (como mini programas WeChat no Android), enquanto o acesso de outros navegadores for normal, o problema geralmente é de compatibilidade de SNI. Siga a seção "Solução de problemas de SNI" abaixo.

Solução de problemas de SNI:

1. Confirme o escopo da falha: verifique se a validação do certificado falha apenas em um cliente específico (como um mini programa WeChat no Android), enquanto testes em outros navegadores são normais. Se sim, um problema de cadeia de certificados pode ser basicamente descartado. Continue investigando o SNI.

2. Capture os pacotes de handshake TLS do cliente e analise se o cliente carrega informações SNI ao iniciar a solicitação. Se o SNI não for carregado, o nó do CDN não poderá retornar o certificado do nome de domínio.

3. Analise se um erro Certificate Unknown seguido por Reset é reportado quando o cliente e o servidor trocam certificados. Se isso ocorrer e a solicitação não carregar SNI, um problema de compatibilidade de SNI pode ser confirmado.

4. Verifique se o certificado retornado pelo servidor é o certificado do nome de domínio, para descartar erros de configuração de certificado.

Solução de problemas de cadeia de certificados (aplicável quando todos os dispositivos falham):

1. Verifique se a cadeia de certificados está completa. Ao enviar um certificado, inclua o certificado do servidor e a cadeia completa de certificados intermediários.

2. Verifique se o certificado intermediário está correto. Um certificado intermediário incorreto causa falha na validação do certificado. Você pode usar o recurso de exportação de certificado de um navegador para exportar o certificado intermediário para comparação, ou usar uma ferramenta online (como myssl.com) para verificá-lo; em seguida, complete a cadeia e faça o upload novamente.

Medidas de melhoria:

• Atualize o sistema do cliente: Certifique-se de que o sistema operacional e o software em uso estejam nas versões mais recentes para obter suporte a SNI.

• Atualize o firmware de dispositivos IoT: Para dispositivos IoT, verifique regularmente e instale as atualizações de firmware mais recentes fornecidas pelo fabricante.

• Garanta que a cadeia de certificados esteja completa: Ao enviar um certificado, certifique-se de que a cadeia completa de certificados intermediários esteja incluída para evitar falhas de validação de certificado em alguns dispositivos causadas por uma cadeia incompleta.

Sintoma: A velocidade da rede local é normal, mas as páginas carregam lentamente ao acessar o nome de domínio acelerado por CDN via HTTPS (por exemplo, o acesso é lento mesmo em um navegador no modo privado), e a velocidade de acesso é significativamente menor que o esperado.

Possíveis causas: O acesso HTTPS lento geralmente não é causado pela negociação de versão de protocolo TLS (uma falha de negociação causa falha direta na conexão, não lentidão). As causas comuns incluem:

• Timeout de consulta OCSP: Quando o cliente verifica o status de revogação do certificado, ele precisa consultar o servidor OCSP da CA em tempo real. Um timeout de consulta pode travar o carregamento da página por vários segundos. O Alibaba Cloud CDN suporta OCSP Stapling: o nó do CDN consulta e armazena em cache o status do certificado da CA em nome do cliente e o entrega junto com o certificado durante o handshake TLS, evitando consultas em tempo real pelo cliente. Note que, na primeira solicitação ou após a expiração do cache OCSP, o nó do CDN precisa consultar a CA novamente, período em que ainda pode haver um breve atraso. Para o método de configuração, consulte Configurar OCSP stapling.

• Cadeia de certificados excessivamente grande: Se a cadeia de certificados enviada contiver certificados raiz desnecessários, o volume de dados do handshake TLS aumenta. Envie apenas o certificado do servidor e os certificados intermediários. Certificados raiz já estão integrados aos sistemas dos clientes e não precisam ser incluídos.

• Problema de agendamento de DNS: O nome de domínio é resolvido para um nó do CDN distante do cliente, e a latência de rede em si é alta. Este é um problema de agendamento de DNS, não de TLS.

• Versão antiga de protocolo TLS: O handshake TLSv1.3 (1-RTT) tem menos idas e vindas que o TLSv1.2 (2-RTT). Ativar uma versão de protocolo mais recente pode encurtar o tempo de handshake.

Etapas de solução de problemas:

1. Localize a fase demorada: Use o painel Network das ferramentas de desenvolvedor do navegador para verificar a distribuição de tempo das solicitações HTTPS. Se o tempo estiver concentrado na fase de handshake SSL/TLS, continue com as etapas seguintes. Se o handshake for rápido, mas o download de conteúdo for lento, o problema não é de TLS. Solucione o problema a partir da direção de busca de origem ou link de rede.

2. Verifique o OCSP Stapling: Confirme se o OCSP Stapling está ativado no lado do CDN. Se não estiver ativado, combine a captura de pacotes para confirmar se o cliente aguarda uma consulta OCSP após o handshake. Quando ativado, o nó do CDN entrega o status do certificado durante o handshake, eliminando essa espera.

3. Verifique o tamanho da cadeia de certificados: Confirme se a cadeia de certificados enviada contém apenas o certificado do servidor e os certificados intermediários, sem o certificado raiz, para evitar volume excessivo de dados no handshake.

4. Descarte problemas de agendamento: Use dig ou nslookup para verificar o resultado da resolução CNAME do nome de domínio acelerado. Se o cliente for agendado para um nó do CDN distante, verifique a configuração de resolução de DNS local ou entre em contato com a Alibaba Cloud para investigar a política de agendamento.

5. Confirme a versão do protocolo: Confirme se TLSv1.2 ou TLSv1.3 está ativado no lado do CDN. O handshake TLSv1.3 tem menos idas e vindas, e desativá-lo não é recomendado em circunstâncias normais. Para o método de configuração, consulte Configurar versões TLS e conjuntos de cifras.

6. Teste novamente: Após o ajuste, acesse o nome de domínio novamente e confirme se a velocidade de acesso voltou ao normal.

Se o mesmo problema de acesso HTTPS lento ocorrer em um nome de domínio DCDN (Dynamic Route for CDN), a solução de problemas e a solução são as mesmas.