CertificateUpdatedEvent

[sNiXx]

I would be curious to know a bit more about this new event type:

• Does this apply to the TLS Registry in general? Or more specifically, does this also reload trust stores, CRLs, ...?
• The documentation only mentions that the reload is automatically done for the Quarkus HTTP server. Does this mean I will need to do this manually for Quarkus REST (server and client part), as desribed in the documentation?

Thank you ☺️

PS: There is a typo in the documentation, section 7.1 mentions "CertificateReloadedEvent".

[sNiXx]

Any hints regarding this one? Thanks 🙏🏼

[cescoffier]

At the moment, it only works for the HTTP server (that includes Quarkus REST server, gRPC server, Web Socket (server)).

It reloads everything including trust stores, CRLs....

Can you open an issue (or even better, a pull request) about the typo?

[sNiXx]

Sorry for the delay in my response, I was on holiday.

Can you open an issue (or even better, a pull request) about the typo?

I will definitely do that, as I found another typo.

I have a few follow-up questions if you don't mind:

• Is it expected behavior that the global quarkus.tls.reload-period is "ignored" when there are named tls configurations?
• Is it expected behavior that the built-in reloading mechanism fires a CertificateUpdatedEvent independent of changes in the file system? I expected it to be only fired when any of the files related to the TLS registry have changed.
• Could you provide a pointer for the changes necessary for the REST client (I am using @RegisterRestClient)? Alternatively, I could of course use QuarkusRestClientBuilder instead?

Pointers to the source code would also be appreciated.

Thank you 🙏🏼

[cescoffier]

Is it expected behavior that the global quarkus.tls.reload-period is "ignored" when there are named tls configurations?

It's a bucket property, meaning that each TLS configuration needs to have a value. The rationale is to be able to configure each named configuration individually and also prevent reloading for certificates not expected to be reloaded. So quarkus.tls.reload-period is for the default TLS configuration only.

Is it expected behavior that the built-in reloading mechanism fires a CertificateUpdatedEvent independent of changes in the file system? I expected it to be only fired when any of the files related to the TLS registry have changed.

Yes, you can fire a CertificateUpdatedEvent independently from a file system change. However, the TLS certificates implemented in Quarkus reload from the file system. I didn't implement in-memory certificate as they would not survive a restart or rescheduling.

However, you can implement and register your own TlsConfiguration with a different behavior.

Could you provide a pointer for the changes necessary for the REST client (I am using @RegisterRestClient)? Alternatively, I could of course use QuarkusRestClientBuilder instead?

The graphql client did implement the reloading, but I can't find the code anymore (@jmartisk ?)
However, it will be very similar to onCertificateUpdate from io.quarkus.vertx.http.runtime.HttpCertificateUpdateEventListener

[jmartisk]

The graphql client did implement the reloading, but I can't find the code anymore (@jmartisk ?) However, it will be very similar to onCertificateUpdate from io.quarkus.vertx.http.runtime.HttpCertificateUpdateEventListener

It's in GraphQLClientCertificateUpdateEventListener in jmartisk@c1c5311#diff-67a304adba0031aba268d58ee9e541fe7306af7002032b7b85dfa3e0ea14d817 - it's not merged into the official repo yet, it will be merged along with the upgrade to SmallRye GraphQL 2.11

[sNiXx]

Thanks for the detailed responses, much appreciated :-)

1. All the TLS bucket properties work like this, I assume? Hence, if I had a trust-all or certificate-revocation-list property as well, these would all have to be set for each named configuration? Meaning that the default TLS configuration is not a fallback/global configuration.
2. I was thinking about something else, so I would like to rephrase: Does the built-in mechanism (as described in https://quarkus.io/guides/tls-registry-reference#periodic-reloading) trigger a CertificateUpdatedEvent each time the underlying task is triggered (according to the reload-period property), or only when a file change is detected? From the description in the documentation, I would assume the latter, but the behavior I was experiencing in Dev Mode was the former, I think.
3. Those references are quite valuable, I will look into those for our own implementation. Thank you!

I will try to put my lessons into a pull request, as I think this could be beneficial for other devs as well.