Remove bad cross reference link

Author: russcam

docs/client-concepts/certificates/working-with-certificates.asciidoc

@@ -17,7 +17,7 @@ please modify the original csharp file found at the link and submit the PR with
 [[working-with-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/shield[Shield] 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
 to the cluster over HTTPS with the client.
@@ -84,8 +84,7 @@ public class AllowAllCertificatesCluster : ClusterBase
 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 `certgen` tool to {xpack_current}/ssl-tls.html[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
+Some certificates do 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
 
 [source,csharp]

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

@@ -15,7 +15,7 @@ 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/shield[Shield] 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
 	 * to the cluster over HTTPS with the client.
@@ -80,8 +80,7 @@ public override ConnectionSettings ClusterConnectionSettings(ConnectionSettings
 		 * 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 `certgen` tool to {xpack_current}/ssl-tls.html[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
+		 * Some certificates do 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
 		 */