NoSuchFileException with ${kc.home.dir} on Windows

[crystalgreen]

Before reporting an issue

• I have searched existing issues
• I have reproduced the issue with the latest nightly release

Area

dist/quarkus

Describe the bug

Under Windows, I use keycloak.config with

https-certificate-file=${kc.home.dir}/../../cert/cert.pem

This works in v21 but no longer in v22.
When with kc.bat --verbose start I get sth like

java.nio.file.NoSuchFileException: D:Dir1Dir2Dir3keyCloakbin..\..\..\cert\cert.pem

When I replace the config path with an absolute path containing only / then it works.
E.g. D:/Dir1/Dir2/Dir3/cert/cert.pem.

Version

22.0.3

Expected behavior

The old configuration should work as it did till v21.

Actual behavior

I get a NoSuchFileException instead. Except when I use the workaround: absolute paths with \ replaced by /.

I think, ${kc.home.dir} may return \ separators and this doesn't seem to work with the file load logic.
Either that logic has changed or the ${kc.home.dir} did use / in the past instead of \.

How to Reproduce?

Use Windows and try a https-certificate-file configuration similar to mine, containing ${kc.home.dir}.

Anything else?

It may be similar like #17413.

[vmuzikar]

@Pepo48 Can you please look into this when you get a chance?

[dpulrichth]

We're also experiencing this since Keycloak 22.0.3. It used to work in Keycloak 22.0.1

[Pepo48]

Hello everyone, first of all, thanks for the reports. Jfyi, I can confirm that issue first appeared in 22.0.2.
Let me investigate it in more detail first.

[Pepo48]

I narrowed the problem to this PR/commit. The changes made there suggest that this may be a bug on a Quarkus/SmallRye side (most likely in VertxHttpRecorder.java in quarkus.vertx.http.runtime, according to my brief investigation), since what Keycloak does is that it just consumes (newer) quarkus.http.ssl.certificate.*files Quarkus properties as is and exposes them further as a https-certificate-*file Keycloak properties.

There is already a follow up #21871 to allow to process multiple certificates/keys at once (just to be on a par Quarkus's behaviour).

What we could do at this point is to provide an additional validation, like I similarly did with Keycloak Keystore path/password properties for a similar reason.
Wdyt @mabartos?
Cc: @vmuzikar

I'll send a PR with the proposed in a minute.