There are two types of certificates involved here. One is a certificate signing certificate, or CA (certificate authority) cert. This is used by the CA to add a cryptographically secure signature to a cert. That signature proves that the certificate was issued by the CA. The elastic-stack-ca.p12 is such a CA cert.
There are companies whose entire business model is to get paid to sign their customer's certificates with their CA certs. Responsible CAs will not let customers request certificates for arbitrary names. If I ask Verisign to issue me a certificate for www.ibm.com they will refuse, since I cannot show that I have a legitimate use for it.
Provided the CA is responsible, browser developers will add the CA cert to the list of CA certs that it trusts. So the customer pays the CA to sign their cert, and in return, browsers trust the customer web site. Everybody wins.
As I said, CAs charge money to sign certificates, so if you have a site/node that will never be accessed outside of a closed system (and elasticsearch nodes tend to be in closed systems) then you will not want to pay them to do that, since it adds no value. Instead you generate your own CA cert.
The other type of certificate mentioned in that documentation is a node certificate, used with TLS to authenticate a website (via the browser trusting it) and encrypt traffic to that site. Each certificate is specific to one website, so you need as many certificates as you have websites (or elasticsearch nodes).
There is a third type of certificate, a client certificate used to authenticate a user to a website instead of a username and password. There is one of these for each user. It is up to you whether you configure your sites/nodes to use these.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.