SSL certificate problem: unable to get local issuer certificate – Elasticsearch connection in Sulu
0 reputation · 22 Apr 2021, 12:29 UTC
0 reputation · 22 Apr 2021, 12:29 UTC
Sulu relies on Symfony’s HttpClient, wrapped by the Elastica library, to talk to Elasticsearch. When the Elasticsearch endpoint is HTTPS and presents a self‑signed or otherwise untrusted certificate, the client throws a TransportExceptionInterface with the message SSL certificate problem: unable to get local issuer certificate.
The Sulu elasticsearch.yaml file only exposes host, port, index, and authentication settings; it does not provide a way to pass SSL context options such as verify or a custom CA bundle. Consequently, the default system CA store is used, and any certificate not signed by a known authority triggers the error.
Developers must decide how to handle SSL verification for Elasticsearch: add the certificate to the system store, supply a custom CA file, or disable verification entirely (which weakens security). The documentation does not clarify whether future Sulu releases will allow configuring these options.
35775 reputation · 23 Apr 2021, 00:08 UTC
No, Sulu does not provide a native configuration key in elasticsearch.yaml for a custom CA bundle, and it does not expose a toggle for SSL verification. The safest approach is to trust the Elasticsearch server certificate at the operating-system level so PHP's cURL/OpenSSL layer can verify the chain.
Sulu uses the Elastica library, which wraps Symfony's HttpClient. When the Elasticsearch endpoint uses HTTPS with a self-signed or private-CA certificate, the client falls back to the system CA store. Because Sulu's configuration layer only exposes host, port, index, and authentication settings, there is no direct path to pass verify or a custom CA file to the transport layer without a service override or environment change.
Adding the Elasticsearch CA to the operating-system trust store is the preferred production solution because it keeps verification enabled and scopes the trust to the host.
sudo cp elasticsearch-ca.crt /usr/local/share/ca-certificates/sudo update-ca-certificatesIf you cannot modify the system store, you can override the Elastica\Client service definition to supply a CA file path to the underlying HttpClient options. This requires editing config/services.yaml and should be limited to the Elasticsearch client so that verification remains enabled for all other outbound HTTP calls.
Do not disable verification globally. Setting verify: false removes certificate validation and exposes the connection to man-in-the-middle attacks. It is acceptable only in isolated local test environments.
Confirm your Sulu version with composer show sulu/sulu, inspect config/packages/elasticsearch.yaml to confirm no CA-related key exists, and retry the connection after updating the trust store.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.