Skip to main content

Algolia DevCon - June 28-29, 2023

Discover the future of the AI Stack with Algolia, be the first to see new platform demos and announcements, and get the most out of Algolia through interactive workshops.

REGISTER FOR FREE DON'T SHOW AGAIN
×

Notes on algolia.net domain SSL Certificate renewal in 2026

  • Updated

Summary

As a part of regular security practice, Algolia renewed the TLS certificate used for Algolia API endpoints (e.g., *.algolia.net / *-dsn.algolia.net) in January, 2026. Along with the renewal, the certificate chain presented during the TLS handshake changed. Most customers will see no impact, but older operating systems, runtimes, or CA bundles may fail to validate the new chain and cannot connect.

 

What changed

  • Leaf certificate renewal: the server certificate for algolia.net was renewed with a new validity period.

  • Chain update: the presented chain moved to a newer Sectigo “Public Server Authentication” hierarchy (e.g., R36/R46).

  • Legacy path differences: some older environments previously validated via legacy trust anchors (often present in older CA bundles). With the updated chain, those environments may no longer be able to build a trusted path.

Who may be affected

You may be impacted if you run Algolia clients on:

  • End-of-life or unpatched OS images (old Debian/Ubuntu/CentOS/Amazon Linux/Alpine, old Docker base images)

  • Older OpenSSL / LibreSSL / cURL versions bundled with the OS

  • Old language runtimes that depend on system trust stores

  • Old API clients

Examples reported by customers include legacy stacks such as:

  • PHP applications running on older distributions (e.g., PHP 7.1-era environments)

  • Ruby applications using older API clients (v1.X), OpenSSL builds / OS CA stores

Symptoms

Typical errors include (examples vary by language/library):

  • SSL certificate problem: unable to get local issuer certificate

  • certificate verify failed

  • unable to verify the first certificate

  • self signed certificate in certificate chain

  • SSL_connect returned=1 errno=0 state=error: certificate verify failed

If the issue is CA/trust-store related, connections may succeed from modern machines but fail from specific older servers/containers.

Root cause (most common)

The client environment cannot build a valid trust chain from the server certificate to a trusted root because its CA bundle/trust store is outdated (missing newer trust anchors), or its TLS stack performs limited path building.

Update the platform trust store and TLS libraries.

Identify which trust store your client uses (important)

Algolia API clients rely on each language/runtime’s underlying TLS implementation. Before changing anything, confirm whether your client validates TLS using:

  • the OS/system trust store (common for many Linux-based stacks), or

  • a runtime-specific trust store (for example, a JVM trust store), or

  • a library-bundled CA bundle (varies by HTTP library/distribution).

This matters because updating the wrong place (e.g., OS CA bundle when your runtime uses its own CA store) won’t resolve certificate validation errors.

General guidance:

  • PHP: commonly uses cURL/OpenSSL and the OS CA bundle, unless curl.cainfo/openssl.cafile is explicitly set.

  • Ruby: commonly uses OpenSSL and the OS CA bundle (exact behavior depends on the HTTP client and platform build). v1 uses library-bundled CA bundle

  • Java (if applicable): typically uses the JVM trust store (cacerts) rather than the OS store.

  • Other languages: behavior can vary by HTTP library and distribution; when in doubt, verify using the commands in the language-specific sections below and the openssl s_client test from the failing host.

Linux (most common fix)

  • Update OS packages (recommended), specifically:

    • ca-certificates

    • openssl / libssl

    • curl / libcurl

  • Rebuild/redeploy containers from a maintained base image.

 

Temporary workaround (if you cannot upgrade immediately)

If upgrading the OS/CA bundle is not immediately possible:

  • Provide a current CA bundle to your runtime and configure it explicitly.

    • For cURL/PHP: set curl.cainfo (php.ini) or pass the CA file to your HTTP client.

    • For Ruby/OpenSSL clients: configure the CA file/path used by OpenSSL (varies by client).

Important:

  • Do not disable certificate verification in production.

  • Treat this as a short-term mitigation; upgrading the platform remains the recommended fix.

You can also manually obtain certificates as described in this article.

 

How to verify

From the affected host/container, test the handshake and certificate chain:

  • Use SNI explicitly:

    • openssl s_client -connect <YOUR_APPID>-dsn.algolia.net:443 -servername <YOUR_APPID>-dsn.algolia.net -showcerts

  • If verification fails, it strongly indicates an outdated trust store/CA bundle on that host.

What Algolia is doing

We maintain industry-standard TLS configurations and regularly renew certificates for security and compliance. Certificate renewals and chain updates can occasionally surface outdated client environments.

Appendix: How certificate chains work (quick primer)

When you connect to an HTTPS endpoint, the server presents a certificate chain so the client can verify the server’s identity.

Key terms

  • Leaf (server) certificate: the certificate for the hostname you are connecting to (e.g., *.algolia.net).

  • Intermediate CA certificate(s): certificate(s) used to link the leaf certificate to a trusted root.

  • Root CA certificate: a top-level CA certificate that is already trusted by your system (stored in the OS/browser/runtime trust store).

  • Trust store / CA bundle: the set of root CA certificates your system trusts (e.g., /etc/ssl/certs, ca-certificates package).

How validation works (high level)

  1. The server sends the leaf certificate and usually one or more intermediate certificates.

  2. The client attempts to build a path from the leaf certificate “up” through intermediates to a trusted root in its trust store.

  3. Each link in the path is verified (signatures, validity dates, name/SAN match, key usage, and policy constraints).

  4. If the client cannot find a path to a trusted root, verification fails.

Why older clients can fail after a chain update

Even if the leaf certificate is valid, chain validation can fail when:

  • The client’s trust store is outdated and does not include the newer root CA needed to complete the path.

  • The client’s TLS stack has limited/buggy path building logic and cannot select an alternate valid path.

  • The server presents an unexpected or overly long chain (for example, including root certificates); some older stacks handle this poorly.

 

Reading openssl s_client -showcerts

Two parts of the output often confuse people:

  • Certificate chain (0,1,2,...): the certificates the server actually sent, in order.

  • depth=N lines: OpenSSL’s view of the verification path it is attempting (N=0 is the leaf). This may differ from the raw “Certificate chain” list if OpenSSL chooses a different path using local trust-store certificates.

Tip: For accurate endpoint testing, always include SNI:

  • openssl s_client -connect <host>:443 -servername <host> -showcerts

Related articles