From 320db041afb3c57af9d95ffd5f83167c201b0cb4 Mon Sep 17 00:00:00 2001 From: Kuni Sen Date: Fri, 17 Oct 2025 15:16:17 +0900 Subject: [PATCH 01/15] Clarify ECE doc about wildcard DNS certificate --- .../cloud-enterprise/change-endpoint-urls.md | 6 ++- .../cloud-enterprise/ece-wildcard-dns.md | 43 +++++++++++++++++-- .../enable-custom-endpoint-aliases.md | 12 +++--- .../manage-security-certificates.md | 15 +++---- 4 files changed, 58 insertions(+), 18 deletions(-) diff --git a/deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md b/deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md index c6009339aa..c046ae39d4 100644 --- a/deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md +++ b/deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md @@ -20,7 +20,7 @@ https://.ip.es.io:9243 ``` ::::{important} -If your application does not support HTTPS, you can connect to the HTTP endpoint on port 9200. However, for security reasons, it is recommended to use **HTTPS (9243)** whenever possible. +For security reasons, it is recommended to use **HTTPS (9243)** whenever possible. :::: To change endpoints in the Cloud UI: @@ -43,3 +43,7 @@ If you have an App Search instance, after specifying a new deployment domain nam ::::{note} The built-in Proxy Certificate only validates against the default endpoint format described on this page. Once you change it, it is necessary to upload a new Proxy Certificate as described in [Manage security certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). For test only, clients can be configured with hostname verification disabled until the new certificate is uploaded. :::: + +::::{note} +If you do not use wildcard certificates, you must configure SAN entries for each component of the deployment (for example, {{es}} or {{kib}}) and repeat this process for every deployment. Review [Wildcard DNS record and certificates](./ece-wildcard-dns.md) for more guidance. +:::: \ No newline at end of file diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 99469c2c67..74efdc3134 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -8,7 +8,7 @@ products: - id: cloud-enterprise --- -# Wildcard DNS record [ece-wildcard-dns] +# Wildcard DNS record and certificates [ece-wildcard-dns] ::::{warning} Don't use `ip.es.io` for production systems. Set up your own domain name and DNS resolver for production. We do not guarantee uptime with `ip.es.io`. @@ -16,11 +16,48 @@ Don't use `ip.es.io` for production systems. Set up your own domain name and DNS `ip.es.io` is intended for use only by {{ece}} customers. We may, acting in our sole discretion, immediately terminate, suspend, or block any unauthorized users or uses without notice. :::: -By default, {{ece}} uses the external `ip.es.io` service provided by Elastic to resolve virtual {{es}} cluster host names in compliance with RFC1918. The service works by resolving host names of the form `.ip.es.io` to ``. In the case of {{ece}}, each cluster is assigned a virtual host name of the form `..ip.es.io:`, such as `6dfc65aae62341e18a8b7692dcc97186.10.8.156.132.ip.es.io:9243`. The `ip.es.io` service simply resolves the virtual host name of the cluster to the proxy address which is specified during installation, `10.8.156.132` in our example, so that client requests are sent to the proxy. The proxy then extracts the cluster ID from the virtual host name of the cluster and uses its internal routing table to route the request to the right allocator. +By default, {{ece}} uses the external `ip.es.io` service provided by Elastic to resolve virtual {{es}} cluster host names in compliance with RFC1918. The service works by resolving host names of the form `.ip.es.io` to ``. In the case of {{ece}}, each cluster is assigned a virtual host name of the form `..ip.es.io:`, such as `6dfc65aae62341e18a8b7692dcc97186.10.8.156.132.ip.es.io:9243`. + +The `ip.es.io` service simply resolves the virtual host name of the cluster to the proxy address which is specified during installation, `10.8.156.132` in our example, so that client requests are sent to the proxy. The proxy then extracts the cluster ID from the virtual host name of the cluster and uses its internal routing table to route the request to the right allocator. + +## Considerations for production The `ip.es.io` service is provided to help you evaluate {{ece}} without having to set up DNS records for your environment. You must set up a wildcard DNS record for your production system. You typically set up a wildcard DNS record that resolves to the proxy host or to a load balancer if you set up multiple proxies fronted by a load balancer. You can create both a wildcard DNS entry for your endpoints and a wildcard TLS/SSL certificate, so that you can create multiple clusters without the need for further DNS or TSL/SSL modifications. Simply configure your DNS to point to your load balancers and install your certificates on them, so that communication with the cluster is secure. -A wildcard certificate is enabled based on the deployment domain name. For more information on modifying the deployment domain name, check [Configure endpoints](change-endpoint-urls.md). The deployment domain name also determines the endpoint URLs that are displayed in the Cloud UI. +## Configuring wildcard DNS certificates + +{{ece}} highly recommends using a wildcard DNS certificate, typically configured as a subdomain (for example, `*.ece.mycompany.com`), to automatically secure the unique endpoints generated for each deployment (for example, `[deployment-id].ece.mycompany.com`). For details on modifying the deployment domain name, see [Change endpoint URLs](change-endpoint-urls.md). The deployment domain name also determines the endpoint URLs displayed in the Cloud UI. + +Alternatively, if you use custom endpoint aliases, you can configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. See [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. + + +## Wildcard DNS certificate vs static SAN certificate + +In {{ece}}, where you create new cluster deployments dynamically, a wildcard DNS certificate is more performant, scalable, and operationally safe than a static SAN certificate. + +### Operational cost perspective + +A central ECE proxy manages all traffic for dynamically created endpoints and performs TLS termination for incoming requests. Since all deployment hostnames cannot be predicted in advance, a wildcard certificate (`*.ece.mycompany.com`) provides optimal flexibility, allowing the proxy to present a valid certificate for any deployment URL accessed by a user. + +By contrast, a static SAN certificate requires reissuing the certificate whenever a new deployment is created and updating the SAN list for all clusters and applications (Elasticsearch, Kibana, etc.), which increases operational overhead. + +### Security perspective + +We suggest configuring your wildcard DNS certificate as a subdomain (e.g., `*.ece.mycompany.com`). Doing so significantly reduces security risks associated with certificate misconfigurations. + +By contrast, if a static SAN certificate does not include a new deployment’s hostname, clients will encounter a certificate name mismatch warning, indicating a security misconfiguration. + + +### Performance perspective + +Wildcard certificates are generally more performant than large static SAN certificates. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. + +By contrast, large SAN certificates can increase handshake latency and may affect client compatibility. + + +## Security Contact Report security issues to security@elastic.co. + + diff --git a/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md b/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md index c6c633a7c6..e0eceffb98 100644 --- a/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md +++ b/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md @@ -23,9 +23,9 @@ After installing or upgrading to version 2.10 or later: 2. [Update your proxy certificate(s)](../../security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). In addition to currently configured domains, additional SAN entries must be configured for each application-specific subdomain: ::::{note} - If you are not using wildcard certificates, you need to repeat this process for each deployment to account for specific aliases. + If you are not using wildcard certificates, you need to repeat this process for each deployment to account for specific aliases. Review [Wildcard DNS record and certificates](./ece-wildcard-dns.md) for more guidance. :::: - + * For {{es}}, the certificate needs to allow for **\*.es.** * For {{kib}}, the certificate needs to allow for **\*.kb.** @@ -33,11 +33,11 @@ After installing or upgrading to version 2.10 or later: * For Fleet, the certificate needs to allow for **\*.fleet.** * For Universal Profiling, the certificate needs to allow for **\*.profiling.** and **\*.symbols.** + ::::{note} + If you plan to deploy [Integration Servers](../../deploy/cloud-enterprise/manage-integrations-server.md), you must add two additional wildcard subdomains, `*.fleet.` and `*.apm.`, to the Subject Alternative Names (SANs) attached to the proxy wildcard certificate. + :::: + 3. In the **Platform** menu, select **Settings**. 4. Under the **Enable custom endpoint alias naming**, toggle the setting to allow platform administrators and deployment managers to choose a simplified, unique URL for the endpoint. -If you do not perform these steps, application endpoints will behave as they did in versions before 2.10. - -To learn about setting up custom endpoint aliases for your deployments, check [Custom endpoint aliases](ece-regional-deployment-aliases.md). - diff --git a/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md b/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md index 9c0a635353..13ebed9924 100644 --- a/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md +++ b/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md @@ -16,22 +16,21 @@ In these instructions, we show you how you can download the security certificate You can change the certificates for the following ECE components separately: -Cloud UI certificate +**Cloud UI certificate** : Used to connect securely to the Cloud UI and to make RESTful API calls. -Proxy certificate -: Used to connect securely to {{es}} clusters and {{kib}}. You should use a wildcard certificate rooted at the [cluster endpoint that you set](../../deploy/cloud-enterprise/change-endpoint-urls.md) (`*.example.com`, for example). A wildcard certificate is required, because the first label of the DNS address is distinct for {{es}} clusters and {{kib}} (`bc898abb421843918ebc31a513169a.example.com`, for example). +**Proxy certificate** +: Used to connect securely to {{es}} clusters and other components such as {{kib}}, etc. - If you wish to enable [custom endpoint aliases](../../deploy/cloud-enterprise/enable-custom-endpoint-aliases.md) in ECE 2.10 or later, also follow the directions for adding Subject Alternative Name (SAN) entries to support these aliases. + {{ece}} highly recommend to use a wildcard certificate typically configured as a subdomain, at the [cluster endpoint that you set](../../deploy/cloud-enterprise/change-endpoint-urls.md) (`*.ece.mycompany.com`, for example). - ::::{note} - If you plan to deploy [Integration Servers](../../deploy/cloud-enterprise/manage-integrations-server.md), you must add two additional wildcard subdomains, `*.fleet.` and `*.apm.`, to the Subject Alternative Names (SANs) attached to the proxy wildcard certificate. Based on the previous example, your proxy certificates should end up with those three wildcards: `*.example.com`, `*.fleet.example.com`, and `*.apm.example.com`. - :::: + If you wish to enable [custom endpoint aliases](../../deploy/cloud-enterprise/enable-custom-endpoint-aliases.md) in ECE 2.10 or later, also follow the directions for adding Subject Alternative Name (SAN) entries to support these aliases. + A wildcard DNS certificate is more performant, scalable, and operationally safe than a static SAN certificate. Review [Wildcard DNS record and certificates](./ece-wildcard-dns.md) for more guidance. After the certificates have been installed, connecting securely to {{es}}, {{kib}}, and the Cloud UI or making secure RESTful API calls to ECE should not result in any security warnings or errors. -Adminconsole certificate +**Adminconsole certificate** : This certificate facilitates a secure connection to an alternative API port, which can be used in rare scenarios where the UI is unavailable. We recommend using the same certificate as the one configured for the Cloud UI. From d258affc2c17bff4a9de3b987c479cc8abf55f9e Mon Sep 17 00:00:00 2001 From: Kuni Sen Date: Fri, 17 Oct 2025 15:33:30 +0900 Subject: [PATCH 02/15] Update manage-security-certificates.md --- .../manage-security-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md b/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md index 13ebed9924..ca12a2ad69 100644 --- a/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md +++ b/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md @@ -26,7 +26,7 @@ You can change the certificates for the following ECE components separately: If you wish to enable [custom endpoint aliases](../../deploy/cloud-enterprise/enable-custom-endpoint-aliases.md) in ECE 2.10 or later, also follow the directions for adding Subject Alternative Name (SAN) entries to support these aliases. - A wildcard DNS certificate is more performant, scalable, and operationally safe than a static SAN certificate. Review [Wildcard DNS record and certificates](./ece-wildcard-dns.md) for more guidance. + A wildcard DNS certificate is more performant, scalable, and operationally safe than a static SAN certificate. Review [Wildcard DNS record and certificates](../../deploy/cloud-enterprise/ece-wildcard-dns.md) for more guidance. After the certificates have been installed, connecting securely to {{es}}, {{kib}}, and the Cloud UI or making secure RESTful API calls to ECE should not result in any security warnings or errors. From 86ce87f0ee2d120362af055412a40680fe6283ab Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 18:58:47 +0900 Subject: [PATCH 03/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 74efdc3134..e080d97a54 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -28,7 +28,7 @@ The `ip.es.io` service is provided to help you evaluate {{ece}} without having t {{ece}} highly recommends using a wildcard DNS certificate, typically configured as a subdomain (for example, `*.ece.mycompany.com`), to automatically secure the unique endpoints generated for each deployment (for example, `[deployment-id].ece.mycompany.com`). For details on modifying the deployment domain name, see [Change endpoint URLs](change-endpoint-urls.md). The deployment domain name also determines the endpoint URLs displayed in the Cloud UI. -Alternatively, if you use custom endpoint aliases, you can configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. See [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. +Additionally, if you use custom endpoint aliases, you can configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. Refer to [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. ## Wildcard DNS certificate vs static SAN certificate From ab03eeb681f08e6ce544c31619115896dafbdbc0 Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 18:59:12 +0900 Subject: [PATCH 04/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index e080d97a54..62f46d5b9b 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -26,7 +26,7 @@ The `ip.es.io` service is provided to help you evaluate {{ece}} without having t ## Configuring wildcard DNS certificates -{{ece}} highly recommends using a wildcard DNS certificate, typically configured as a subdomain (for example, `*.ece.mycompany.com`), to automatically secure the unique endpoints generated for each deployment (for example, `[deployment-id].ece.mycompany.com`). For details on modifying the deployment domain name, see [Change endpoint URLs](change-endpoint-urls.md). The deployment domain name also determines the endpoint URLs displayed in the Cloud UI. +{{ece}} highly recommends using a wildcard DNS certificate, typically configured as a subdomain (for example, `*.ece.mycompany.com`), to automatically secure the unique endpoints generated for each deployment (for example, `[cluster-id].ece.mycompany.com`). For details on modifying the deployment domain name, see [Change endpoint URLs](change-endpoint-urls.md). The deployment domain name also determines the endpoint URLs displayed in the Cloud UI. Additionally, if you use custom endpoint aliases, you can configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. Refer to [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. From 9f1ccb8e393f125a5d4ec7f4988c6b43e993abfa Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 18:59:33 +0900 Subject: [PATCH 05/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 62f46d5b9b..b98e1e67ac 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -50,7 +50,7 @@ By contrast, if a static SAN certificate does not include a new deployment’s h ### Performance perspective -Wildcard certificates are generally more performant than large static SAN certificates. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. +Wildcard certificates are generally more performant than certificates with a large number of SAN entries. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. By contrast, large SAN certificates can increase handshake latency and may affect client compatibility. From a386a62dc40357239cb81aa01c0ff4d48d2a01df Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 18:59:44 +0900 Subject: [PATCH 06/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index b98e1e67ac..0755428273 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -52,7 +52,7 @@ By contrast, if a static SAN certificate does not include a new deployment’s h Wildcard certificates are generally more performant than certificates with a large number of SAN entries. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. -By contrast, large SAN certificates can increase handshake latency and may affect client compatibility. +By contrast, certificates with a large number of SAN entries can increase handshake latency and may affect client compatibility. ## Security Contact From 288bc8e4a18de9a3144a6ed5c93dd7c660747b1f Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 19:01:18 +0900 Subject: [PATCH 07/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 0755428273..2ef5af92a7 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -33,7 +33,9 @@ Additionally, if you use custom endpoint aliases, you can configure a wildcard D ## Wildcard DNS certificate vs static SAN certificate -In {{ece}}, where you create new cluster deployments dynamically, a wildcard DNS certificate is more performant, scalable, and operationally safe than a static SAN certificate. +In {{ece}}, each deployment generates multiple DNS entries, as every component within a deployment has its own cluster ID and fully qualified domain name (FQDN). In environments with many deployments, especially when deployment aliases are used, this can result in hundreds of unique FQDNs that need to be covered by the certificate. + +For this reason, using a wildcard DNS certificate is recommended over a certificate with static SAN entries, as it provides a more scalable, performant, and operationally safe solution. ### Operational cost perspective From 0ccb9eb56a5bf0279b6c75d5493456c7925caad0 Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 19:01:58 +0900 Subject: [PATCH 08/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 2ef5af92a7..214ea7ba00 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -47,7 +47,7 @@ By contrast, a static SAN certificate requires reissuing the certificate wheneve We suggest configuring your wildcard DNS certificate as a subdomain (e.g., `*.ece.mycompany.com`). Doing so significantly reduces security risks associated with certificate misconfigurations. -By contrast, if a static SAN certificate does not include a new deployment’s hostname, clients will encounter a certificate name mismatch warning, indicating a security misconfiguration. +By contrast, if a certificate with static SAN entries does not include the new deployment’s cluster IDs (each component has its own FQDN), clients will encounter certificate name mismatch warnings, indicating a security misconfiguration. ### Performance perspective From c778e1749c258c3e4f1ba66026004c83ccf0b262 Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 19:02:38 +0900 Subject: [PATCH 09/15] Update deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- .../manage-security-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md b/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md index ca12a2ad69..3be6ca2a0f 100644 --- a/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md +++ b/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md @@ -22,7 +22,7 @@ You can change the certificates for the following ECE components separately: **Proxy certificate** : Used to connect securely to {{es}} clusters and other components such as {{kib}}, etc. - {{ece}} highly recommend to use a wildcard certificate typically configured as a subdomain, at the [cluster endpoint that you set](../../deploy/cloud-enterprise/change-endpoint-urls.md) (`*.ece.mycompany.com`, for example). + We strongly recommend using a wildcard certificate configured for a subdomain at the [cluster endpoint you set](../../deploy/cloud-enterprise/change-endpoint-urls.md) (for example, `*.ece.mycompany.com`). If you wish to enable [custom endpoint aliases](../../deploy/cloud-enterprise/enable-custom-endpoint-aliases.md) in ECE 2.10 or later, also follow the directions for adding Subject Alternative Name (SAN) entries to support these aliases. From ed311dff15a3a84cc826ab3210d2d88e3f35c1ea Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Fri, 17 Oct 2025 19:03:34 +0900 Subject: [PATCH 10/15] Update deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- .../deploy/cloud-enterprise/enable-custom-endpoint-aliases.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md b/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md index e0eceffb98..ba6e893e5c 100644 --- a/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md +++ b/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md @@ -33,9 +33,6 @@ After installing or upgrading to version 2.10 or later: * For Fleet, the certificate needs to allow for **\*.fleet.** * For Universal Profiling, the certificate needs to allow for **\*.profiling.** and **\*.symbols.** - ::::{note} - If you plan to deploy [Integration Servers](../../deploy/cloud-enterprise/manage-integrations-server.md), you must add two additional wildcard subdomains, `*.fleet.` and `*.apm.`, to the Subject Alternative Names (SANs) attached to the proxy wildcard certificate. - :::: 3. In the **Platform** menu, select **Settings**. 4. Under the **Enable custom endpoint alias naming**, toggle the setting to allow platform administrators and deployment managers to choose a simplified, unique URL for the endpoint. From 12c2e198dbe9f526db6c31aee0a921e8c5f01544 Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Sat, 18 Oct 2025 17:15:50 +0900 Subject: [PATCH 11/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 214ea7ba00..5e81e514e4 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -28,7 +28,7 @@ The `ip.es.io` service is provided to help you evaluate {{ece}} without having t {{ece}} highly recommends using a wildcard DNS certificate, typically configured as a subdomain (for example, `*.ece.mycompany.com`), to automatically secure the unique endpoints generated for each deployment (for example, `[cluster-id].ece.mycompany.com`). For details on modifying the deployment domain name, see [Change endpoint URLs](change-endpoint-urls.md). The deployment domain name also determines the endpoint URLs displayed in the Cloud UI. -Additionally, if you use custom endpoint aliases, you can configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. Refer to [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. +Additionally, if you use custom endpoint aliases, you must configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. Refer to [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. ## Wildcard DNS certificate vs static SAN certificate From ceb0e7c59ca70ae8e448790a2bbc4d033733c459 Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Sat, 18 Oct 2025 17:18:41 +0900 Subject: [PATCH 12/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 5e81e514e4..6912afc6e3 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -33,7 +33,7 @@ Additionally, if you use custom endpoint aliases, you must configure a wildcard ## Wildcard DNS certificate vs static SAN certificate -In {{ece}}, each deployment generates multiple DNS entries, as every component within a deployment has its own cluster ID and fully qualified domain name (FQDN). In environments with many deployments, especially when deployment aliases are used, this can result in hundreds of unique FQDNs that need to be covered by the certificate. +In {{ece}}, each deployment generates multiple DNS entries, as every component within a deployment has its own cluster ID and fully qualified domain name (FQDN) and can have a second DNS entry using [its alias](./enable-custom-endpoint-aliases.md). In environments with many deployments, especially when deployment aliases are used, this can result in hundreds of unique FQDNs that need to be covered by the certificate. For this reason, using a wildcard DNS certificate is recommended over a certificate with static SAN entries, as it provides a more scalable, performant, and operationally safe solution. From ea8dcf04395fcdf9b24ef0cb0537fd9b07befbf8 Mon Sep 17 00:00:00 2001 From: Kuni Sen Date: Sat, 18 Oct 2025 17:20:46 +0900 Subject: [PATCH 13/15] Update ece-wildcard-dns.md --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 6912afc6e3..88ef42483b 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -40,20 +40,17 @@ For this reason, using a wildcard DNS certificate is recommended over a certific ### Operational cost perspective A central ECE proxy manages all traffic for dynamically created endpoints and performs TLS termination for incoming requests. Since all deployment hostnames cannot be predicted in advance, a wildcard certificate (`*.ece.mycompany.com`) provides optimal flexibility, allowing the proxy to present a valid certificate for any deployment URL accessed by a user. - By contrast, a static SAN certificate requires reissuing the certificate whenever a new deployment is created and updating the SAN list for all clusters and applications (Elasticsearch, Kibana, etc.), which increases operational overhead. ### Security perspective We suggest configuring your wildcard DNS certificate as a subdomain (e.g., `*.ece.mycompany.com`). Doing so significantly reduces security risks associated with certificate misconfigurations. - By contrast, if a certificate with static SAN entries does not include the new deployment’s cluster IDs (each component has its own FQDN), clients will encounter certificate name mismatch warnings, indicating a security misconfiguration. ### Performance perspective Wildcard certificates are generally more performant than certificates with a large number of SAN entries. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. - By contrast, certificates with a large number of SAN entries can increase handshake latency and may affect client compatibility. From f9d22882874f97bdee81d7f3aca9a7127212b43a Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Tue, 28 Oct 2025 17:19:25 +0900 Subject: [PATCH 14/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- .../cloud-enterprise/ece-wildcard-dns.md | 22 +++++-------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 88ef42483b..4d5916deb8 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -31,27 +31,17 @@ The `ip.es.io` service is provided to help you evaluate {{ece}} without having t Additionally, if you use custom endpoint aliases, you must configure a wildcard DNS certificate for each application-specific subdomain, such as `*.es.mycompany.com` for {{es}} or `*.kb.mycompany.com` for {{kib}}. Refer to [Enable custom endpoint aliases](./enable-custom-endpoint-aliases.md) for more information. Platform administrators must enable this feature to allow deployment managers to create and modify aliases for their deployments. -## Wildcard DNS certificate vs static SAN certificate +### Wildcard DNS certificate vs static SAN certificates -In {{ece}}, each deployment generates multiple DNS entries, as every component within a deployment has its own cluster ID and fully qualified domain name (FQDN) and can have a second DNS entry using [its alias](./enable-custom-endpoint-aliases.md). In environments with many deployments, especially when deployment aliases are used, this can result in hundreds of unique FQDNs that need to be covered by the certificate. +In {{ece}}, each deployment generates multiple DNS entries, as every component within a deployment has its own cluster ID and fully qualified domain name (FQDN), and may also have an [alias](./enable-custom-endpoint-aliases.md). In environments with many deployments, especially when aliases are used, this can result in hundreds of unique FQDNs that must be covered by the certificate. -For this reason, using a wildcard DNS certificate is recommended over a certificate with static SAN entries, as it provides a more scalable, performant, and operationally safe solution. +For this reason, using a wildcard DNS certificate for a subdomain, such as `*.ece.mycompany.com`, is recommended over a certificate with static SAN entries, as it offers a more scalable, efficient, and operationally safe solution: -### Operational cost perspective +* **Operational cost:** Because deployment FQDNs cannot be predicted in advance, a wildcard certificate provides optimal flexibility, allowing the proxy to present a valid certificate for any deployment URL. In contrast, a certificate with static SAN entries must be reissued whenever a new deployment is created, which increases the operational overhead. -A central ECE proxy manages all traffic for dynamically created endpoints and performs TLS termination for incoming requests. Since all deployment hostnames cannot be predicted in advance, a wildcard certificate (`*.ece.mycompany.com`) provides optimal flexibility, allowing the proxy to present a valid certificate for any deployment URL accessed by a user. -By contrast, a static SAN certificate requires reissuing the certificate whenever a new deployment is created and updating the SAN list for all clusters and applications (Elasticsearch, Kibana, etc.), which increases operational overhead. +* **Security:** We suggest configuring your wildcard DNS certificate for a subdomain, such as `*.ece.mycompany.com`. Doing so significantly reduces security risks associated with certificate misconfigurations. In contrast, if a certificate with static SAN entries does not include the new deployment’s cluster IDs, clients will encounter certificate name mismatch warnings, indicating a security misconfiguration. -### Security perspective - -We suggest configuring your wildcard DNS certificate as a subdomain (e.g., `*.ece.mycompany.com`). Doing so significantly reduces security risks associated with certificate misconfigurations. -By contrast, if a certificate with static SAN entries does not include the new deployment’s cluster IDs (each component has its own FQDN), clients will encounter certificate name mismatch warnings, indicating a security misconfiguration. - - -### Performance perspective - -Wildcard certificates are generally more performant than certificates with a large number of SAN entries. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. -By contrast, certificates with a large number of SAN entries can increase handshake latency and may affect client compatibility. +* **Performance:** Wildcard certificates are generally more performant than certificates with a large number of SAN entries. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. In contrast, certificates with a large number of SAN entries can increase handshake latency and may affect client compatibility. ## Security Contact From 84c0c49efa2a8aa2679bffb122ba266fa08eaf84 Mon Sep 17 00:00:00 2001 From: Kuni Sen <30574753+kunisen@users.noreply.github.com> Date: Tue, 28 Oct 2025 17:20:26 +0900 Subject: [PATCH 15/15] Update deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com> --- deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md index 4d5916deb8..014f4b974f 100644 --- a/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md +++ b/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md @@ -44,9 +44,3 @@ For this reason, using a wildcard DNS certificate for a subdomain, such as `*.ec * **Performance:** Wildcard certificates are generally more performant than certificates with a large number of SAN entries. They are smaller, which reduces TLS handshake time, and scale automatically with new deployments. In contrast, certificates with a large number of SAN entries can increase handshake latency and may affect client compatibility. -## Security Contact - -Report security issues to security@elastic.co. - - -