dirty

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

@@ -183,6 +183,12 @@ certificate. Dynamic clients are `@Dependent` scoped, so you should
 inject them into components with an appropriate scope.
 ====
 
+=== Referencing the default truststore of SunJSSE
+
+SunJSSE is the default implementation of Java Secure Socket Extension (JSSE).
+It is available in most OpenJDK based Java distributions.
+
+
 == Configuring TLS
 
 TLS configuration primarily involves managing keystores and truststores.
@@ -248,15 +254,15 @@ quarkus.tls.http.key-store.pem.password=password
 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:
 
@@ -292,11 +298,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]
@@ -317,12 +323,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.
@@ -390,7 +396,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.
 
@@ -408,7 +414,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.
 
@@ -432,7 +438,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
@@ -562,7 +568,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
@@ -572,7 +578,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.
 
@@ -591,9 +597,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]
 ----
@@ -937,7 +943,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.
 
@@ -1209,7 +1215,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

extensions/tls-registry/runtime/src/main/java/io/quarkus/tls/runtime/JavaNetSslTlsBucketConfig.java

@@ -27,6 +27,7 @@
  * <li>If the {@code $JAVA_HOME/lib/security/jssecacerts} is a regular file, then it is used
  * <li>If the {@code $JAVA_HOME/lib/security/cacerts} is a regular file, then it is used
  * <li>Otherwise an {@link IllegalStateException} is thrown.
+ * </ol>
  *
  * @since 3.18.0
  */