How HTTPS Secures Web Traffic: Encryption, PKI, and Certificate Chains Explained

What Problems Does HTTPS Solve

HTTPS addresses two key issues: encrypted transmission to keep client‑server data confidential, and identity authentication to verify the server’s legitimacy and prevent impersonation.

Symmetric Encryption Algorithms

Symmetric encryption uses a single key, which can be vulnerable to key enumeration, so its security is limited. Common symmetric algorithms include DES, 3DES, and AES . Because symmetric encryption is faster, HTTPS uses it for content encryption after a key is negotiated via asymmetric encryption.

Asymmetric Encryption Algorithms

Asymmetric algorithms rely on mathematically hard problems and include RSA and ECC. They involve a public key and a private key.

Encryption: Using the public (or private) key to transform plaintext into ciphertext (e.g., RSA).

Decryption: Using the counterpart key to recover plaintext from ciphertext.

The sender encrypts data with the receiver’s public key; the receiver decrypts with its private key.

For identity authentication, the signer creates a digital signature with its private key, and the verifier checks it using the signer’s public key.

Asymmetric Encryption Scenarios – Identity Authentication and PKI

Identity Authentication

Digital signatures serve as identity proof because a private key is unique and secret, similar to a fingerprint. However, the question arises: how does the other party know that a given public key truly belongs to you?

How to Prove "I Am Me"

In the physical world, you would present an official ID issued by a trusted authority. In the digital world, a similar trusted authority exists: the Certificate Authority (CA).

PKI (Public Key Infrastructure) Basics

PKI is the foundational security infrastructure. CAs issue certificates that bind a public key to an entity’s identity. Users verify a certificate’s validity to confirm they are communicating with the intended party. Obtaining a certificate from a CA usually incurs a fee.

Certificate Issuance Process

The applicant generates a CSR (Certificate Signing Request) containing the public key and identity information.

Select a CA (e.g., Amazon, GlobalSign, or a free provider).

Submit the CSR; the CA validates the identity and signs the CSR, producing a deployable public‑key certificate.

The signed certificate is returned to the applicant.

With a trusted CA signature, clients can trust the certificate because root certificates are pre‑installed in browsers and operating systems.

When many certificates are issued, CAs may create intermediate certificates or cross‑certificates to delegate trust and manage load.

Intermediate and Cross Certificates

Intermediate Certificate: Signed by a root CA’s private key, it signs end‑entity certificates.

Cross Certificate: A mutual signing between different root CAs, altering the trust starting point.

Trust Chain and Trust Anchor

A trust chain is built by verifying each certificate’s signature with the issuer’s public key, moving from the server’s certificate up to a trusted root certificate (the trust anchor) stored in the client.

Different browsers use different root stores: Chrome relies on the system’s root store, while Firefox maintains its own.

Nginx Certificate Deployment and Verification

Deploy certificates in Nginx using base64‑encoded files. Example configuration:

<code>ssl on;
ssl_certificate /opt/soft/ssl/0xfe.com.cn_chain.crt;
ssl_certificate_key /opt/soft/ssl/0xfe.com.cn_key.key;</code>

The

.crt

file contains the public‑key certificate; the

.key

file holds the private key.

Certificate decoding (using an online tool) yields:

<code>CER decoding result:

Common Name: 0xfe.com.cn
Subject Alternative Names: DNS:0xfe.com.cn, DNS:www.0xfe.com.cn
Validity: 2019‑08‑16 to 2020‑08‑15
Serial Number: 8239351073242680476627775209099171701
Issuer: TrustAsia TLS RSA CA
Expires: 2020‑08‑15 20:00:00</code>

Decoding the intermediate certificate shows:

<code>CER decoding result:

Common Name: TrustAsia TLS RSA CA
Organization: TrustAsia Technologies, Inc.
Validity: 2017‑12‑08 to 2027‑12‑08
Serial Number: 7311534772508790650765434802415791662
Issuer: DigiCert Global Root CA
Expires: 2027‑12‑08 20:28:26</code>

The full trust chain is:

<code>0xfe.com.cn <---- verifies ----> TrustAsia TLS RSA CA <---- verifies ----> DigiCert Global Root CA (present in the client)</code>

Similarly, Baidu’s certificate chain is:

<code>baidu.com <---- verifies ----> GlobalSign Organization Validation CA - SHA256 - G2 <---- verifies ----> GlobalSign Root CA (present in the client)</code>

Using GlobalSign Cross‑Certificates to Change the Trust Anchor

MacOS includes five GlobalSign root CAs (R1‑R5). When a client lacks a newer root (e.g., R4), certificates issued by that root appear untrusted.

In such cases, GlobalSign provides a cross‑certificate that links the newer root to an older root already trusted by the client, restoring trust without re‑issuing intermediate certificates.

Example of a missing root scenario:

<code>baidu.com <---- verifies ----> GlobalSign Organization Validation CA - SHA256 - G2 <---- verifies ----> GlobalSign Root CA - R4 (not present on client)</code>

Solution: Append the cross‑certificate (R1‑R4) after the server’s public‑key certificate in Nginx, shifting the trust anchor from R4 to R1, which the client trusts.

<code>baidu.com <---- verifies ----> GlobalSign Organization Validation CA - SHA256 - G2 <---- verifies ----> R1‑R4 cross‑certificate <---- verifies ----> GlobalSign Root CA - R1 (trusted)</code>

GlobalSign announced that as of 27 May 2019, new intermediate CAs using RSA keys will chain to GlobalSign R3 root. Users should ensure the appropriate root (R1‑R3) is present in their systems.

After updating, the intermediate certificate chain points to the R3 root:

Users of GlobalSign certificates should add the appropriate cross‑certificate to avoid trust‑anchor issues on clients lacking the newer root.