Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.0
Oxia's TLS Certificate Validation Fails with Multi-Certificate Files
GHSA-7jrq-q4pq-rhm6
Summary
Oxia's TLS configuration has a bug that prevents it from properly checking the identity of clients using multi-certificate files. This can cause legitimate clients to be rejected, potentially forcing you to disable security checks. To fix this, use single-certificate files or wait for an update to the software.
What to do
- Update github.com oxia-db to version 0.16.2.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| github.com | oxia-db | <= 0.16.1 | 0.16.2 |
Original title
Oxia's TLS CA certificate chain validation fails with multi-certificate PEM bundles
Original description
### Summary
The `trustedCertPool()` function in the TLS configuration only parses the first PEM block from CA certificate files. When a CA bundle contains multiple certificates (e.g., intermediate + root CA), only the first certificate is loaded. This silently breaks certificate chain validation for mTLS.
### Impact
In deployments using mTLS with certificate chains (intermediate CA + root CA bundles), legitimate clients with properly chained certificates are rejected with `x509: certificate signed by unknown authority`. This degrades the security posture by making mTLS unusable with standard CA chain configurations, potentially forcing operators to disable client certificate verification.
All versions using TLS with `trustedCaFile` configuration are affected.
### Details
In `common/security/tls.go`, the `trustedCertPool()` method calls `pem.Decode()` only once, processing a single PEM block. The remaining bytes (containing additional certificates) are silently discarded. Additionally, the error return from `pem.Decode` is ignored, so a corrupted CA file results in an empty certificate pool without any error.
### Patches
Fixed by iterating over all PEM blocks in the file, parsing each CERTIFICATE block, and returning an error if no valid certificates are found.
### Workarounds
Use CA files containing only a single certificate (the direct issuer of client certificates, not a chain).
The `trustedCertPool()` function in the TLS configuration only parses the first PEM block from CA certificate files. When a CA bundle contains multiple certificates (e.g., intermediate + root CA), only the first certificate is loaded. This silently breaks certificate chain validation for mTLS.
### Impact
In deployments using mTLS with certificate chains (intermediate CA + root CA bundles), legitimate clients with properly chained certificates are rejected with `x509: certificate signed by unknown authority`. This degrades the security posture by making mTLS unusable with standard CA chain configurations, potentially forcing operators to disable client certificate verification.
All versions using TLS with `trustedCaFile` configuration are affected.
### Details
In `common/security/tls.go`, the `trustedCertPool()` method calls `pem.Decode()` only once, processing a single PEM block. The remaining bytes (containing additional certificates) are silently discarded. Additionally, the error return from `pem.Decode` is ignored, so a corrupted CA file results in an empty certificate pool without any error.
### Patches
Fixed by iterating over all PEM blocks in the file, parsing each CERTIFICATE block, and returning an error if no valid certificates are found.
### Workarounds
Use CA files containing only a single certificate (the direct issuer of client certificates, not a chain).
ghsa CVSS4.0
8.0
Vulnerability type
CWE-295
Improper Certificate Validation
Published: 14 Apr 2026 · Updated: 15 Apr 2026 · First seen: 15 Apr 2026