Skip to content

Commit 9b3ea03

Browse files
committed
[DOCS] Reviews security.asciidoc.
1 parent cfabbdf commit 9b3ea03

File tree

1 file changed

+50
-31
lines changed

1 file changed

+50
-31
lines changed

docs/security.asciidoc

Lines changed: 50 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,16 @@
11
[[security]]
22
== Security
33

4-
The Elasticsearch-PHP client supports two security features: HTTP Authentication and SSL encryption.
4+
The Elasticsearch-PHP client supports two security features: HTTP Authentication
5+
and SSL encryption.
6+
57

68
=== HTTP Authentication
79

8-
If your Elasticsearch server is protected by HTTP Authentication, you need to provide the credentials to ES-PHP so
9-
that requests can be authenticated server-side. Authentication credentials are provided as part of the host array
10-
when instantiating the client:
10+
If your {es} server is protected by HTTP Authentication, you need to provide the
11+
credentials to ES-PHP so that requests can be authenticated server-side.
12+
Authentication credentials are provided as part of the host array when
13+
instantiating the client:
1114

1215
[source,php]
1316
----
@@ -21,12 +24,17 @@ $client = ClientBuilder::create()
2124
->build();
2225
----
2326

24-
Credentials are provided per-host, which allows each host to have their own set of credentials. All requests sent to the
25-
cluster will use the appropriate credentials depending on the node being talked to.
27+
Credentials are provided per-host, which allows each host to have their own set
28+
of credentials. All requests sent to the cluster use the appropriate credentials
29+
depending on the node being talked to.
30+
2631

2732
=== ApiKey Authentication
2833

29-
If your Elasticsearch cluster is secured by API keys as described https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-create-api-key.html[here], you can use these values to connect the client with your cluster, as illustrated in the following code snippet.
34+
If your {es} cluster is secured by API keys as described
35+
{ref}/security-api-create-api-key.html[here], you can use these values to
36+
connect the client with your cluster, as illustrated in the following code
37+
snippet.
3038

3139
[source,php]
3240
----
@@ -36,27 +44,33 @@ $client = ClientBuilder::create()
3644
----
3745
<1> ApiKey pair of `id` and `api_key` from the create API key response.
3846

47+
3948
=== SSL Encryption
4049

41-
Configuring SSL is a little more complex. You need to identify if your certificate has been signed by a public
42-
Certificate Authority (CA), or if it is a self-signed certificate.
50+
Configuring SSL is a little more complex. You need to identify if your
51+
certificate has been signed by a public Certificate Authority (CA), or if it is
52+
a self-signed certificate.
4353

4454
[NOTE]
4555
.A note on libcurl version
4656
=================
47-
If you believe the client is configured to correctly use SSL, but it simply is not working, check your libcurl
48-
version. On certain platforms, various features may or may not be available depending on version number of libcurl.
49-
For example, the `--cacert` option was not added to the OSX version of libcurl until version 7.37.1. The `--cacert`
50-
option is equivalent to PHP's `CURLOPT_CAINFO` constant, meaning that custom certificate paths will not work on lower
51-
versions.
52-
53-
If you are encountering problems, update your libcurl version and/or check the http://curl.haxx.se/changes.html[curl changelog].
57+
If you believe the client is configured to correctly use SSL, but it simply is
58+
not working, check your libcurl version. On certain platforms, various features
59+
may or may not be available depending on version number of libcurl. For example,
60+
the `--cacert` option was not added to the OSX version of libcurl until version
61+
7.37.1. The `--cacert` option is equivalent to PHP's `CURLOPT_CAINFO` constant,
62+
meaning that custom certificate paths will not work on lower versions.
63+
64+
If you are encountering problems, update your libcurl version and/or check the
65+
http://curl.haxx.se/changes.html[curl changelog].
5466
=================
5567

68+
5669
==== Public CA Certificates
5770

58-
If your certificate has been signed by a public Certificate Authority and your server has up-to-date root certificates,
59-
you only need to use `https` in the host path. The client will automatically verify SSL certificates:
71+
If your certificate has been signed by a public Certificate Authority and your
72+
server has up-to-date root certificates, you only need to use `https` in the
73+
host path. The client automatically verifies SSL certificates:
6074

6175
[source,php]
6276
----
@@ -71,10 +85,11 @@ $client = ClientBuilder::create()
7185
<1> Note that `https` is used, not `http`
7286

7387

74-
If your server has out-dated root certificates, you may need to use a certificate bundle. For PHP clients, the best
75-
way is to use https://github.com/composer/ca-bundle[composer/ca-bundle]. Once installed, you need to tell the client to
76-
use your certificates instead of the system-wide bundle. To do this, specify the path to verify:
77-
88+
If your server has out-dated root certificates, you may need to use a
89+
certificate bundle. For PHP clients, the best way is to use
90+
https://github.com/composer/ca-bundle[composer/ca-bundle]. Once installed, you
91+
need to tell the client to use your certificates instead of the system-wide
92+
bundle. To do this, specify the path to verify:
7893

7994
[source,php]
8095
----
@@ -87,15 +102,18 @@ $client = ClientBuilder::create()
87102
->build();
88103
----
89104

105+
90106
==== Self-signed Certificates
91107

92-
Self-signed certificates are certs that have not been signed by a public CA. They are signed by your own organization.
93-
Self-signed certificates are often used for internal purposes, when you can securely spread the root certificate
94-
yourself. It should not be used when being exposed to public consumers, since this leaves the client vulnerable to
95-
man-in-the-middle attacks.
108+
Self-signed certificates are certs that have not been signed by a public CA.
109+
They are signed by your own organization. Self-signed certificates are often
110+
used for internal purposes, when you can securely spread the root certificate
111+
yourself. It should not be used when being exposed to public consumers, since
112+
this leaves the client vulnerable to man-in-the-middle attacks.
96113

97-
If you are using a self-signed certificate, you need to provide the certificate to the client. This is the same syntax
98-
as specifying a new root bundle, but instead you point to your certificate:
114+
If you are using a self-signed certificate, you need to provide the certificate
115+
to the client. This is the same syntax as specifying a new root bundle, but
116+
instead you point to your certificate:
99117

100118
[source,php]
101119
----
@@ -111,9 +129,10 @@ $client = ClientBuilder::create()
111129

112130
=== Using Authentication with SSL
113131

114-
It is possible to use HTTP authentication with SSL. Simply specify `https` in the URI, configure SSL settings as
115-
required and provide authentication credentials. For example, this snippet will authenticate using Basic HTTP auth
116-
and a self-signed certificate:
132+
It is possible to use HTTP authentication with SSL. Simply specify `https` in
133+
the URI, configure SSL settings as required and provide authentication
134+
credentials. For example, this snippet authenticates using Basic HTTP auth and a
135+
self-signed certificate:
117136

118137
[source,php]
119138
----

0 commit comments

Comments
 (0)