HTTPS configuration errors-CDN(CDN)-阿里云帮助中心

Hypertext Transfer Protocol Secure (HTTPS) creates a secure channel over HTTP to better protect content transmitted via Alibaba Cloud CDN. This allows clients to browse websites securely and efficiently with accelerated access. This topic answers common questions about HTTPS.

What is HTTPS?

Hypertext Transfer Protocol Secure (HTTPS) is a protocol that encrypts data transmitted over HTTP to ensure security. The HTTP protocol sends content in plaintext and provides no data encryption. HTTPS secures HTTP by encapsulating it with Secure Sockets Layer (SSL) or Transport Layer Security (TLS). SSL/TLS provides the security foundation for HTTPS. HTTPS provides identity authentication and encrypted communication, making it essential for security-sensitive web communications like payment transactions. When you configure HTTPS on Alibaba Cloud CDN, you must provide a certificate for your domain name. This certificate is deployed to all CDN edge nodes to enable encrypted data transmission across the network.

What are the common types of HTTP attacks?

HTTPS is only one part of a comprehensive security strategy. To ensure full network security, you also need to implement defenses such as WAF and DDoS protection. The following are common types of HTTP attacks:

SQL injection: An attacker injects malicious SQL commands into the back-end database engine through an existing application. By entering malicious SQL statements into a web form, an attacker can exploit a vulnerable website's database, forcing it to execute unintended commands.
Cross-site scripting (XSS): XSS is one of the most common and basic methods for attacking web applications. An attacker posts data containing malicious code on a webpage. When a user views this page, the script executes with the user's identity and permissions, allowing the attacker to modify user data or steal user information.
Cross-site request forgery (CSRF): CSRF is another common attack. An attacker forges a request that mimics a user's actions, such as submitting a form, to modify user data or perform specific tasks. To impersonate a user, CSRF attacks are often combined with XSS attacks, but they can also be executed by other means, such as tricking a user into clicking a link that contains the attack.
HTTP header injection: In an HTTP response, a blank line, which consists of two CRLF (0x0D 0A) character pairs, separates the headers from the content. This blank line marks the end of the headers and the beginning of the content. An attacker can exploit this by injecting arbitrary characters into the headers.
Redirection attacks: Phishing is a common attack method. A phishing attacker typically sends a victim a link that appears legitimate. When you visit the link, you are redirected to a malicious website designed to deceive you into revealing personal information. To prevent this, all redirection operations must be audited to avoid redirecting to a dangerous location. A common solution is to use an allowlist of legitimate redirect URLs and reject any redirects to domains not on the list. Another solution is to add a redirection token to legitimate URLs, which is then verified upon redirection.

Is HTTPS required only for website logins?

No. Consider the following reasons to use HTTPS for your entire site:

Security: When a site has a mix of HTTP and HTTPS pages, loading resources like JS or CSS files over HTTP can expose user information. Full-site HTTPS is the simplest way to prevent this risk.
Performance: When a website uses both HTTPS and HTTP, switching between them requires numerous server redirects, which can slow down page loading times.
Compatibility: Browsers provide better support for HTTPS, and search engines favor HTTPS sites in their rankings.

What certificates do I need to configure for HTTPS?

If you only need to encrypt requests from clients to CDN edge nodes, configure an SSL/TLS certificate on the CDN only.

If you need to configure end-to-end HTTPS access, you must configure an HTTPS certificate on both the CDN and your origin server. For more information, see What is HTTPS acceleration.

Am I charged extra for enabling HTTPS acceleration on CDN?

Yes. Enabling HTTPS acceleration on the CDN secures the link from the client to the CDN edge node. The SSL handshake and content decryption require computation, which increases CPU consumption on CDN servers. However, this does not increase the resource consumption of your origin server because the link from the CDN edge node to your origin server still uses HTTP.

Different types of certificates incurs extra charges. You can also log on to the Certificate Management Service console to apply for a test certificate (free edition), which is a DV-level certificate. You can apply for one test certificate for each accelerated domain name. The certificate is valid for three months and can be automatically renewed for free. After configuring an HTTPS certificate, CDN bills all HTTPS requests for that domain name. For information about charges for static HTTPS requests, see HTTPS request billing.

Are HTTPS requests billed when the IP blacklist/whitelist or User-Agent blacklist returns 403/404?

Yes. Requests that match a policy rule and return a 403 or 404 status code are considered successfully handled and billed as one HTTPS request. Since the response does not carry any resource content, the traffic and billing for it are minimal.

Do I still need to configure HTTPS on CDN if my origin server already uses HTTPS?

Yes. HTTPS secures the connection between a client and a server. Before you use a CDN, clients connect directly to your origin server, requiring HTTPS on the origin. After you add a CDN, clients connect to the CDN. Therefore, to secure client-to-CDN connections, you must configure an HTTPS certificate on the CDN. For instructions, see Configure an HTTPS certificate.

Does enabling HTTPS acceleration consume more resources or reduce access speeds?

Enabling HTTPS on your origin server increases computational resource consumption compared to HTTP. This increase mainly comes from the asymmetric encryption and decryption during the HTTPS handshake, and is especially noticeable under high concurrency. Symmetric encryption and decryption consume roughly the same resources as HTTP. Therefore, it is important to increase the session reuse rate. However, accessing the origin server directly over HTTPS takes longer than accessing it over HTTP.

When you use dynamic acceleration for end-to-end HTTPS access, the average SSL handshake time is shortened. Under high concurrency, the session reuse rate on the origin server increases significantly, reducing its resource consumption.

For static content: Edge distribution adds some handshake time but reduces transmission time, resulting in an overall decrease in access time. Since static resources do not require an origin fetch, interaction with the origin server is reduced, lowering its resource consumption.
For dynamic content: Dynamic requests must fetch content from the origin server. Using dynamic acceleration provides a more controllable and optimal path than the public internet. This increases the session reuse rate and improves overall transmission speed. Although the unavoidable asymmetric encryption increases resource consumption on the origin server, dynamic acceleration optimizes resource consumption for end-to-end HTTPS access.

How do I configure an HTTPS certificate?

You can configure an HTTPS certificate on the CDN console. For detailed instructions, see Configure an HTTPS certificate.

Why can't I find my existing certificate in the resource list when I deploy a certificate to a new CDN domain?

After a wildcard certificate has been deployed to other CDN domain names, it cannot be directly selected from the default certificate list for a new domain name. You need to deploy it by using the upload method on the CDN console. After that, you can use the cloud product deployment feature in the Certificate Management Service console.

Follow these troubleshooting steps:

Verify 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 listed. The associated domain name list in Certificate Management Service shows only domain names that have been added to CDN. If the new domain name has not been added, the list is empty.
Verify that the certificate covers the accelerated domain name. A wildcard certificate (for example, *.example.com) can cover all subdomains at the same level. If the domain name bound to the certificate does not match the accelerated domain name, the certificate does not appear in the available list.
Perform the operations in the following order: First, configure an HTTPS certificate for the domain name on the CDN console by selecting an existing certificate or using custom upload. Then, manage the certificate through cloud product deployment in the Certificate Management Service console. The cloud product deployment feature in the Certificate Management Service console depends on the CDN-side certificate configuration. You must complete the certificate configuration on the CDN console first.
If a wildcard certificate has been deployed to other CDN domain names, you can reuse it for the new domain name by using the custom upload method. Alternatively, you can create a deployment task in the Certificate Management Service console to deploy it to CDN.

For instructions on how to configure an HTTPS certificate, see Configure an HTTPS certificate.

What do I do if a duplicate certificate error is reported when I upload an HTTPS certificate?

When you upload a Custom Certificate (Certificate+Private Key), if the system reports a duplicate certificate, change the certificate name and upload it again.

How do I upload a certificate when I have multiple .crt files from a third-party CA?

Certificate files from an intermediate authority may contain multiple certificates. Before uploading, you must concatenate the server certificate and the intermediate certificate into a single file.

Open the .pem files in a text editor and paste the content of the intermediate certificate directly after the server certificate, with no blank lines in between. Certificate authorities usually provide instructions, so be sure to read their guidelines.

The concatenated certificate looks like this:

What do I do if errors occur when I configure an HTTPS certificate?

You may encounter various errors when uploading a custom SSL certificate on the CDN console. Common error types include:

Certificate format error: CDN supports only PEM-formatted certificates. Make sure the certificate content begins with -----BEGIN CERTIFICATE-----, ends with -----END CERTIFICATE-----, and typically has 64 characters per line. If your certificate is in DER, P7B, or PFX format, you must convert it to PEM format first.
Private key format error: The header of the private key file should be -----BEGIN RSA PRIVATE KEY-----. If a private key format error is displayed, you need to convert it before uploading. Additionally, the private key cannot be password-protected.
Certificate and private key mismatch: The uploaded certificate and private key must be a matching pair. To check an RSA certificate, run openssl x509 -noout -modulus -in your_cert.pem | openssl md5 and openssl rsa -noout -modulus -in your_key.pem | openssl md5 to compare their modulus values.
Certificate domain mismatch: The Common Name (CN) or Subject Alternative Name (SAN) of the certificate must include the accelerated domain name. To check, run the following command: openssl x509 -in cert.pem -noout -text | grep -A1 "Subject:|Subject Alternative Name"
Certificate/key too long: Check if the certificate chain contains extra blank lines, invisible characters, a Byte Order Mark (BOM), or if the root CA certificate was mistakenly included.
Certificate expired: Use the openssl x509 -in your_cert.pem -noout -dates command to check the certificate's validity period.

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

Do I need to update the HTTPS certificate on CDN after updating the certificate on my origin server?

No. Updating the HTTPS certificate on your origin server does not affect the HTTPS certificate on the CDN. You only need to update the HTTPS certificate on the CDN when it is about to expire or has already expired. For instructions, see Configure an HTTPS certificate.

Do I need to enable HSTS on subdomains after I enable the includeSubdomains option?

No, you do not need to enable HSTS on the subdomains. After you enable the Include Subdomains option, the HSTS policy applies to all subdomains. Ensure that all subdomains support HTTPS access, otherwise they will become inaccessible.

Why do clients still use HTTP after I configure HTTPS?

Whether clients use HTTP or HTTPS depends on their request. To force all clients to use HTTPS, enable a force redirect on the CDN. For instructions, see Configure a force redirect.

Why can most devices access my HTTPS-accelerated domain but some cannot?

This issue typically occurs because the CDN relies on Server Name Indication (SNI) to process HTTPS requests. SNI is a TLS extension that allows a client to specify the hostname it wants to connect to when initiating an HTTPS connection.

However, some older or specially configured clients, such as old versions of Android or iOS, Java 6 and earlier, and some IoT devices, may not support SNI or may not send SNI information when making an HTTPS request. In such cases, the CDN edge node cannot determine the exact site the client wants to access and therefore cannot provide the correct SSL/TLS certificate. This causes the HTTPS connection to fail, and the user is unable to access the website content.

To resolve this issue, we recommend the following:

Upgrade the client system: Ensure that your operating system and software are up-to-date to get SNI support.
Update IoT device firmware: For IoT devices, regularly check for and install the latest firmware updates provided by the manufacturer.

How do I remove password protection from a private key file?

Check if the key is password-protected
If you are certain that your private key is password-protected and you know the encryption algorithm, you can skip directly to the "Remove password protection" section below for decryption. If you are unsure whether your private key is password-protected or you do not know the encryption algorithm, follow these steps to check:
1. For RSA-encrypted private keys
  Use OpenSSL to run the following command. If the private key is encrypted, OpenSSL prompts you to enter a passphrase: Enter pass phrase for <encrypted private key file>:. If the private key is unencrypted, OpenSSL does not prompt you for a passphrase and displays the private key information. If an error message is returned, it indicates that the private key is not an RSA-encrypted file.
```
openssl rsa -in <encrypted_private_key_file> -text -noout
```
2. For ECC/SM2-encrypted private keys
  Run the following command using OpenSSL. If the private key is encrypted, OpenSSL prompts you to enter a password: Enter pass phrase for <encrypted_private_key_file>:. If the private key is not encrypted, OpenSSL does not ask for a password and displays the private key information directly. If an error message appears, the private key is not an ECC or SM2-encrypted file.
```
openssl ec -in <encrypted_private_key_file> -text -noout
```
Remove password protection
- If the certificate's encryption algorithm is RSA, run the following command on a computer with OpenSSLor BabaSSLinstalled to decrypt the private key.
```
openssl rsa -in <encrypted_private_key_file> -passin pass:<private_key_password> -out <decrypted_private_key_file>
```
- If the certificate's encryption algorithm is ECC or SM2, run the following command on a computer with OpenSSLor BabaSSLinstalled to decrypt the private key.
```
openssl ec -in <encrypted_private_key_file> -passin pass:<private_key_password> -out <decrypted_private_key_file>
```