Currently, HTTPS has become the mainstream method of network communication and is widely used in various websites and services, especially in scenarios involving the transmission of sensitive information. HTTPS is built on the SSL/TLS protocol, providing an encrypted communication channel that ensures the security and integrity of data transmission, effectively preventing data leakage and tampering.

SSL certificates, as a key implementation of the SSL/TLS protocol in practice, play a crucial role in verifying server identities and securing data transmission.

Core Concepts of SSL Certificates

Before diving deep into SSL certificates, we need to understand the core elements of their operation, primarily involving the concepts of public and private keys.

• Public Key: Used to encrypt information. Once information is encrypted with the public key, only the corresponding private key can decrypt and read the content.

• Private Key: Used to decrypt information. It has a one-to-one relationship with the public key, meaning the private key can only decrypt information encrypted by the corresponding public key.

Public and private keys are generated as a pair through an algorithm; they are mathematically related but cannot be feasibly derived from one another. The public key is openly available and can be accessed by anyone, while the private key is confidential and known only to the key holder, which is the cornerstone of asymmetric encryption algorithms.

For example, suppose you want to exchange encrypted information with a bank's website. The basic process is as follows:

1. The bank first provides you with its public key. This public key is disclosed securely (e.g., on the bank’s official website or through a trusted third-party certificate authority). The public key is part of a key pair used by the bank to receive encrypted information.

2. You use this public key to encrypt the private information you wish to send to the bank. The encryption ensures that only the person with the corresponding private key (i.e., the bank) can decrypt and read the information. Even if the encrypted data is intercepted by others, it cannot be decrypted because only the bank possesses the private key.

3. When the bank receives the encrypted information, it uses its private key to decrypt it. Since the private key is unique to the bank and paired with the public key, the bank can successfully decrypt and read the private information you sent.

4. After decrypting and reading your information, the bank processes your request or instructions accordingly. If necessary, the bank can also use your public key to encrypt its reply to ensure the security of its response.

While this encryption communication process seems perfect, there is a risk: the public key you initially received might not be from the bank but from an imposter posing as the bank. This means that if you use this counterfeit public key for encryption without verifying its authenticity, any intercepted information can be decrypted by the corresponding counterfeit private key, leading to information leakage.

To address this issue, a mechanism is needed to verify the legitimacy of the public key. This is where the concept of Certificate Authority (CA) comes into play. CA is specifically responsible for issuing CA certificates used to validate the authenticity of public keys. If the public key is illegal, it should not be used for encryption.

An SSL certificate is a type of CA certificate issued by a CA. It includes the server's public key and the CA's signature, while the private key is typically held by the server owner. Together, the public and private keys work to ensure data transmission's security and integrity.

After understanding the concepts of public keys, private keys, and CA certificates, the next step is to explore how these concepts are applied in real-world communication. Since SSL certificates are used for communication encryption, it’s essential to understand how to deploy these certificates correctly to ensure communication security and data confidentiality.

How to Deploy Certificates on API Gateways?

After understanding the core concepts of SSL certificates, let's discuss how to deploy them. In practice, certificates are usually deployed on gateways because gateways act as entry points for all client requests, playing a critical role in receiving, distributing, processing, filtering, and encrypting data between networks.

From a management perspective, deploying certificates on the gateway greatly simplifies the certificate management process. Since all encrypted communication occurs through the gateway, SSL certificates only need to be configured and managed on the gateway rather than individually on each server requiring encrypted transmission.

For example, in the open-source gateway Apache APISIX, deploying SSL certificates involves two main steps:

1. Prepare the SSL Certificate: Purchase an SSL certificate from a CA or generate a self-signed certificate (for testing environments only) and obtain the certificate files (.crt or .pem format) and private key files (.key format).

2. Add Certificate Resources via Admin API: APISIX provides Admin API that allows you to dynamically create, update, and delete SSL resources. You can configure SSL resources using an HTTP PUT request by specifying the certificate, key, and optional SNI (Server Name Indication) list.

To configure an SSL resource for the domain test.com, you can use a command similar to the following:

curl http://127.0.0.1:9180/apisix/admin/ssls/1 \  
-H 'X-API-KEY: your-api-key' -X PUT -d'  
{  
    "cert" : "'"$(cat t/certs/apisix.crt)"'",
     "key": "'"$(cat t/certs/apisix.key)"'",
     "snis": ["*.test.com"]
}'

If you are using NGINX, you must reload the configuration after setting up the SSL certificate. However, APISIX supports hot reloading, so the certificate configuration takes effect immediately after adding the SSL resources.

SSL Certificate Workflow

Once the SSL certificate is configured, when a client attempts to connect to test.com or its subdomains (e.g., www.test.com, as specified in the SNI list *.test.com) via HTTPS, APISIX will use the provided certificate and key to establish a secure connection. The general workflow is as follows:

1. Handshake Phase: When the APISIX server receives a request on the HTTPS port (default: 9443), it initiates the SSL handshake process. During this process, APISIX sends the pre-configured SSL certificate to the client. The certificate includes the server’s public key and information about the CA. The client validates the certificate, checking whether it is issued by a trusted CA, whether it is within its validity period, and whether the domain name matches the requested domain. If validation passes, the client generates a random number as a Pre-Master Secret, encrypts it with the server’s public key, and sends it to the server.

2. Key Exchange: APISIX decrypts the Pre-Master Secret using the private key from the SSL resource, obtaining the Pre-Master Secret. Both the client and server use this Pre-Master Secret and other parameters (such as random numbers and protocol versions) to compute a shared Session Key, which will be used for subsequent encryption and decryption.

3. Data Transmission: After key exchange, a secure encrypted channel is established between the client and the APISIX server. The client uses the Session Key to encrypt the data before sending it to the APISIX server, which then decrypts it using the same Session Key to obtain the original data. Similarly, APISIX encrypts data before sending it back to the client.

4. Process Request and Return Response: APISIX processes the received request (now decrypted) according to the configured routes. Before returning a response, APISIX encrypts the response data with the Session Key to ensure secure transmission.

5. Close Connection: After communication is complete, the client and the APISIX server securely close the SSL connection and release related resources.

Key Points in SSL Certificate Management

SSL certificates ensure secure and encrypted communication between the client and the server. However, SSL certificates alone are not enough to guarantee long-term communication security; understanding the importance of SSL certificate management is also crucial. Effective certificate management ensures the ongoing validity and security of certificates, preventing security risks caused by expired certificates or mismanagement.

When managing SSL certificates on gateways, the following key points should be noted:

1. SSL certificates have a fixed validity period. Once expired, the browser will display warnings when accessing the site, negatively impacting user experience and website trust. Administrators should regularly check certificate validity and set up reminders to renew certificates promptly before expiration.

2. As business scales grow, manually managing SSL certificates becomes increasingly impractical. To minimize human error and save time, it is recommended to use automation tools (e.g., ACME clients, Certbot) to automatically apply for, deploy, update, and revoke certificates.

3. Centralize monitoring of SSL certificate status and performance to promptly detect and resolve any potential issues. Set up effective alert strategies to notify administrators immediately if certificates are about to expire, exhibit anomalies, or contain security vulnerabilities.

Conclusion

In summary, SSL certificates play an essential role in ensuring the security of network communication. By understanding the principles and management of SSL certificates and deploying them effectively on gateways, we can significantly enhance the security and integrity of data transmission. This not only protects sensitive information from leakage or tampering but also improves user experience and website trustworthiness.