I need to enable SSL encryption between the Servoy client and server. There is not much info about it in the documentation, but I managed to create a keystore and entered the path and password in the Server Administration console. After restarting the server I run the client and get an error: “Cannot find repository, it may not be running on server”.
I need to enable SSL encryption between the Servoy client and server. There is not much info about it in the documentation, but I managed to create a keystore and entered the path and password in the Server Administration console. After restarting the server I run the client and get an error: “Cannot find repository, it may not be running on server”.
Any ideas about this?
Should I have the key signed by a Certificate Authority?
Hi Joonas,
To enable the SSL feature, you DO NOT have to create a keystore - all you have to do is to CHECK the “Use SSL” checkbox on the Servoy admin page (http://youripaddress:8080/servoy-admin).
You only need to generate a keystore if you want ADDED security.
To enable the SSL feature, you DO NOT have to create a keystore - all you have to do is to CHECK the “Use SSL” checkbox on the Servoy admin page (http://youripaddress:8080/servoy-admin).
You only need to generate a keystore if you want ADDED security.
But Servoy Server gives this message:
Warning: No keystore specified, using default testkeys. THIS IS NOT SECURE!
Anyway, is it possible to have a little howto on the subject? I also tried to set up SSL, but I found it quite difficult.
Warning: No keystore specified, using default testkeys. THIS IS NOT SECURE!
It is telling this be couse if you enable SSL and not specifing a keystore it is using test keystore (we ship within Servoy), this means the communication is encrypted but the keys used are semi public, to completely secure get yourself a certificate and create a keystore file with it, many links about how to make a keystore can be found via google.
Jan Blok:
It is telling this be couse if you enable SSL and not specifing a keystore it is using test keystore (we ship within Servoy), this means the communication is encrypted but the keys used are semi public, to completely secure get yourself a certificate and create a keystore file with it, many links about how to make a keystore can be found via google.
I’ve tried following some directions, but it doesn’t work. I tried with a self-signed cert and a CA signed cert.
Do i need to use a specific alias name?
Also there are separate passwords for the keystore and a certificate, but Servoy lets me only specify one.
Of course, I can keep on trying different combinations
Thanks!
.. I have done it just the same way and when listing keystore contents it’s the same structure… Still doesn’t work - error connecting to repository. The problem must be somewhere else than the keystore. I’ll take a look at it after some time… If anybody has any ideas about this, please share. I’m getting desperate!
is indeed a very different problem, it means it can not found the database with the servoy repository tables.
Check for example if your database is running.
back again after a while with still the same issue…
Jan Blok:
jonttu:
error connecting to repository
is indeed a very different problem, it means it can not found the database with the servoy repository tables.
Check for example if your database is running.
Everything works fine with SSL disabled, and also with the internal test keys (keystore path not specified), but not with my own created keystore. I followed the steps in that web page… My keystore contains:
# keytool -list -keystore servoy.keystore
Enter keystore password: *********
Keystore type: jks
Keystore provider: SUN
Your keystore contains 2 entries
cacert, Aug 5, 2004, trustedCertEntry,
Certificate fingerprint (MD5): FD:06:81:BF:93:56:54:25:D6:74:D7:F8:43:A3:62:45
mykey, Aug 5, 2004, keyEntry,
Certificate fingerprint (MD5): 4F:BB:49:61:42:84:6C:92:8D:6A:40:83:CE:F2:A7:69
Some ideas:
do key alias names matter? i’ve tried “servoy” and “mykey”
should key passwords be same as the keystore password?
my certificate authority is not Thawte or Verisign, but our University’s own CA, does it matter?
I’m running the application server in Red Hat Enterprise linux under a dedicated user account “servoy”.
keytool is an application that gets installed in your Java directory when you install java SDK (NOT JRE).
keytool is a COMMAND LINE program - there is no UI
To generate a keystore - open a command prompt (start → run then enter cmd). Type in:
keytool -help
IF you get back a long listing - then go to the next step. If you DO NOT get a long listing - or see something like “unrecognized command” - then navigate to your BIN folder inside your java install directory using something like:
Go to Network Settings and enter the FULL PATH to the keystore in the field SocketFactory SSLKeystorePath, and enter your password (the “keystore” password you entered above) into the SocketFactoryKeystorePassphrase field.
Thanks for the tip on making the key. I believe I now have a valid key but when I follow the rest of the directions it does not work.
I placed the key file in server/conf/keystore and specified the path and passphrase in the server. {also tried server/conf} I have also checked off useTwoWaySocket and useSSL. When I try to log onto the server I get the no repository running on this server message.
I have the same problem.
I created the kestore, I typed path and passfrase in Network Settings, the I saved ad server said OK. I restarted the server.
Now if I try to connect from client I have the error “Cannot find repository, it may not be running on server”.
Futhermore, it is also insecure. Anybody who feels like it can make a self-signed certificate with the same fields and do a man in the middle attack which is not detectable.
Maybe we will allow you to store certs client side in a future release to make it semi-safe to work with self-signed certificates, but this is not currently high on the list of priorities.
Yes, this is indeed the case. The previous explanation is incorrect as Servoy does not accept self signed certificates. The updated explanation in the FAQ is correct.
