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 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:
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 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, reported 23 October 2026; checked 25 October.
- [S2] stable-11248-2 release, published 23 October.
- [S3] Merged correction #2345 and corrected Jigasi startup.
- [S4] Pinned release Jigasi Compose file and transcriber Compose file.
- [S5] Custom CA initializer, certificate input and generated-store behavior in the reviewed release.