What is HTTPS secure acceleration
HTTPS encrypts data in transit over HTTP by using the TLS/SSL protocol, which effectively prevents data from being eavesdropped on, intercepted, or tampered with by third parties. You can configure an HTTPS certificate on CDN to encrypt requests between clients and CDN over HTTPS to ensure the security of data transmission.
Why HTTPS encryption is required
HTTPS secure transmission effectively prevents the risks of eavesdropping, tampering, spoofing, and hijacking in HTTP plaintext transmission. Your critical information is encrypted during data transmission, which prevents security risks such as the leakage of sensitive information caused by attackers capturing Session IDs or cookies.
HTTPS is the mainstream trend. If you continue to use the HTTP protocol, in addition to potential security risks, the insecure warnings that end users see when they visit your website affect the user experience.
Major search engines give search weighting to HTTPS websites. Websites accessed over HTTPS get higher search rankings.
SSL/TLS certificates
SSL (Secure Sockets Layer) is a security protocol that sits between TCP/IP and various application layer protocols. Clients (such as browsers) can use it to verify the authenticity and integrity of the servers they connect to, and exchange information using encryption.
After IETF standardized SSL, it was renamed TLS (Transport Layer Security). The two are therefore commonly referred to together as SSL/TLS.
SSL certificates use the SSL protocol for communication. They are trusted credentials issued to websites by authoritative organizations, and serve the dual purposes of website identity verification and encrypted transmission.
End-to-end HTTPS encryption
When a client sends a request to a server, the HTTPS encryption process is shown in the following figure:
Configure an HTTPS certificate on CDN to encrypt requests between clients and CDN nodes over HTTPS.
NoteHTTPS secure acceleration is a value-added service. In addition to the basic service fees, you are charged based on the number of HTTPS requests. For more information about billing, see Billing of HTTPS requests for static content.
Configure an HTTPS certificate on the origin server, and configure CDN nodes to fetch content from the origin server over HTTPS to achieve HTTPS encryption.
NoteTo implement end-to-end HTTPS encryption, make sure that the origin server supports HTTPS and configure HTTPS back-to-origin.
SNI (Server Name Indication)
Due to the shortage of IPv4 addresses, the concept of virtual hosts was introduced on HTTP servers so that multiple domain names can share a single IP address. The server can dispatch requests to different virtual hosts based on the host names in client requests. However, for an HTTPS server with multiple virtual hosts, before the SSL handshake is established, the server cannot know which host the client is requesting, and therefore cannot route the request to the corresponding virtual host. Meanwhile, completing the SSL handshake requires reading the certificate information configured in the virtual host.
SNI (Server Name Indication) is designed to resolve this contradiction. SNI requires the client to carry the host name of the domain being accessed when it performs the handshake with the server. This way, the server knows which virtual host's certificate to use for the handshake to establish the TLS connection. SNI was first proposed in 2004 and is now supported by mainstream browsers, servers, and testing tools.
SNI has been supported since TLSv1.2. Specifically, SNI adds the host name of the access target to the SSL handshake information. For example, the handshake information for accessing www.example.com contains the host name information of www.example.com.
Some older or specially configured clients (such as legacy Android or iOS versions, Java 6 and earlier, and some IoT devices) may not support SNI, which can cause access failures to HTTPS-accelerated domain names. For troubleshooting steps, see HTTPS troubleshooting.
Configure HTTPS secure acceleration between clients and CDN nodes
Step 1: Prepare a certificate that matches the accelerated domain name
Only PEM-format certificates are supported. To convert certificates in other formats, see Convert certificate formats.
If you need to apply for a certificate, you can apply for a personal test certificate (free edition) or purchase an official certificate in the SSL Certificate console.
You can also apply for a certificate from a third-party provider. The issued certificate must meet the certificate format requirements. For more information, see Certificate format.
Step 2: Enable HTTPS secure acceleration
Required: After the certificate is prepared, you must Configure an HTTPS certificate for the accelerated domain name before you can enable HTTPS secure acceleration.
Optional: You can configure more features based on your requirements.
Category
Feature
Description
Configure client access protocol
By configuring Protocol Redirect, you can redirect HTTP requests from clients to CDN nodes to HTTPS requests, or redirect HTTPS requests to HTTP requests as needed.
Forces clients to use HTTPS to establish connections with CDN nodes, reducing the risk of first-visit hijacking.
Configure protocol version
HTTP/2 (HTTP2.0) is the new HTTP protocol following HTTP1.1. It supports the latest features such as binary framing, multiplexing, and header compression, which can significantly improve web performance and reduce data interaction latency.
After the TLS version is specified, clients can only use the corresponding TLS version to send and receive requests with CDN nodes, meeting the security requirements of the communication link.
Accelerate SSL certificate verification
CDN nodes pre-cache online certificate verification results and deliver them to clients, so browsers do not need to query the CA site directly for certificate status, reducing user verification time.