Edge Acceleration

Site Acceleration
- Overview
- Access Control
  - Token authentication
    - Token Authentication
    - Authentication Method A
    - Authentication Method B
    - Authentication Method C
    - Authentication Method D
    - Authentication Method V
- Smart Acceleration
- Cache configuration
  - Overview
  - EdgeOne caching rules introduction
    - Content Cache Rules
    - Cache Key Introduction
    - Vary Feature
  - Cache Configuration
    - Custom Cache Key
    - Node Cache TTL
    - Status Code Cache TTL
    - Browser Cache TTL
    - Offline Caching
    - Cache Prefresh
  - Clear and Preheat Cach
    - Cache Purge
    - URL Pre-Warming
    - Prefetch M3U8
  - How to improve the Cache Hit Rate of EdgeOne
- File Optimization
  - Content Compression
  - Smart Compression
- Network Optimization
  - HTTP/2
  - HTTP/3(QUIC)
    - Overview
    - Enable HTTP/3
    - QUIC SDK
      - SDK Overview
      - SDK Download and Integration
      - Sample Code
        Android
        iOS
      - API Documentation
        Android
        iOS
  - IPv6 Access
  - Maximum Upload Size
  - WebSocket
  - Client IP Geolocation Header
  - Client IP Geographical Location
  - gRPC
  - Network Error Logging
- URL Rewrite
  - Access URL Redirection
  - Origin-Pull URL Rewrite
- Modifying Header
  - Modifying HTTP Response Headers
  - Modifying HTTP Request Headers
- Modify response content
  - HTTP Response
  - Custom Error Page
- Rules Engine
  - Overview
  - Rule Management
  - variables
  - Supported Matching Types and Actions
- Image and video processing
  - Audio and Video Pre-pulling
  - Just-in-Time Image Processing
  - Video Just-In-Time Processing
  - VOD Media Origin
- Speed limit for single connection download
- Request and Response Actions
  - HTTP Response
  - Processing order
  - Default HTTP Headers of Origin-Pull Requests
  - Default HTTP Response Headers
  - HTTP Restrictions
- Media Services
  - Audio and Video Pre-pulling
  - Just-in-Time Image Processing
  - Just-in-Time Media Processing
  - VOD Media Origin
L4 Proxy
- Overview
- Creating an L4 Proxy Instance
- Modifying an L4 Proxy Instance
- Disabling or Deleting an L4 Proxy Instance
- Batch Configuring Forwarding Rules
- Obtaining Real Client IPs
  - Obtaining Real TCP Client IPs via TOA
  - Obtaining Real Client IPs Through Protocol V1/V2
    - Overview
    - Method 1: Obtaining Real Client IPs Through Nginx
    - Method 2: Parsing Real Client IPs on Application Server
    - Format of Real Client IPs Obtained Through Proxy Protocol V1/V2
  - Transmitting Client Real IP via SPP Protocol
Domain name service and origin server configuration
- Domain Name Services
  - Overview
  - DNS resolution for managed domains
    - Modifying DNS Servers
    - Configuring DNS Records
    - Batch Importing DNS Records
    - Advanced DNS Configuration
  - Access accelerated domains
    - Adding A Domain Name for Acceleration
    - Ownership Verification
    - Modifying CNAME Records
    - Verify Business Access
  - Traffic scheduling
    - Traffic Scheduling Management
- HTTPS Certificate
  - Overview
  - Edge HTTPS Certificate
    - Overview
    - Deploying/Updating SSL Certificate for A Domain Name
    - Configuring A Free Certificate for A Domain Name
    - Using Keyless Certificate
  - Edge mTLS Authentication
  - Origin Certificate Validation
  - HTTPS configuration
    - Forced HTTPS Access
    - Enabling HSTS
    - SSL/TLS security configuration
      - Configuring SSL/TLS Security
      - TLS Versions and Cipher Suites
    - Enabling OCSP Stapling
  - Related References
    - Using OpenSSL to Generate Self-Signed Certificates
    - Certificate Format Requirements
    - The Difference Between one-way authentication and Mutual authentication
- Origin Configuration
  - Load Balancing
    - Overview
    - Quickly Create Load Balancers
    - Health Check Policies
    - Viewing the Health Status of Origin Server
    - Related References
      - Load Balancing-Related Concepts
      - Introduction to Request Retry Strategy
  - Origin Group Configuration
  - Origin configuration
    - Origin-Pull Timeout
    - Configuring Origin-Pull HTTPS
    - Host Header Rewrite
    - Controlling Origin-pull Requests
    - Redirect Following During Origin-Pull
    - HTTP/2 Origin-Pull
    - Range GETs
    - Modify Origin
    - Origin-pull Rate Limiting Policy
  - Origin Protection(Obtaining/Updating Origin IP Address Range)
  - Related References
    - ld Version Origin Group Compatible Related Issues

Using OpenSSL to Generate Self-Signed Certificates

All server and client certificates generally need to be applied for from an authoritative certificate authority (CA) to ensure they are trusted by different operating systems and browsers. The CA usually charges a certain fee for the certificate. If you currently only need an HTTPS certificate for testing or in-house use, you can also manually issue a self-signed certificate using OpenSSL. The steps are as follows:
RSA Algorithm Certificate
ECC Algorithm Certificate
Step 1: Generate Root Certificate
1. Generate the root certificate private key through the following command, using an RSA certificate with a 4096 key length as an example, and save the generated private key as a ca-rsa.key file.
openssl genrsa -out ca-rsa.key 4096
2. Use the above certificate private key to generate a Certificate Signing Request (CSR) file, saved as ca-rsa.csr. The following command specifies the basic information of the certificate through -subj, where:
 C=CN represents the country.
ST=State represents the province.
L=City represents the city.
O= Example Org represents the organization.
OU=Example CA represents the department.
CN=Example Root CA represents the common name of the certificate. In a CA certificate, this field can describe the purpose of the CA. If it is a domain name certificate, the domain name for certificate issuance needs to be specified in this field.
openssl req -new -key ca-rsa.key -out ca-rsa.csr -subj "/C=US/ST=State/L=City/O=Example Org/OU=Example CA/CN=Example Root CA"
3. Create the root certificate public key based on the certificate signing request file, with a validity of 3650 days, and save it as ca-rsa.crt. The -extfile parameter specifies this certificate as a CA certificate.
openssl x509 -req -in ca-rsa.csr -out ca-rsa.crt -signkey ca-rsa.key -days 3650 -sha256 -extfile <(printf "basicConstraints=critical,CA:TRUE\nkeyUsage=critical,keyCertSign,cRLSign\nsubjectKeyIdentifier=hash\n")
4. Issue the certificate and verify whether it is a CA certificate.
openssl x509 -in ca-rsa.crt -noout -text | grep -A2 "X509v3 Basic Constraints"
The output result contains CA:TRUE, which indicates a correct CA certificate. See the output result below:
X509v3 Basic Constraints: critical
                CA:TRUE    # Indicates the cert is a CA certificate.
            X509v3 Key Usage: critical
Step Two: Issue a Domain Name Certificate
To issue a certificate for the designated domain name www.example.com, you can use the generated CA certificate to start issuing a self-signed domain name certificate:
1. Generate the certificate private key through the following command, using an RSA certificate with a 4096 key length as an example, and save the generated private key as a rsa-domain.key file.
openssl ecparam -name secp384r1 -genkey -noout -out rsa-domain.key
2. Use the above certificate private key to generate a Certificate Signing Request (CSR) file, saved as rsa-domain.csr. The following command specifies the basic information of the certificate through -subj. Please note to replace the CN field content with the domain name you want to issue. In this example, www.example.com is used.
openssl req -new -key rsa-domain.key -out rsa-domain.csr -subj "/C=US/ST=State/L=City/O=Example Org/OU=Example CA/CN=www.example.com"
3. Sign the domain name certificate with the CA certificate, generate the public key with a validity of 3650 days, and save it as rsa-domain.crt.
openssl x509 -req -in rsa-domain.csr -out rsa-domain.crt -CA ca-rsa.crt -CAkey ca-rsa.key -days 3650
4. Compare the CA certificate with the domain name certificate public key to verify whether the certificate chain of the issued domain name certificate is correct.
openssl verify -CAfile ca-rsa.crt rsa-domain.crt
If the output result displays rsa-domain.crt:OK, it indicates that the certificate issuance chain is correct. See the following:
rsa-domain.crt: OK
Step 1: Generate Root Certificate
1. Generate the root certificate private key through the following command, using an ECC certificate with the secp384r1 encryption algorithm as an example, and save the generated private key as a ca-ecc.key file.
openssl ecparam -name secp384r1 -genkey -noout -out ca-ecc.key
2. Use the above certificate private key to generate a Certificate Signing Request (CSR) file, saved as ca-ecc.csr. The following command specifies the basic information of the certificate through -subj, where:
 C=CN represents the country.
ST=State represents the province.
L=City represents the city.
O= Example Org represents the organization.
OU=Example CA represents the department.
CN=Example Root CA represents the common name of the certificate. In a CA certificate, this field can describe the purpose of the CA. If it is a domain name certificate, the domain name for certificate issuance needs to be specified in this field.
openssl req -new -key ca-ecc.key -out ca-ecc.csr -subj "/C=US/ST=State/L=City/O=Example Org/OU=Example CA/CN=Example Root CA"
3. Create the root certificate public key based on the certificate signing request file, with a validity of 3650 days, and save it as ca-ecc.crt. The -extfile parameter specifies this certificate as a CA certificate.
openssl x509 -req -in ca-ecc.csr -out ca-ecc.crt -signkey ca-ecc.key -days 3650 -sha256 -extfile <(printf "basicConstraints=critical,CA:TRUE\nkeyUsage=critical,keyCertSign,cRLSign\nsubjectKeyIdentifier=hash\n")
4. Issue the certificate and verify whether it is a CA certificate.
openssl x509 -in ca-ecc.crt -noout -text | grep -A2 "X509v3 Basic Constraints"
The output result contains CA:TRUE, which indicates a correct CA certificate. See the output result below:
X509v3 Basic Constraints: critical
                CA:TRUE    # Indicates the cert is a CA certificate.
            X509v3 Key Usage: critical
Step Two: Issue a Domain Name Certificate
To issue a certificate for the designated domain name www.example.com, you can use the generated CA certificate to start issuing a self-signed domain name certificate:
1. Generate the certificate private key through the following command, using an ECC certificate with the secp384r1 encryption algorithm as an example, and save the generated private key as a ecc-domain.key file.
openssl ecparam -name secp384r1 -genkey -noout -out ecc-domain.key
2. Use the above certificate private key to generate a Certificate Signing Request (CSR) file, saved as ecc-domain.csr. The following command specifies the basic information of the certificate through -subj. Please note to replace the CN field content with the domain name you want to issue, using www.example.com as an example in this case.
openssl req -new -key ecc-domain.key -out ecc-domain.csr -subj "/C=US/ST=State/L=City/O=Example Org/OU=Example CA/CN=www.example.com"
3. Sign the domain name certificate with the CA certificate, generate the public key with a validity of 3650 days, and save it as ecc-domain.crt.
openssl x509 -req -in ecc-domain.csr -out ecc-domain.crt -CA ca-ecc.crt -CAkey ca-ecc.key -days 3650
4. Compare the CA certificate with the domain name certificate public key to verify whether the certificate chain of the issued domain name certificate is correct.
openssl verify -CAfile ca-ecc.crt ecc-domain.crt
If the output result displays ecc-domain.crt:OK, it indicates that the certificate issuance chain is correct.
ecc-domain.crt: OK
﻿