Remove a duplicated line in the TLS registry guide

Author: marko-bekhta

docs/src/main/asciidoc/tls-registry-reference.adoc

@@ -195,15 +195,15 @@ This setting is important when using SNI, because it uses the first specified pa
 PKCS12 keystores are single files that contain the certificate and the private key.
 
 To configure a PKCS12 keystore:
- 
+
 [source,properties]
 ----
 quarkus.tls.key-store.p12.path=server-keystore.p12
 quarkus.tls.key-store.p12.password=secret
 ----
- 
+
 `.p12` files are password-protected, so you need to provide the password to open the keystore.
- 
+
 These files can include more than one certificate and private key.
 If this is the case, take either of the following actions:
 
@@ -239,11 +239,11 @@ To configure a JKS keystore:
 quarkus.tls.key-store.jks.path=server-keystore.jks
 quarkus.tls.key-store.jks.password=secret
 ----
- 
+
 `.jks` files are password-protected, so you need to provide the password to open the keystore.
 Also, they can include more than one certificate and private key.
 If this is the case:
- 
+
 * Provide and configure the alias of the certificate and the private key you want to use:
 +
 [source,properties]
@@ -264,12 +264,12 @@ Server Name Indication (SNI) is a TLS extension that makes it possible for a cli
 SNI enables a server to present different TLS certificates for multiple domains on a single IP address, which facilitates secure communication for virtual hosting scenarios.
 
 To enable SNI:
- 
+
 [source,properties]
 ----
 quarkus.tls.key-store.sni=true # Disabled by default
 ----
- 
+
 With SNI enabled, the client indicates the server name during the TLS handshake, which allows the server to select the appropriate certificate:
 
 * When configuring the keystore with PEM files, multiple certificate (CRT) and key files must be provided.
@@ -337,7 +337,7 @@ quarkus.tls.trust-store.p12.path=client-truststore.p12
 quarkus.tls.trust-store.p12.password=password
 quarkus.tls.trust-store.p12.alias=my-alias
 ----
- 
+
 `.p12` files are password-protected, so you need to provide the password to open the truststore.
 However, unlike keystores, the alias does not require a password because it contains a public certificate, not a private key.
 
@@ -355,7 +355,7 @@ quarkus.tls.trust-store.jks.path=client-truststore.jks
 quarkus.tls.trust-store.jks.password=password
 quarkus.tls.trust-store.jks.alias=my-alias
 ----
- 
+
 `.jks` files are password-protected, so you need to provide the password to open the truststore.
 However, unlike keystores, the alias does not require a password because it contains a public certificate, not a private key.
 
@@ -379,7 +379,7 @@ quarkus.tls.trust-store.credentials-provider.bean-name=my-credentials-provider
 # The key used to retrieve the truststore password, `password` by default
 quarkus.tls.trust-store.credentials-provider.password-key=password
 ----
- 
+
 IMPORTANT: The credential provider can only be used with PKCS12 and JKS truststores.
 
 === Other properties
@@ -509,7 +509,7 @@ While extensions automatically use the TLS registry, you can also access the TLS
 
 To access the TLS configuration, inject the `TlsConfigurationRegistry` bean.
 You can retrieve a named TLS configuration by calling `get("<NAME>")` or the default configuration by calling `getDefault()`.
- 
+
 [source,java]
 ----
  @Inject
@@ -519,7 +519,7 @@ TlsConfiguration def = certificates.getDefault().orElseThrow();
 TlsConfiguration named = certificates.get("name").orElseThrow();
 //...
 ----
- 
+
 The `TlsConfiguration` object contains the keystores, truststores, cipher suites, protocols, and other properties.
 It also provides a way to create an `SSLContext` from the configuration.
 
@@ -538,9 +538,9 @@ To register a certificate in the TLS registry by using the extension, the _proce
 TlsCertificateBuildItem item = new TlsCertificateBuildItem("named",
     new MyCertificateSupplier());
 ----
- 
+
 The certificate supplier is a runtime object generally retrieved by using a recorder method.
- 
+
 .An example of a certificate supplier:
 [source,java]
 ----
@@ -768,7 +768,6 @@ The generated secret includes the following files:
 
 == Working with OpenShift serving certificates
 
-When running your application in OpenShift, you can use the link:https://docs.openshift.com/container-platform/4.16/security/certificates/service-serving-certificate.html[OpenShift serving certificates] to generate and renew TLS certificates automatically.
 When running your application in OpenShift, you can use the link:https://docs.openshift.com/container-platform/4.16/security/certificates/service-serving-certificate.html[OpenShift serving certificates] to generate and renew TLS certificates automatically.
 The Quarkus TLS registry can use these certificates and Certificate Authority (CA) files to handle HTTPS traffic and validate certificates securely.
 
@@ -876,7 +875,7 @@ Ensure that the path matches the one used in the configuration (here `/etc/tls`)
 . Deploy your application to use the certificate generated by OpenShift.
 This will make the service available over HTTPS.
 
-[NOTE] 
+[NOTE]
 ====
 By setting the `quarkus.tls.key-store.pem.acme.cert` and `quarkus.tls.key-store.pem.acme.key` variables or their environment variable variant, the TLS registry will use the certificate and private key from the secret.
 
@@ -1148,7 +1147,7 @@ Even if the Quarkus Development CA is installed, you can generate a self-signed
 ----
 quarkus tls generate-certificate --name my-cert --self-signed
 ----
- 
+
 This generates a self-signed certificate that the Quarkus Development CA does not sign.
 
 === Uninstalling the Quarkus Development CA