Why SSL/TLS Certificates Are Shrinking to 47 Days and How HTTPS Secures Your Data

Recent news reports that the maximum validity period for SSL/TLS certificates will be reduced to 47 days. After several adjustments, the current maximum is 398 days (about 13 months), meaning developers and enterprises must renew certificates roughly every year.

The gradual shortening of certificate lifetimes reflects increasing security concerns from the CA/Browser Forum. In insecure environments such as public Wi‑Fi, sensitive information can be intercepted and altered by a man‑in‑the‑middle (MITM) attacker. HTTPS serves as a critical defense, and this article explores how it works and how certificates are validated.

Why Encryption Is Needed

The original HTTP protocol transmits data in clear text, exposing it to interception and tampering by intermediate devices such as routers, Wi‑Fi hotspots, and ISPs. This vulnerability is known as a MITM attack, which is why encryption is required.

Common Encryption Methods

2.1 Symmetric Encryption

Both parties use the same secret key for encryption and decryption. Typical algorithms include AES (Advanced Encryption Standard) and DES (Data Encryption Standard). For example, AES processes plaintext in 128‑bit blocks and applies multiple rounds of substitution, shifting, mixing, and key addition to produce ciphertext.

2.2 Asymmetric Encryption

Two different keys are used: a public key that can be shared openly and a private key that must remain secret. Data encrypted with the public key can only be decrypted with the matching private key, and vice versa. Common algorithms are RSA (Rivest‑Shamir‑Adleman) and ECC (Elliptic Curve Cryptography).

HTTPS Certificate Verification Process

3.1 Plaintext Communication

In a simple client‑server model without encryption, messages travel in clear text and are vulnerable to MITM attacks.

1. Client sends plaintext message "v我50" to Server
2. Server replies with plaintext "疯狂星期四"
3. Client is delighted

When the communication passes through intermediate devices, a MITM attacker can intercept and modify the messages, illustrating the need for encryption.

1. Client sends plaintext "v我50" to Server
2. MITM intercepts and changes it to "转我50"
3. Server replies with plaintext "我们不熟"
4. MITM forwards the reply unchanged
5. Client is left disappointed

To prevent MITM from reading the content, encryption must be introduced.

3.2 Symmetric Encryption Communication

Both client and server share a secret key E1. The communication flow is illustrated below.

1. Client encrypts "v我50" with E1 → ciphertext U2FsdGVkX1
2. Client sends ciphertext to Server
3. Server decrypts with E1 → "v我50"
4. Server encrypts "疯狂星期四" with E1 → ciphertext S6Vk01J1u
5. Server sends ciphertext to Client
6. Client decrypts with E1 → "疯狂星期四"
7. Client is delighted

However, this assumes both parties already share E1 securely, which is unrealistic in open networks.

3.3 Asymmetric Encryption Communication

Using a public/private key pair, the client can encrypt data that only the server can decrypt.

1. Client asks for server's public key
2. Server replies with PK1
3. Client encrypts "v我50" with PK1 → ciphertext U2FsdGVkX1
4. Client sends ciphertext to Server
5. Server decrypts with SK1 → "v我50"
6. Server encrypts "疯狂星期四" with SK1 → ciphertext S6Vk01J1u
7. Server sends ciphertext to Client
8. Client decrypts with PK1 → "疯狂星期四"
9. Client is delighted

Although the MITM can see the server's public key, it cannot decrypt the messages without the private key, limiting the attack to server‑to‑client direction.

3.4 Hybrid Encryption Communication

Hybrid encryption combines asymmetric key exchange with symmetric data encryption. The client obtains a symmetric key E1 securely via the server’s public key, then uses E1 for the bulk of the communication.

1. Client requests server's public key PK1
2. Server replies with PK1
3. Client encrypts symmetric key E1 with PK1 → ciphertext pTyLGTddEr
4. Client sends ciphertext to Server
5. Server decrypts with SK1 → obtains E1
6. Server and Client now share E1 for symmetric encryption
7. Subsequent messages are encrypted with E1, protecting confidentiality and integrity

If the MITM replaces the server’s public key with its own (PK2), it can decrypt the exchanged symmetric key and compromise the session, highlighting the importance of trusted certificates.

Certificate Authority (CA)

CA/Browser Forum was founded in 2005 to standardize SSL/TLS certificates. A digital certificate contains three parts: the clear‑text information T (public key, domain, organization), a hash algorithm M, and a digital signature S generated by the CA.

The certificate generation process:

1. Assemble clear‑text information T (public key, domain, organization)
2. Compute hash value using algorithm M
3. CA encrypts the hash with its private key to create digital signature S
4. Combine T and S to form the final CA‑signed certificate

4.1 Can a MITM Tamper with the Certificate?

A MITM cannot modify the certificate’s contents without the CA’s private key, so any alteration would invalidate the signature and be detected by the client.

4.2 Can a MITM Swap the Certificate?

Swapping the certificate would change the domain information, which the client verifies against the requested hostname, preventing successful substitution.

Complete Certificate Verification Process

The full TLS handshake involves exchanging random values, selecting cipher suites, and establishing a shared symmetric key E1.

1. Client sends ClientHello with supported TLS version, cipher suites, and random value RandomA
2. Server replies with ServerHello, its certificate (CA1), chosen TLS version, cipher suite, and random value RandomB
3. Client validates the certificate, generates random value RandomC, and encrypts it with the server’s public key PK1 → ciphertext HtjyMfqw
4. Client sends ciphertext to Server; both sides derive symmetric key E1 from RandomA, RandomB, RandomC
5. Server decrypts ciphertext, obtains RandomC, and uses E1 to encrypt "Finished" → ciphertext BFgENlNcc
6. Server sends ciphertext to Client; Client decrypts with E1 and confirms handshake completion
7. Subsequent application data is encrypted with E1, protecting confidentiality and integrity

Even with a reduced certificate validity period, the combination of asymmetric key exchange, trusted CAs, and symmetric encryption provides robust security, though advances in computational power continually pressure algorithms like RSA.

Conclusion

The HTTPS certificate verification process integrates multiple encryption techniques and security mechanisms, forming the foundation of modern internet security. Understanding these mechanisms is essential for protecting personal privacy and enterprise data, and the protocol will continue to evolve to meet emerging threats.

References

Zhihu column: https://zhuanlan.zhihu.com/p/43789231

GlobalSign blog: https://www.globalsign.cn/blog_detailed_225

hpbn.co: https://hpbn.co/