Update Working with certificates docs

Author: russcam

src/Tests/Tests/ClientConcepts/Certificates/WorkingWithCertificates.doc.cs

@@ -17,27 +17,25 @@ namespace Tests.ClientConcepts.Certificates
 {
 	/**=== Working with certificates
 	 *
-	 * If you've enabled SSL on Elasticsearch with https://www.elastic.co/products/x-pack[X-Pack] or through a
+	 * If you've enabled SSL on Elasticsearch with https://www.elastic.co/products/elastic-stack[Elastic Stack Security features], or through a
 	 * proxy in front of Elasticsearch, and the Certificate Authority (CA)
-	 * that generated the certificate is trusted by the machine running the client code, there should be nothing you'll have to do to talk
+	 * that generated the certificate is trusted by the machine running the client code, there should be nothing for you to do to talk
 	 * to the cluster over HTTPS with the client.
 	 *
-	 * If you are using your own CA which is not trusted however, .NET won't allow you to make HTTPS calls to that endpoint by default. With .NET,
-	 * you can pre-empt this though a custom validation callback on the global static
+	 * If you are using your own CA which is not trusted however, .NET won't allow you to make HTTPS calls to that endpoint by default.
+	 * With .NET Framework, you can pre-empt this though a custom validation callback on the global static
 	 * `ServicePointManager.ServerCertificateValidationCallback`. Most examples you will find doing this this will simply return `true` from the
 	 * validation callback and merrily whistle off into the sunset. **This is not advisable** as it allows *any* HTTPS traffic through in the
 	 * current `AppDomain` *without* any validation. Here's a concrete example:
 	 *
 	 */
 	public class WorkingWithCertificates
 	{
-		/** Imagine you deploy a web application that talks to Elasticsearch over HTTPS through NEST, and also uses some third party SOAP/WSDL endpoint;
-		* by setting
+		/** Imagine you deploy a web application that talks to Elasticsearch over HTTPS using NEST, and also uses some third party SOAP/WSDL endpoint.
+		* By setting the following
 		*/
-#if !DOTNETCORE
 		public void ServerValidationCallback() => ServicePointManager.ServerCertificateValidationCallback +=
 			(sender, cert, chain, errors) => true;
-#endif
 		/**
 		 * validation will not be performed for HTTPS connections to *both* Elasticsearch *and* that external web service.
 		 *
@@ -60,7 +58,7 @@ public class DenyAllCertificatesCluster : SslAndKpiXPackCluster
 		{
 			protected override ConnectionSettings ConnectionSettings(ConnectionSettings s) => s
 				.ServerCertificateValidationCallback((o, certificate, chain, errors) => false)
-				.ServerCertificateValidationCallback(CertificateValidations.DenyAll); // <1> synonymous with the previous lambda expression
+				.ServerCertificateValidationCallback(CertificateValidations.DenyAll); // <1> use a lambda expression or `CertificateValidations.DenyAll` to deny all validation
 		}
 
 		//hide
@@ -87,8 +85,8 @@ protected override void AssertHttpRequestException(HttpRequestException e)
 		public class AllowAllCertificatesCluster : SslAndKpiXPackCluster
 		{
 			protected override ConnectionSettings ConnectionSettings(ConnectionSettings s) => s
-				.ServerCertificateValidationCallback((o, certificate, chain, errors) => true)
-				.ServerCertificateValidationCallback(CertificateValidations.AllowAll); // <1> synonymous with the previous lambda expression
+				.ServerCertificateValidationCallback((o, certificate, chain, errors) => true) // <1>
+				.ServerCertificateValidationCallback(CertificateValidations.AllowAll); // <1> use a lambda expression or `CertificateValidations.AllowAll` to allow all validation
 		}
 		/**
 		 * This is not recommended in production.
@@ -111,7 +109,7 @@ public AllowAllSslCertificatesApiTests(AllowAllCertificatesCluster cluster, Endp
 		 * If your client application has access to the public CA certificate locally, Elasticsearch.NET and NEST ship with some handy helpers
 		 * that can assert that a certificate the server presents is one that came from the local CA.
 		 *
-		 * If you use X-Pack's {ref_current}/certutil.html[+elasticsearch-certutil+ tool] to generate SSL certificates, the generated node certificate
+		 * If you use {ref_current}/certutil.html[+elasticsearch-certutil+ tool] to generate SSL certificates, the generated node certificate
 		 * does not include the CA in the certificate chain, in order to cut down on SSL handshake size. In those case you can use
 		 * `CertificateValidations.AuthorityIsRoot` and pass it your local copy of the CA public key to assert that
 		 * the certificate the server presented was generated using it
@@ -179,14 +177,13 @@ protected override void AssertHttpRequestException(HttpRequestException e)
 		/**
 		 * ==== Client Certificates
 		 *
-		 * X-Pack also allows you to configure a {ref_current}/configuring-pki-realm.html[PKI realm] to enable user authentication
-		 * through client certificates. The {ref_current}/certutil.html[+elasticsearch-certutil+ tool] included with X-Pack allows you to
-		 * generate client certificates as well and assign the distinguished name (DN) of the
-		 * certificate to a user with a certain role.
+		 * Elastic Stack Security features allow you to configure a {ref_current}/configuring-pki-realm.html[PKI realm] to enable user authentication
+		 * through client certificates. The {ref_current}/certutil.html[+elasticsearch-certutil+ tool] included with the default distribution
+		 * allows you to generate client certificates as well and assign the distinguished name (DN) of the certificate to a user with a certain role.
 		 *
-		 * By default, the `elasticsearch-certutil` tool only generates a public certificate (`.cer`) and a private key `.key`. To authenticate with client certificates, you need to present both
-		 * as one certificate. The easiest way to do this is to generate a `pfx` or `p12` file from the `.cer` and `.key`
-		 * and attach these to requests using `new X509Certificate(pathToPfx)`.
+		 * By default, the `elasticsearch-certutil` tool only generates a public certificate (`.cer`) and a private key `.key`.
+		 * To authenticate with client certificates, you need to present both as one certificate. The easiest way to do this is to generate a `pfx`
+		 * or `p12` file from the `.cer` and `.key` and attach these to requests using `new X509Certificate(pathToPfx)`.
 		 *
 		 * You can pass a client certificate on `ConnectionSettings` for *all* requests.
 		 *