Understanding HTTPS Certificates, Trust Chains, and Security Practices

Certificate Trust

Even when using HTTPS, a client may connect to a malicious server that also presents a valid‑looking certificate; the client must decide whether to trust the server's certificate based on its issuance by a trusted Certificate Authority (CA).

How to Distinguish CA‑Issued Certificates

A certificate contains information such as the subject, domain, validity period, and a digital signature. The issuance process involves creating a certificate request, uploading it to a CA, the CA verifying the request, hashing the request data, signing the hash with its private key, and returning the signed certificate.

When a browser receives the certificate, it hashes the certificate data (producing value A) and uses the CA’s public key (from the trusted root store) to decrypt the digital signature (producing value B). If A equals B, the certificate is confirmed to be CA‑issued.

If a CA’s private key is compromised, attackers can forge certificates.

Beyond CA Verification

In addition to confirming CA issuance, browsers must check the certificate’s validity period, domain match, and other constraints.

Is HTTPS Always Safe?

Even with HTTPS and a correct domain, security can be undermined if an attacker installs a malicious root certificate on the client machine, causing the browser to trust forged certificates without warnings.

Why Adopt HTTPS

HTTPS protects user privacy, especially for e‑commerce sites that handle personal data such as phone numbers and addresses.

Pre‑Launch Considerations

When rolling out HTTPS globally, factors like varying network speeds across countries, which pages need HTTPS, and which platforms (PC, mobile web, apps) require it must be evaluated.

Data Survey

Performance data and page‑level analytics were collected to identify regions with slow networks where HTTPS rollout might be deferred, and to decide which non‑sensitive pages can remain on HTTP.

Launch Goals

Enable gradual rollout (by country, user segment, device).

Provide a quick toggle to enable or pause HTTPS for specific regions.

Implement protocol enforcement (redirect HTTP to HTTPS for pages handling personal data).

Additional Work Beyond Development

Identify pages that must use HTTPS and coordinate with front‑end teams to minimize redirects.

Audit static resources (JS, CSS, images) to ensure they are served over HTTPS.

Configure servers and purchase certificates.

Static resources pose challenges because HTTPS pages require all resources and Ajax calls to be HTTPS; some older mobile browsers may allow mixed content, but the goal is full HTTPS compliance.

Static Resource Strategies

Protocol‑relative URLs (using "//" instead of "http://") so the browser automatically matches the current scheme.

Update content management systems to store resources with protocol‑relative URLs.

Perform server‑side rewriting for legacy systems that cannot be changed directly.

To guard against missed resources, a security header is added.

Protective Measure – CSP

Content-Security-Policy: upgrade-insecure-requests

This header (or the equivalent meta tag) instructs browsers to automatically upgrade any HTTP resource on an HTTPS page to HTTPS, provided the domain supports both protocols. Not all browsers support this feature.

Final Thoughts

The article acknowledges additional topics not covered, such as HSTS, asymmetric encryption algorithms, keyless TLS, session identifiers, and performance optimizations for TLS connections.