From 5a13aeda3451b873b835addab2c23af616129db0 Mon Sep 17 00:00:00 2001 From: Peter Palaga Date: Wed, 16 Oct 2024 12:37:17 +0200 Subject: [PATCH] Use the correct event type CertificateUpdatedEvent in TLS Registry reference --- .../main/asciidoc/tls-registry-reference.adoc | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/src/main/asciidoc/tls-registry-reference.adoc b/docs/src/main/asciidoc/tls-registry-reference.adoc index 4024783fe2e8af..7de7d7e3ee06e1 100644 --- a/docs/src/main/asciidoc/tls-registry-reference.adoc +++ b/docs/src/main/asciidoc/tls-registry-reference.adoc @@ -218,15 +218,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: @@ -262,11 +262,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] @@ -287,12 +287,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. @@ -360,7 +360,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. @@ -378,7 +378,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. @@ -402,7 +402,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 @@ -532,7 +532,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 @@ -542,7 +542,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. @@ -561,9 +561,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] ---- @@ -675,7 +675,7 @@ quarkus.tls.http.key-store.pem.0.cert=tls.crt quarkus.tls.http.key-store.pem.0.key=tls.key ---- -IMPORTANT: Impacted server and client may need to listen to the `CertificateReloadedEvent` to apply the new certificates. +IMPORTANT: Impacted server and client may need to listen to the `CertificateUpdatedEvent` to apply the new certificates. This is automatically done for the Quarkus HTTP server, including the management interface if it is enabled. ifndef::no-kubernetes-secrets-or-cert-manager[] @@ -902,7 +902,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. @@ -1174,7 +1174,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