HTTPS troubleshooting guide

Multiple errors may occur when you upload a custom SSL certificate in the CDN console. Common error types and solutions:

• Invalid certificate format: CDN supports only certificates in PEM format. Make sure that the certificate content starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----, and each line typically contains 64 characters. If your certificate is in DER, P7B, or PFX format, convert it to PEM format first.

• Invalid private key format: The header of the private key file must match the key algorithm: -----BEGIN RSA PRIVATE KEY----- (PKCS#1 format) for RSA keys, and -----BEGIN EC PRIVATE KEY----- for ECC/SM2 keys. If your private key starts with -----BEGIN PRIVATE KEY----- (PKCS#8 format), convert it before uploading: run openssl rsa -in old_server_key.pem -out new_server_key.pem for RSA keys, or openssl ec -in old_server_key.pem -out new_server_key.pem for ECC/SM2 keys. In addition, the private key cannot be password-protected. For how to remove password protection, see Remove password protection from a private key file.

  Note

  To run the preceding openssl ec command on an SM2 (Chinese national cryptographic) key, you must use OpenSSL 1.1.1 or later (SM2 was introduced in 1.1.1) compiled with SM2 algorithm support. Otherwise, the command directly reports an error, which can be mistakenly attributed to the private key file itself.

  If your OpenSSL does not support SM2, we recommend that you use the SM2 certificate tool provided by Alibaba Cloud Certificate Management Service or host the certificate directly in the console.

• Certificate and private key mismatch: The uploaded certificate and private key must be a pair. For RSA keys, run the following commands to compare whether the modulus values are identical:

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

  ECC/SM2 keys do not have a modulus. Compare the public keys instead by running the following commands respectively. If the outputs are identical, the certificate and private key match:

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

  If you are unsure about the key type, use the following generic method that applies to both RSA and ECC. If the MD5 values of the two output lines are identical, the certificate and private key match:

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

• Certificate domain name mismatch: The CN or SAN of the certificate must include the accelerated domain name. Check command: openssl x509 -in cert.pem -noout -text | grep -E -A1 "Subject:|Subject Alternative Name"

• Certificate or private key too long: The console imposes a length limit on uploaded content. Check the following: whether the certificate chain contains extra blank lines, invisible characters, or a BOM header (display invisible characters in a text editor and remove them); whether the root CA certificate was pasted into the certificate chain by mistake (upload only the server certificate and intermediate certificates); whether the private key was pasted into the certificate field (or vice versa).

• Certificate expired: Run openssl x509 -in your_cert.pem -noout -dates to check the validity period of the certificate.

For specific format requirements and conversion methods, see Certificate format.

If a private key is password-protected, an invalid private key format error is reported during upload. You must remove the password protection first:

1. Check whether the private key is password-protected

   For an RSA-encrypted private key, run the following command by using OpenSSL. If you are prompted with Enter pass phrase for <encrypted private key file>:, the key is encrypted. If the private key information is directly displayed, the key is not encrypted. If an error is reported, the private key is not an RSA-encrypted file:

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

   For an ECC/SM2-encrypted private key, run the following command to check:

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

2. Decrypt the private key

   If the encryption algorithm of the certificate is RSA, run the following command to decrypt the private key:

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

   If the encryption algorithm of the certificate is ECC or SM2, run the following command to decrypt the private key:

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

Possible causes and solutions:

1. The wildcard certificate has been deployed to other domain names: After a wildcard certificate is deployed to other CDN domain names, if a new domain name needs to reuse the same certificate, the certificate cannot be directly selected from the default certificate list. You must deploy it by using the custom upload method in the CDN console. After that, you can use the certificate deployment feature in the Certificate Management Service console.

2. The domain name bound to the certificate differs from the accelerated domain name: Check whether the domain name bound to the certificate matches the current CDN accelerated domain name. Note the difference between two cases: a single-domain certificate (such as one bound only to example.com) cannot be used for the subdomain image.example.com, and you must apply for a certificate for that subdomain separately; whereas a wildcard certificate (such as *.example.com) matches all subdomains at the same level (such as image.example.com and api.example.com).

3. Account mismatch: Make sure that the certificate and the CDN domain name belong to the same Alibaba Cloud account.

4. The free certificate does not include the www prefix: When you apply for a free SSL certificate, the www prefix is not automatically added. You must manually enter the complete domain name to apply.

5. The domain name format prevents automatic matching: If automatic matching fails due to the domain name format (such as root domain versus subdomain), we recommend that you create a deployment task in the Certificate Management Service console to deploy the certificate to CDN, or download the certificate file and configure it by using the custom upload method.

If the certificate still does not appear in the resource list, troubleshoot in the following order:

1. Confirm that the domain name has been added to CDN. Log on to the CDN console, go to the Domain Names page, and check whether the target domain name is in the list. The associated domain name list of the certificate service displays only domain names that have been added to CDN. The list is empty if the new domain name has not been added.

2. Confirm that the domain name bound to the certificate covers the accelerated domain name. A wildcard certificate (such as *.example.com) covers all subdomains at the same level, but does not cover deeper-level subdomains (such as a.b.example.com) or the parent domain name itself (such as example.com). If the domain name bound to the certificate does not match the accelerated domain name, the certificate does not appear in the selectable list.

3. Perform operations in order: first configure an HTTPS certificate for the domain name in the CDN console (select an existing certificate or upload a custom one). After this is done, perform subsequent management through the cloud product deployment feature in the certificate console. The cloud product deployment feature in the certificate console depends on the configuration on the CDN console side, so the certificate configuration in the CDN console must be completed first.

For the specific operations of configuring an HTTPS certificate, see Configure an HTTPS certificate.

When you upload a certificate of the Custom Certificate (Certificate+Private Key) type, if the system reports that the certificate is a duplicate, the same certificate content already exists in the system. For example, the same certificate may have been uploaded for another domain name before. Solutions:

• Reuse the existing certificate (recommended): There is no need to upload it again. On the HTTPS configuration page of the CDN console, switch the certificate source to Existing Certificate, search for and select the certificate in the list, and deploy it directly.

• Re-upload is really required: Change the certificate name and upload it again.

Symptom: After you upload a wildcard certificate for the accelerated domain name, the browser reports a certificate error when you access third-level or deeper domain names.

Possible cause: According to the HTTPS certificate domain name matching specification (RFC 6125), a wildcard certificate matches only the next-level domain names at the level where the wildcard resides. For example, the *.abc.com certificate matches a.abc.com and b.abc.com, but does not match the parent domain name abc.com or the third-level domain name x.a.abc.com.

Solution:

• For deeper-level domain names, apply for a wildcard certificate of the corresponding level. For example, if you need to accelerate third-level domain names such as 1.cdn.abc.com and 2.cdn.abc.com, use the *.cdn.abc.com wildcard certificate.

• If you also need to cover the parent domain name abc.com, apply for a separate certificate for the parent domain name, or use a SAN (Subject Alternative Name) certificate that includes both abc.com and *.abc.com.

Symptom: When you configure a free certificate for a domain name in the CDN console, the system prompts "Check whether the domain name is on Alibaba Cloud CDN" and you cannot proceed with the configuration.

Cause: Configuring a free certificate requires the CDN accelerated domain name to be correctly resolved to the CNAME value. If the domain name is not correctly resolved to the CNAME assigned by CDN, the system cannot detect that the domain name is on Alibaba Cloud CDN and reports this error.

1. Log on to the console of your DNS service provider, check the DNS record of the accelerated domain name, and confirm that it is correctly resolved to the CNAME value assigned by CDN.

2. DNS resolution takes some time to take effect. After confirming that the resolution is correct, try configuring the free certificate in the CDN console again.

3. If the domain name is correctly resolved but the error persists, use tools such as dig or nslookup to confirm that the resolution has taken effect, clear the browser cache, and try again.

If the same message appears when you configure a free certificate for a DCDN (Dynamic Route for CDN) domain name, the solution is the same.

ERR_SSL_PROTOCOL_ERROR usually indicates that an SSL certificate is not correctly configured on CDN nodes or the certificate is invalid. Perform the following steps to troubleshoot:

1. Check the HTTPS configuration in the CDN console. Make sure that a certificate has been uploaded and enabled, and the certificate is in a normal state (not expired).

2. If you use a custom certificate, make sure that the certificate format is correct (PEM format) and the private key is not password-protected.

3. Make sure that the certificate matches the private key, and the domain name bound to the certificate matches the accelerated domain name.

4. Run the following command to verify whether the certificate actually returned by the CDN node is correct:

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

5. If you have not configured an HTTPS certificate before, configure one in the CDN console first. Before the configuration is complete, you can temporarily access the domain name over HTTP (remove the "s" from the URL).

Symptom: The browser reports ERR_SSL_VERSION_OR_CIPHER_MISMATCH (Chrome) or SSL_ERROR_NO_CIPHER_OVERLAP (Firefox), and the connection is directly blocked. These are two different error messages reported by the two browsers for the same type of negotiation failure.

Possible cause: If the client and the CDN node cannot negotiate a mutually supported TLS protocol version or cipher suite, the browser directly blocks the connection. This kind of error is a TLS protocol layer issue and is not displayed as a certificate risk warning. Do not troubleshoot it as a certificate trust chain issue. On the premise that the certificate is correctly configured, this error is unrelated to the certificate validity (it can occur even if the certificate is completely correct). However, if no certificate is configured on the CDN side at all, all key exchange suites that depend on the certificate are also unavailable, which triggers the same error. Therefore, confirm that a certificate is configured first.

Troubleshooting steps:

1. Confirm that a certificate is configured: Check the HTTPS certificate status in the CDN console to rule out the possibility that no certificate is configured.

2. Confirm the TLS protocol versions and cipher suites supported by the client: Outdated clients may support only earlier protocol versions such as TLSv1.0 or legacy cipher suites.

3. Check the TLS versions and cipher suites enabled on the CDN side: Confirm that they overlap with the client capabilities. The Alibaba Cloud CDN console supports configuring TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3. We recommend that you enable TLSv1.2 and TLSv1.3. For cipher suites, we recommend suites with AEAD encryption algorithms such as AES-128-GCM and AES-256-GCM, with ECDHE_RSA or ECDHE_ECDSA (paired with ECC certificates) as the key exchange mechanism. Avoid legacy cipher suites with low encryption strength. For the configuration method, see Configure TLS versions and cipher suites.

4. Keep compatibility with legacy clients: If your business must support legacy clients that only support earlier protocol versions, you can temporarily enable the corresponding earlier protocol version on the CDN side. Earlier protocol versions pose security risks and are recommended only as a transitional solution. Upgrade the clients as soon as possible.

1. Make sure that the certificate is correctly deployed: Log on to the CDN console and confirm in the HTTPS settings that the new certificate is selected or the new certificate content is uploaded.

2. Check domain name matching: Make sure that the domain name bound to the certificate exactly matches the CDN accelerated domain name (including the www prefix).

3. Wait for the change to take effect and clear the local cache: Deploying the new certificate to all CDN nodes takes some time (usually 1 to 10 minutes). Wait and then test again. Certificate delivery is unrelated to CDN resource caching. Clear the browser cache or use an incognito browser window for verification.

4. Verify the certificate on the node by using the command line: Bypass the browser cache interference and directly view the certificate currently deployed on the CDN node:

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

5. Certificate updates on the origin server are not automatically synchronized: If the certificate on the origin server is updated, the CDN side is not automatically synchronized. You must manually update the certificate in the CDN console.

An HTTPS certificate has been configured for the domain name in the CDN console, but a certificate risk warning still appears when you access the website by using a browser. Possible causes and solutions:

• Cause 1: The certificate chain is incomplete

  The complete intermediate certificate chain was not included when the certificate was uploaded. Some devices (especially iOS devices and some Android devices) have stricter requirements for certificate chain integrity and directly display a risk warning. We recommend that you use an online tool (such as myssl.com) to check the certificate chain integrity, complete the intermediate certificates, and upload the certificate again. You can also check by using the command line:

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

  If the output contains verify error or unable to get local issuer certificate, the certificate chain is incomplete.

• Cause 2: The certificate has expired

  You must renew the certificate. After the renewal succeeds, update the certificate in the CDN console in a timely manner. For how to update the certificate, see Configure an HTTPS certificate.

• Cause 3: A self-signed HTTPS certificate is used

  A certificate generated by yourself instead of being issued by a CA is called a self-signed certificate. Self-signed certificates are not in the trusted root certificate list of browsers and are vulnerable to forgery and man-in-the-middle attacks, so a risk warning is triggered, and it cannot be resolved by completing the certificate chain. We recommend that you replace it with an HTTPS certificate issued by a trusted CA.

• Cause 4: The web page contains HTTP resources (mixed content)

  If the web page loads resources (such as images, JS, and CSS files) over HTTP, the browser displays a mixed content warning. Modern browsers block active mixed content loaded over HTTP, such as scripts and iframes, by default, and only display warnings for passive content such as images. Solution: Change the HTTP resource links on the page to HTTPS, or use protocol-relative URLs (//domain/path).

• Cause 5: The system time is incorrect

  Check whether the system time of your computer is correct. An incorrect system time causes the browser to consider the certificate expired or not yet valid, which triggers a certificate risk warning. Correct the system time and try browsing the website again.

• Cause 6: The HSTS cache prevents falling back to HTTP

  If the website previously configured the HSTS (HTTP Strict Transport Security) response header, the browser forces HTTPS access within the specified period. If the certificate expires or is removed at this point, the browser directly blocks access without providing a "proceed anyway" option. Solution: Fix the certificate issue as soon as possible. If you need to temporarily clear the local HSTS cache, in Chrome you can visit chrome://net-internals/#hsts to delete the HSTS record of the corresponding domain name. For how to configure HSTS, see Configure HSTS.

Symptom: An HTTPS certificate is configured for the accelerated domain name, and direct HTTPS access works normally. However, HTTP access is not redirected to HTTPS, and the content is still returned over HTTP.

Cause: Configuring an HTTPS certificate only enables the CDN node to handle HTTPS requests. It does not change how HTTP requests are handled. The redirect from HTTP to HTTPS must be configured separately by using protocol redirect.

Solution:

1. Enable protocol redirect for the accelerated domain name in the CDN console, and select the HTTP-to-HTTPS force redirect mode. For the configuration method, see Configure HTTP/S redirection.

2. After the configuration takes effect, clear the browser cache and test again. Run the following command. Normally, a 301 or 302 status code is returned, and the Location response header is an address that starts with https:

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

Symptom: Most devices can access the domain name accelerated over HTTPS without issues, but some earlier or specifically configured clients cannot access it, or certificate validation fails.

Cause: CDN relies on Server Name Indication (SNI) when processing HTTPS requests. SNI is an extension of the TLS protocol that allows a client to specify the hostname it wants to access when initiating an HTTPS connection request. Some earlier or specifically configured clients (such as legacy operating systems or client TLS libraries that have not been maintained for years, and some IoT devices) may not support SNI or may not send SNI information when initiating HTTPS requests. In this case, the CDN node cannot determine the exact site that the client wants to access and therefore cannot provide the correct SSL/TLS certificate, which causes the HTTPS connection to fail.

Distinguish the issue type first: If HTTPS access or certificate validation fails on all devices and all browsers, the issue is usually a certificate chain issue. Follow "Certificate chain troubleshooting" below. If the failure occurs only on specific legacy devices or specific clients (such as WeChat mini programs on Android) while access from other browsers is normal, the issue is usually an SNI compatibility issue. Follow "SNI troubleshooting" below.

SNI troubleshooting:

1. Confirm the failure scope: whether certificate validation fails only on a specific client (such as a WeChat mini program on Android) while tests in other browsers are normal. If so, a certificate chain issue can basically be ruled out. Continue to investigate SNI.

2. Capture the TLS handshake packets of the client and analyze whether the client carries SNI information when initiating the request. If SNI is not carried, the CDN node cannot return the certificate of the domain name.

3. Analyze whether a Certificate Unknown error followed by a Reset is reported when the client and server exchange certificates. If this occurs and the request does not carry SNI, an SNI compatibility issue can be confirmed.

4. Check whether the certificate returned by the server is the certificate of the domain name, to rule out certificate configuration errors.

Certificate chain troubleshooting (applicable when all devices fail):

1. Check whether the certificate chain is complete. When uploading a certificate, include the server certificate and the complete intermediate certificate chain.

2. Check whether the intermediate certificate is correct. An incorrect intermediate certificate causes certificate validation to fail. You can use the certificate export feature of a browser to export the intermediate certificate for comparison, or use an online tool (such as myssl.com) to check it, then complete the chain and upload it again.

Improvement measures:

• Upgrade the client system: Make sure that the operating system and software in use are of the latest versions to obtain SNI support.

• Update IoT device firmware: For IoT devices, regularly check for and install the latest firmware updates provided by the vendor.

• Ensure the certificate chain is complete: When uploading a certificate, make sure that the complete intermediate certificate chain is included to prevent certificate validation failures on some devices caused by an incomplete certificate chain.

Symptom: The local network speed is normal, but web pages load slowly when you access the CDN-accelerated domain name over HTTPS (for example, access is slow even in a privacy-mode browser), and the access speed is significantly lower than expected.

Possible causes: Slow HTTPS access is usually not caused by TLS protocol version negotiation (a negotiation failure causes the connection to fail directly, not to slow down). Common causes include:

• OCSP query timeout: When the client verifies the certificate revocation status, it must query the OCSP server of the CA in real time. A query timeout can stall the page loading for several seconds. Alibaba Cloud CDN supports OCSP Stapling: the CDN node queries and caches the certificate status from the CA on behalf of the client and delivers it together with the certificate during the TLS handshake, which avoids real-time queries from the client. Note that, on the first request or after the OCSP cache expires, the CDN node must query the CA again, during which a brief delay may still exist. For the configuration method, see Configure OCSP stapling.

• Oversized certificate chain: If the uploaded certificate chain contains unnecessary root certificates, the data volume of the TLS handshake increases. Upload only the server certificate and intermediate certificates. Root certificates are built into client systems and do not need to be included.

• DNS scheduling issue: The domain name is resolved to a CDN node that is far from the client, and the network latency itself is high. This is a DNS scheduling issue, not a TLS issue.

• Early TLS protocol version: The TLSv1.3 handshake (1-RTT) has fewer round trips than TLSv1.2 (2-RTT). Enabling a later protocol version can shorten the handshake time.

Troubleshooting steps:

1. Locate the time-consuming phase: Use the Network panel of the browser developer tools to check the time distribution of HTTPS requests. If the time is concentrated in the SSL/TLS handshake phase, continue with the following steps. If the handshake is fast but content download is slow, the issue is not a TLS issue. Troubleshoot from the origin fetch or network link direction.

2. Check OCSP Stapling: Confirm whether OCSP Stapling is enabled on the CDN side. If it is not enabled, you can combine packet capture to confirm whether the client waits for an OCSP query after the handshake. After it is enabled, the CDN node delivers the certificate status during the handshake, which eliminates this wait.

3. Check the certificate chain size: Confirm that the uploaded certificate chain contains only the server certificate and intermediate certificates, without the root certificate, to avoid excessive handshake data volume.

4. Rule out scheduling issues: Use dig or nslookup to check the CNAME resolution result of the accelerated domain name. If the client is scheduled to a distant CDN node, check the local DNS resolution configuration or contact Alibaba Cloud to investigate the scheduling policy.

5. Confirm the protocol version: Confirm that TLSv1.2 or TLSv1.3 is enabled on the CDN side. The TLSv1.3 handshake has fewer round trips, and disabling it is not recommended under normal circumstances. For the configuration method, see Configure TLS versions and cipher suites.

6. Retest: After the adjustment, access the domain name again and confirm that the access speed returns to normal.

If the same slow HTTPS access issue occurs on a DCDN (Dynamic Route for CDN) domain name, the troubleshooting and solution are the same.