AWS Glue + Chargebee: Diagnosing CERTIFICATE_VERIFY_FAILED After TLS Chain Updates

Context

An AWS Glue job that consumes the Chargebee API begins failing with:

SSLError: &#91;SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: 
unable to get local issuer certificate

The same request works in Postman.

This pattern typically appears after a certificate chain rotation on the API provider side combined with an outdated trust store in the execution environment.

Chargebee announced updates related to its TLS certificate chain (DigiCert G2 becoming permanent in February 2026). When a runtime does not trust the updated intermediate/root CA, SSL validation fails.

Reference:
https://apidocs.chargebee.com/docs/api/getting-started
https://apidocs.chargebee.com/docs/api/tls_certificate_update_g2

Why It Works in Postman but Fails in AWS Glue

The discrepancy is environmental.

Postman

Uses an up-to-date CA bundle.
Often relies on the operating system trust store.
Ships with modern TLS handling by default.

AWS Glue

Runs inside a managed container runtime.
May use:
- A system CA store bundled with the Glue version.
- A bundled certifi version (if requests is used).
If the CA bundle does not trust the new DigiCert chain, verification fails.

The Chargebee SDK ultimately uses requests and urllib3, which perform strict certificate validation.

What the Error Actually Means

unable to get local issuer certificate

This does not mean:

The certificate is invalid.
The API endpoint is broken.

It means:

The client cannot build a trusted certificate chain from the server certificate to a known root CA in its trust store.

This is a client-side trust issue.

Correct Fix (Production-Safe)

Do not disable SSL verification (verify=False). That bypasses authentication guarantees and exposes credentials to interception.

Instead:

1. Update Dependencies in Glue

In the Glue Job configuration:

Glue Console → Jobs → Your Job → Job details → Default arguments

Add:

--additional-python-modules certifi==2025.1.31,requests==2.32.3,urllib3==2.2.3

This ensures:

Modern CA bundle
Compatible TLS stack

2. Force `requests` to Use `certifi`

In your Glue script, before any API call:

import os
import certifi

os.environ&#91;"REQUESTS_CA_BUNDLE"] = certifi.where()

This ensures that:

All requests calls (including those inside the Chargebee SDK)
Use the updated CA bundle shipped with certifi

Optional: Runtime Verification Debug

Add temporary diagnostics:

import certifi
import requests
import urllib3
import ssl

print("certifi:", certifi.__version__)
print("requests:", requests.__version__)
print("urllib3:", urllib3.__version__)
print("openssl:", ssl.OPENSSL_VERSION)
print("CA bundle:", certifi.where())

If Glue shows an outdated certifi or OpenSSL version compared to your local environment, that explains the discrepancy.

Alternative Root Cause: Corporate TLS Inspection

If your Glue job runs inside a VPC with outbound traffic routed through a proxy performing TLS inspection:

The proxy may inject its own certificate.
You must add the corporate root CA to the trust bundle.
This is different from a public CA rotation.

However, if only Chargebee fails and other HTTPS endpoints succeed, the most likely cause is a CA chain update.

Architecture Lesson

Cloud-managed runtimes are not identical to local environments. When an external API rotates its TLS chain:

Clients using outdated CA bundles break.
Environments with updated trust stores continue working.

In distributed data pipelines (Glue, Lambda, Spark), certificate trust management must be treated as part of dependency management.

Summary

The error is almost certainly due to a CA trust mismatch following Chargebee’s TLS chain update.

Postman works because its trust store is current.
Glue fails because its CA bundle is outdated.

Correct remediation:

Update certifi, requests, and urllib3 in Glue.
Explicitly point REQUESTS_CA_BUNDLE to certifi.where().
Avoid disabling SSL verification.

That restores secure TLS validation without compromising integrity.