HTTPS FAQ

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.

Common HTTP attack types

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.

Certificates for HTTPS

If you only need to encrypt requests from clients to CDN edge nodes, configure an HTTPS 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.

Charges for HTTPS acceleration

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.

Purchasing different types of certificates incurs extra charges. You can also log on to the Certificate Management Service console to apply for a personal test certificate (free edition). A personal test certificate (free edition) is a DV-level certificate. You can apply for one personal test certificate (free edition) 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.

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.

HTTPS on CDN with an HTTPS origin

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.

Impact of HTTPS acceleration on performance

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.

Configure an HTTPS certificate

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

Handle the duplicate certificate error

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

Upload a certificate with multiple files

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:

Troubleshoot HTTPS certificate errors

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.

Syncing origin certificate updates to CDN

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.

HSTS on subdomains with 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.

Clients using HTTP despite HTTPS configuration

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.

HTTPS access issues on some devices

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.

Remove password from a private key

Check if the key is password-protected

If you are unsure whether your private key is password-protected, 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 OpenSSL or BabaSSL installed 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 OpenSSL or BabaSSL installed to decrypt the private key.
```
openssl ec -in <encrypted_private_key_file> -passin pass:<private_key_password> -out <decrypted_private_key_file>
```