Error generation certificate on OpenHAB boot

maxin · July 1, 2022, 12:38pm

Hello.
I replaced MY keystore certificate with my real one. I also changed the password(s). I made all the changes in runtime\etc\jetty.xml

	<New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory$Server">
		<Set name="KeyStorePath"><SystemProperty name="jetty.keystore.path" default="/etc/myKeystore" /></Set>
		<Set name="KeyStorePassword"><SystemProperty name="jetty.ssl.password" default="OBF:mysecretkey" /></Set>
		<Set name="KeyManagerPassword"><SystemProperty name="jetty.ssl.keypassword" default="OBF:mysecretkey" /></Set>
		<Set name="TrustStorePath"><SystemProperty name="jetty.truststore.path" default="/etc/myKeystore" /></Set>
		<Set name="TrustStorePassword"><SystemProperty name="jetty.ssl.password" default="OBF:mysecretkey" /></Set>
		<Set name="EndpointIdentificationAlgorithm"></Set>
		<Set name="NeedClientAuth"><SystemProperty name="jetty.ssl.needClientAuth" default="false" /></Set>
		<Set name="WantClientAuth"><SystemProperty name="jetty.ssl.wantClientAuth" default="false" /></Set>
	</New>

Now I have a secure connection, but openhab not happy at every boot that it cannot create a certificate.
How to remove this error? I understand that I have to use SSL through a reverse proxy, but I need this approach.

Why does he swear at the password if he uses it later without problems?

2022-07-01 15:20:38.642 [ERROR] [ficate.internal.CertificateGenerator] - Failed to generate a new SSL Certificate.
java.security.KeyStoreException: Failed to load the keystore R:\servers\openhab\userdata\etc\keystore
	at org.openhab.core.io.jetty.certificate.internal.CertificateGenerator.ensureKeystore(CertificateGenerator.java:132) ~[bundleFile:?]
	at org.openhab.core.io.jetty.certificate.internal.CertificateGenerator.start(CertificateGenerator.java:88) [bundleFile:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:813) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl$2.run(BundleContextImpl.java:1) [org.eclipse.osgi-3.17.200.jar:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:805) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:762) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1032) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:371) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.Module.doStart(Module.java:605) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.Module.start(Module.java:468) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1847) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1840) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1745) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1667) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.17.200.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.17.200.jar:?]
Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
	at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:795) ~[?:?]
	at sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:222) ~[?:?]
	at java.security.KeyStore.load(KeyStore.java:1479) ~[?:?]
	at org.openhab.core.io.jetty.certificate.internal.CertificateGenerator.ensureKeystore(CertificateGenerator.java:130) ~[bundleFile:?]
	... 19 more
Caused by: java.security.UnrecoverableKeyException: Password verification failed
	at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:793) ~[?:?]
	at sun.security.util.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:222) ~[?:?]
	at java.security.KeyStore.load(KeyStore.java:1479) ~[?:?]
	at org.openhab.core.io.jetty.certificate.internal.CertificateGenerator.ensureKeystore(CertificateGenerator.java:130) ~[bundleFile:?]
	... 19 more

Wolfgang_S · July 1, 2022, 4:55pm

Your wrote, that you made all the changes in runtime\etc\jetty.xml.
As far as I understand this includes the path to your keystore containing your certificate as well.

To my understanding

<Set name="KeyStorePath"><SystemProperty name="jetty.keystore.path" default="/etc/myKeystore" /></Set>

defines the default value for the keystore but this is overwritten by content of etc/custom.system.properties which contains:

 jetty.keystore.path=${openhab.userdata}/etc/keystore

so the keystore that is being used is found in a different location as modified and stored in runtime/etc/jetty.xml

maxin · July 4, 2022, 6:31am

I’m going to try now

maxin · July 4, 2022, 6:40am

I checked. I only changed the passwords in the files runtime/etc/jetty.xml and userdata\etc\keystore .
Of course, I replaced the contents of the keystore, but it is in its usual place. I did not change the pathes anywhere, they correctly point to the files location.

maxin · July 4, 2022, 7:16am

The problem cannot be solved. I changed my password, and openhab is using a hardcoded password to generate a self-signed certificate… very strange solution.

maxin · July 4, 2022, 7:26am

As a result, I changed the password to the default and the problem went away. But this is not correct, it would be better if they read from the settings.

Wolfgang_S · July 4, 2022, 5:11pm

Are you sure that one ( hard corded password for self signed certificate ) is depending on the other ( cannot change password when certificates are changed ) ?
It is just using a hard corded certificate for the initial setup. Initial setup is used as long as there is not certificate setup in the box’s keystore.

According to Securing Communication and Access | openHAB

If you wish, you can import your own certificate into this keystore. Please ensure that you remove the old certificate and give the new certificate the same alias as the old one (otherwise, the App might still be presented the old certificate).

You also took care of that ( alias ) ?

Basic instructions for OH2 were posted here: Securing Openhab with free ssl Let's Encrypt Certificates . There different passwords were used.

maxin · July 5, 2022, 12:13pm

Yes I am sure. Look at the code, it wants to create a certificate if it’s not in the store. But since the password doesn’t match (and it uses a hardcoded password, not a custom one), it can’t check if it’s there or not. We will get an error. The code must have read the password from custom.system.properties (just like he’s looking for the keystore) then this error would not exist. Sloppy programming.