Clarify ECE doc about wildcard DNS certificate

[kunisen]

Description

This doc PR is to address this internal ticket. Change detail: this comment.

Preview before PR merge

• deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md
• deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md
• deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md
• deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md

Preview after PR merge

• https://www.elastic.co/docs/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns
• https://www.elastic.co/docs/deploy-manage/deploy/cloud-enterprise/change-endpoint-urls
• https://www.elastic.co/docs/deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases
• https://www.elastic.co/docs/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates

[kunisen]

Hi @eedugon @AlexP-Elastic @dtuck9 @maggieghamry

I requested your kind review from doc, dev and support perspective.
Please refer to this comment about the change details and thank you!

[github-actions]

🔍 Preview links for changed docs

• deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md
• deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md
• deploy-manage/deploy/cloud-enterprise/enable-custom-endpoint-aliases.md
• deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md

[eedugon]

Awesome improvements in my opinion.
Really worthy.

In some way I think we shouldn't even mention (or support) the possibility of certificates with static SAN entries, but I'm ok with this text.

[AlexP-Elastic]

Looks fine to me, had a few minor comments but nothing blocking

[AlexP-Elastic]

Do we really need 3 sections here to expand on the sentence above?

Who are you trying to convince - pretty sure everyone who is allowed to use a wildcard cert will do so :)

I think I'd probably just add

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.

and

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.

to the section above

I don't feel super strongly about this though

[kunisen]

Thank you @AlexP-Elastic!

The request comes from past cases from customers and the discussion with @eedugon that we felt it doesn't harm to make it super clear that "why in specific do we highly recommend wildcard DNS certs". We had multiple customers / users asking details about security risk, operational cost related questions, and Edu shared the insights about the performance considerations too, which eventually and logically it split into 3 sections.

I will leave this to @eedugon and @maggieghamry to make the decision :) If they could help confirm that the simplified content is easily and visibly understandable enough for customers, then I am perfectly fine with we remove the headings and describe the context in one paragraph.

@eedugon @maggieghamry please help provide your kind insights on this 🙏 and thanks again!

[eedugon]

@kunisen , I think there's a middle point, as in some way we don't need to highlight all this that much with a big H2 section and 3 x H3.

On Monday I will quickly prepare a proposal through a suggestion so you can take a look and evaluate. The suggestion will:

• Change the name of Wildcard DNS certificate vs static SAN certificate H2 section and convert it to H3.
• Convert the final 3 sections Operational cost perspective, Performance perspective, and Security perspective to bullets with a bit shorter explanations on each, but keeping the esence.

I agree the 3 big sub-sections at the end don't add value and it makes the doc scope to not be totally clear.