docs(enterprise): document trusting a private CA - #12659
Merged
mergify[bot] merged 1 commit intoSep 3, 2026
Merged
Conversation
Contributor
Merge Protections🟢 All 6 merge protections satisfied — ready to merge. Show 6 satisfied protections🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
There was a problem hiding this comment.
🟢 Approval recommended
Only minor wording/grammar nits were found, with no functional or structural documentation issues identified.
Pull request overview
Adds dedicated Enterprise documentation for trusting private/self-signed CAs and updates existing Enterprise docs to recommend using MERGIFYENGINE_EXTRA_CA_BUNDLE (with caveats) instead of disabling TLS verification, then links the new guidance from key operator “failure points” (connectivity checks and outbound subscription calls).
Changes:
- Add a new Enterprise docs page covering
MERGIFYENGINE_EXTRA_CA_BUNDLEusage, caveats, and verification steps. - Update Installation, Requirements, Troubleshooting, and Enterprise overview pages to link to the new Private CA guidance.
- Add “Private CA” to the Enterprise navigation.
File summaries
| File | Description |
|---|---|
| src/content/enterpriseNavItems.ts | Adds the new “Private CA” entry to the Enterprise nav. |
| src/content/docs/enterprise/custom-ca.mdx | New page documenting how to trust a private/self-signed CA bundle and related caveats. |
| src/content/docs/enterprise/installation.mdx | Reorders guidance to prefer CA bundle for Redis/PostgreSQL TLS verification and links to the new page. |
| src/content/docs/enterprise/requirements.mdx | Notes egress proxy TLS interception implications and links to the new page. |
| src/content/docs/enterprise/troubleshooting.mdx | Links connectivity-check certificate verification failures to the new page. |
| src/content/docs/enterprise.mdx | Adds a top-level pointer to the new “Trusting a Private CA” page. |
Review details
- Files reviewed: 6/6 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
jd
previously approved these changes
Sep 2, 2026
sileht
force-pushed
the
devs/sileht/docs-enterprise-custom-ca/document-trusting-private-ca--b0ef33d6
branch
from
September 2, 2026 13:24
a6d130b to
b1240b9
Compare
Member
Author
Revision history
|
sileht
marked this pull request as ready for review
September 2, 2026 13:24
sileht
force-pushed
the
devs/sileht/docs-enterprise-custom-ca/document-trusting-private-ca--b0ef33d6
branch
from
September 2, 2026 13:27
b1240b9 to
1fe01fa
Compare
The enterprise docs never said how to make an on-premise deployment trust a private or self-signed certificate authority, and installation.mdx told operators to disable Redis TLS verification instead, which is the anti-pattern this was raised about. Add an enterprise page for MERGIFYENGINE_EXTRA_CA_BUNDLE: what belongs in the bundle, how to mount it, how to confirm it took effect, and the places where the setting alone is not enough. PostgreSQL needs sslmode=verify-full before libpq consults the roots at all, REDIS_SSL_VERIFY_MODE_CERT_NONE overrides the bundle, SSL_CERT_DIR reaches only part of the engine, and the bundle is read once per process so rotating the CA needs a restart. The PostgreSQL and Redis caveats come before the verification steps on purpose: a connectivity check against a connection that verifies nothing reports ok either way. installation.mdx now leads its self-signed Redis section with the bundle and keeps REDIS_SSL_VERIFY_MODE_CERT_NONE only as the fallback for a certificate you cannot obtain, while still telling a truly self-signed deployment to put the server certificate itself in the bundle, and pointing managed-Redis users at the CA their provider publishes. Its vague PostgreSQL "configure the connection options accordingly" becomes the concrete sslmode. The section heading is unchanged so its existing anchor keeps resolving. Troubleshooting and requirements link the page from the two places an operator hits the wall: a connectivity check that fails on certificate verification, and an egress proxy that re-signs the subscription calls. Fixes MRGFY-8831 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018XJzBXXpAFeRk3pLsADvjw Change-Id: Ib0ef33d61614b688512cfe24897e121790072193
sileht
force-pushed
the
devs/sileht/docs-enterprise-custom-ca/document-trusting-private-ca--b0ef33d6
branch
from
September 2, 2026 13:33
1fe01fa to
bd960d6
Compare
jd
approved these changes
Sep 3, 2026
AlexandreGaubert
approved these changes
Sep 3, 2026
Contributor
Merge Queue Status
This pull request spent 3 minutes 5 seconds in the queue, including 2 minutes 22 seconds running CI. Required conditions to merge
|
63 tasks
mergify
Bot
deleted the
devs/sileht/docs-enterprise-custom-ca/document-trusting-private-ca--b0ef33d6
branch
September 3, 2026 07:45
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The enterprise docs never said how to make an on-premise deployment trust a
private or self-signed certificate authority, and installation.mdx told
operators to disable Redis TLS verification instead, which is the anti-pattern
this was raised about.
Add an enterprise page for MERGIFYENGINE_EXTRA_CA_BUNDLE: what belongs in the
bundle, how to mount it, how to confirm it took effect, and the places where
the setting alone is not enough. PostgreSQL needs sslmode=verify-full before
libpq consults the roots at all, REDIS_SSL_VERIFY_MODE_CERT_NONE overrides the
bundle, SSL_CERT_DIR reaches only part of the engine, and the bundle is read
once per process so rotating the CA needs a restart. The PostgreSQL and Redis
caveats come before the verification steps on purpose: a connectivity check
against a connection that verifies nothing reports ok either way.
installation.mdx now leads its self-signed Redis section with the bundle and
keeps REDIS_SSL_VERIFY_MODE_CERT_NONE only as the fallback for a certificate
you cannot obtain, while still telling a truly self-signed deployment to put
the server certificate itself in the bundle, and pointing managed-Redis users
at the CA their provider publishes. Its vague PostgreSQL "configure the
connection options accordingly" becomes the concrete sslmode. The section
heading is unchanged so its existing anchor keeps resolving.
Troubleshooting and requirements link the page from the two places an operator
hits the wall: a connectivity check that fails on certificate verification, and
an egress proxy that re-signs the subscription calls.
Fixes MRGFY-8831
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_018XJzBXXpAFeRk3pLsADvjw