# Jigasi or the transcriber rejects a private CA certificate

> A successful custom CA import does not prove Jigasi's running Java process uses that trust store. Issue #2344 reports this mismatch in stable-11248-1; stable-11248-2 adds the certificate-service property that preserves the custom trust store. Compare the exact error, release and service before upgrading, then verify the actual private TLS endpoint. [S1][S2][S3]

Source: https://jitsi.help/troubleshooting/jigasi-custom-ca-pkix-error/
Updated: October 25, 2026
Publisher: Jitsi Help (https://jitsi.help/)

## Match the symptom and the release

The upstream report concerns a Docker **transcriber using Jigasi in stable-11248-1**. The private CA was imported and independent TLS tests succeeded, but the running Jigasi process no longer retained `javax.net.ssl.trustStore`. Its outgoing WSS request failed with `SSLHandshakeException` and `PKIX path building failed`. These are the reporter's findings, not tests completed by this site. [S1]

PR #2345 explains the integration: Jigasi's certificate service sets the JVM trust store from `net.java.sip.communicator.service.cert.truststore.file` and removes it when that setting is absent. The corrected startup writes that setting when `/run/ca/cacerts` exists. The change shipped in `stable-11248-2`. [S2][S3]

Other causes remain possible: a missing mount, an unreadable or wrong CA file, a missing intermediate, an expired certificate, a hostname mismatch, an unreachable endpoint or a different TLS client. Do not diagnose all transcription failures as this regression.

## Docker first: check the correct service and mount

[Identify the running images](/guides/check-jitsi-version/) and whether the failing service is `jigasi` or `transcriber`. They use different host configuration directories. The pinned `stable-11248-2` Compose files mount: [S4]

| Service | Host directory under the actual CONFIG | Container CA directory |
| --- | --- | --- |
| `jigasi` | `jigasi/custom-ca` | `/usr/local/share/ca-certificates` |
| `transcriber` | `transcriber/custom-ca` | `/usr/local/share/ca-certificates` |

The custom CA initializer accepts certificate files directly in that directory; nested folders are ignored. It builds a merged system bundle and a Java store under `/run/ca`. Use CA certificates approved for the endpoint, not private keys. Keep your existing Compose overlays and resolved host `CONFIG`; a directory created under another home folder will not populate the running container. [S5]

The standard files mount CA inputs read-only. Do not remove the root filesystem's protections or write into system certificate directories inside a running container to make a test succeed.

## Check generated configuration without exposing credentials

For an already running **transcriber**, these Linux-host examples inspect only the expected files and trust-store property. Include your actual Compose project and file options:

```bash
docker compose exec -T transcriber sh -c \
  'test -r /run/ca/ca-certificates.crt && test -r /run/ca/cacerts'

docker compose exec -T transcriber sh -c \
  'grep -F "net.java.sip.communicator.service.cert.truststore.file=/run/ca/cacerts" /run/jigasi/config/sip-communicator.properties'
```

Use `jigasi` instead of `transcriber` only when that is the actual failing service. A zero exit status from the first command establishes readable files; the second establishes the expected generated property. Neither proves that the live Java client successfully connects. The store is not expected to exist when no custom CA is configured. [S3][S5]

Do not publish the complete properties file, process environment, connection URLs or logs: those can contain credentials and private endpoint details. Keep a sanitized error excerpt with the image version and the distinction between import, generated configuration and handshake.

## Apply the released correction and retest

If the release and error match, use the [matched-release upgrade workflow](/guides/upgrade-jitsi-docker/) to evaluate `stable-11248-2`. Preserve persistent input files and optional Compose files, plan downtime, back up first and verify the new running images. Do not treat an in-container manual edit as a permanent deployment correction. [S2][S3]

Then repeat the actual transcription or SIP path that failed, with a disposable meeting and approved test endpoint. Confirm a successful TLS connection to the intended hostname and a useful service result. A browser trusting the same certificate does not prove the container's Java client trusts it.

If PKIX errors remain after the correction, inspect the actual chain and CA selection with the endpoint operator. Do not disable certificate verification. Keep certificate trust separate from transcription provider credentials, model availability, WebSocket routing and meeting authorization.

## Package installations and verification limits

The `/run/ca` initializer and Compose mount examples are Docker-release details. Debian and Ubuntu package installations need their installed Jigasi certificate-service configuration and Java trust-store lifecycle checked separately. Copying a Docker runtime path into a host package is not a package setup procedure.

Reviewed 25 October 2026 against the issue, merged correction and pinned release files. We did not reproduce the TLS failure, load a private CA into a running server or verify a real WSS/SIP/transcription connection. The upstream correction is released; these installation checks remain recommendations to perform on your setup.

## Sources

- **[S1]** [Issue #2344](https://github.com/jitsi/docker-jitsi-meet/issues/2344), reported 23 October 2026; checked 25 October.
- **[S2]** [stable-11248-2 release](https://github.com/jitsi/docker-jitsi-meet/releases/tag/stable-11248-2), published 23 October.
- **[S3]** [Merged correction #2345](https://github.com/jitsi/docker-jitsi-meet/pull/2345) and [corrected Jigasi startup](https://github.com/jitsi/docker-jitsi-meet/blob/74d3e6edbb275d700d25de71bddc7088a78b1af4/jigasi/rootfs/etc/s6-overlay/scripts/config).
- **[S4]** Pinned release [Jigasi Compose file](https://github.com/jitsi/docker-jitsi-meet/blob/74d3e6edbb275d700d25de71bddc7088a78b1af4/jigasi.yml) and [transcriber Compose file](https://github.com/jitsi/docker-jitsi-meet/blob/74d3e6edbb275d700d25de71bddc7088a78b1af4/transcriber.yml).
- **[S5]** [Custom CA initializer](https://github.com/jitsi/docker-jitsi-meet/blob/74d3e6edbb275d700d25de71bddc7088a78b1af4/base/rootfs/usr/bin/setup-custom-ca), certificate input and generated-store behavior in the reviewed release.

## Frequently asked questions

### Does a successful CA import prove Jigasi will trust my WSS service?

No. File import, the Java process's effective trust configuration and a successful TLS handshake are separate checks. Issue #2344 reports an imported CA that was not used by the running Jigasi process.

### Which release corrects the reported Jigasi trust-store problem?

stable-11248-2 includes PR #2345. It sets Jigasi's certificate-service trust-store property when the generated custom Java store exists. This does not fix every possible certificate-chain or hostname problem.

### Should I disable TLS verification or trust all certificates?

No. Preserve verification and use the intended CA, a complete server certificate chain and the correct hostname. Diagnose the release-specific configuration without converting a trust error into unverified connections.


---

Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.