Location of the Karaf ssl certs

I’m running OH2 in a Docker container using the snapshots as described here:

Every time I restart the service it starts up a new container. So far this works great and it lets me sidestep some of the upgrade issues since my userdata and conf folders are mounted into the container so don’t get wiped out with updates.

However I do have one minor problem which I’m having trouble figuring out. Every time I restart the container, the ssl cert for the karaf console ssh connection gets regenerated. So that means I have to remove the cert from my known hosts every time I want to connect to the console after a restart.

I tried mounting the host’s /etc/ssl/certs into the container but it appears karaf uses its own certs.

I’ve applied my find skills to see if I could find the certs in the openhab directory but I could not find any pem files.

I did find where I think I can configure karaf to allow login using a cert but that doesn’t help me capture and keep the cert the host uses to identify itself.

Does anyone have any insights?


The ssl cert is generated on first startup and put into userdata/etc/keystore. If you keep your userdata folder, I would expect it to be found and thus not being re-generated. So although I can tell you where it is, I doubt I can help you identifying your problem…

Odd indeed as userdata/etc/keystore is indeed being mounted into the container. I wonder if there is something somewhere else that is causing karaf to think it has to regenerate the keystore.

So what gets stored in userdata.dist? There is a keystore there as well:


I assumed that was the keystore for the Jetty server but now I wonder…

Tried making a copy and mounting it into the container too and and I’m still getting a new key.

Is it bad to keep this folder mounted like this or should this one continue to remain in the container?

It occurs to me I’m not setting the hostname in the container so that is being autogenerated. :frowning: Didn’t work.

Back to the drawing board…

This is something docker specific, so you’ll need some docker specialist (@cniweb?) here…