Authenticating...
Skip to main content

0066: Enforce Cloudflare Full Strict SSL Mode Across AdGem Domains

STATUS​

Accepted

CONTEXT​

We were recently asked by a client in a security questionnaire the following question:

"Is the personal information sent to each processing location in cleartext?"

We interpreted that question as meaning whether we use HTTPS throughout the journey of a request until reaching the final processing location which for us would be our private VPC hosted in AWS.

We answered this question saying that we always use HTTPS and therefore personal information is not sent over cleartext.

It was recently discovered though that not all of our properties use HTTPS all the way to the VPC.

The domain adgem.com for instance, uses the Flexible SSL mode on Cloudflare which means SSL (HTTPS) is terminated at Cloudflare and then the requests from the Cloudflare proxy to our Load Balancers is done over plaintext (HTTP).

The domain cosmicrewards.com correctly uses the Full Strict SSL mode on Cloudflare which means all requests from the Cloudflare proxy are sent to our Load Balancers over HTTPS using a SSL certificate provisioned in AWS.

An additional reason for adopting this policy on adgem.com is so we can enable the Cloudflare Proxy for our new offerwall-ui project. This project uses AWS Amplify and provisions its own SSL certificate and forces all requests to use HTTPS. This creates an endless loop when used with the Flexible SSL mode (see ERR_TOO_MANY_REDIRECTS) as Cloudflare terminates HTTPS and sends a HTTP request to Amplify which redirects the request back to cloudflare over HTTPS. To date, we've been running Amplify without the Cloudflare Proxy, but we've discovered that the performance of the offerwall has seen a decline globally and one possible answer could be due to the absence of the Cloudflare Proxy. The old offerwall lived in the AdGem API project which ran over HTTP and avoided this endless loop. There are other possible explanations for the decline such as an increased number of back-end requests on the new project causing the offerwall performance to be unusable by some global users. Or it is possible that the new UI is not as resilient to slow performance as the old offerwall.

ERR TOO MANY REDIRECTS

Considered Options​

Solutions​

  • [Chosen] Provision origin TLS certificates and configure HTTPS listeners on the ALBs for projects under the adgem.com domain (API, Dashboard, Service Hub) and enable Full Strict Mode
  • Disable HTTPS on Amplify to remove endless loop

Approach​

  • [Chosen] Create a centralized CDK app AdGem-Infrastructure to provision and manage TLS certificates and DNS records for all adgem.com domains. This avoids drift by keeping certificate lifecycle in a single repo with clear ownership.

    Rejected alternatives:

    • Manually provision certificates in the AdGem AWS Account — rejected due to lack of repeatability and audit trail.
    • Per-service CDK apps (e.g., in the API repo) — rejected because scattering certificate management across repos leads to inconsistent configuration and ownership ambiguity.

DECISION​

We believe it is in our best interest to move forward with enabling Full Strict mode on all of our domains to align better with security best practices. In addition, it will give us a way to test the impact the Cloudflare proxy has on the performance of the new offerwall-ui.

We also believe it is in our best interest to create a new CDK app to provision the certificate so we can reuse this code if AdGem is moved to its own accounts.

Steps​

  • Create CDK project and GitHub repo for AdGem Infrastructure
  • Add certificate and DNS provisioning for nextadgem.com and adgem.com to AdGem Infrastructure
  • Test the provisioning in the CDK App in a Sandbox AWS account
  • Deploy the CDK project to the AdGem AWS Account (172122050326)
  • Add ebextension to API, Dashboard, and Service Hub that associates the SSL certificate with the project load balancers and 443 traffic.
  • Deploy the ebextension update to staging for all projects.
  • Enable the Full Strict mode on nextadgem.com and smoke test all impacted projects (service hub, dashboard, api, and offerwall-ui).
  • Deploy the ebextension to production for all projects.
  • Enable the Full Strict mode on adgem.com and smoke test all impacted projects (service hub, dashboard, api, and offerwall-ui).
  • Monitor AdGem performance and look for any drops possibly attributed to this change and evaluate non-US traffic post-change. Key metrics to watch:
    • SSL/TLS handshake failure rate between Cloudflare and origin
    • HTTP 5xx and Cloudflare 521 (Web Server Is Down) error rates
    • Time to First Byte (TTFB) and API response times across regions

CONSEQUENCES​

All of our applications running on the adgem.com domain that use the Cloudflare Proxy must support HTTPS requests.

DNS Entries

Risks​

The Cloudflare SSL mode toggle applies per-zone (domain), so the switch affects all proxied records under that zone at once. There is a possibility of an outage if ALBs are not serving TLS before the mode is changed. We mitigate this by validating the full setup on nextadgem.com first before touching adgem.com, and by confirming each service's ALB has a working HTTPS listener before flipping the mode. Rollback is straightforward — switching Cloudflare back to Flexible mode is instant.

There are several applications that will be impacted by this change and so it has considerable blast radius.

SSL Certificate Expiration — If origin certificates expire, Cloudflare Full Strict will reject the connection and services go down. We mitigate this by using ACM, which handles automatic renewal. We should set up monitoring and alerts on certificate expiration dates.

Load Balancer Misconfiguration — Errors configuring HTTPS listeners on ALBs could cause outages or improper routing. We mitigate this by testing configurations in a staging environment first, using CDK to automate and version-control the changes, and having configurations peer-reviewed before deployment. Rollback is possible by reverting to the last known good CDK deployment.

NOTES​

References​

Original Author​

Nick Haynes

Approval date​

Approved by​

Appendix​

N/A