From 72d2b860324e84b2be80735624d70f708866e049 Mon Sep 17 00:00:00 2001 From: marko-bekhta Date: Fri, 20 Sep 2024 16:47:40 +0200 Subject: [PATCH] Remove a duplicated line in the TLS registry guide --- .../main/asciidoc/tls-registry-reference.adoc | 33 +++++++++---------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/docs/src/main/asciidoc/tls-registry-reference.adoc b/docs/src/main/asciidoc/tls-registry-reference.adoc index 8774141b5c93e4..0eac097cd9f6dd 100644 --- a/docs/src/main/asciidoc/tls-registry-reference.adoc +++ b/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("")` 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