Nxt Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client 1.11.4 - NEW RELEASE: Ardor 2.0.2e TestNet IS LAUNCHED!

Pages: 1 2 3 [4]  All

Author Topic: NRS v1.8.1  (Read 10163 times)

martismartis

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1202
    • View Profile
  • Karma: +67/-10
Re: NRS v1.8.1
April 14, 2016, 08:39:28 am

If you haven't restarted it yet, what is your peer IP (assuming it is with open API)?

Already restarted with new db :(

Klokan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 269
    • View Profile
  • Karma: +27/-5
Re: NRS v1.8.1
April 14, 2016, 09:27:21 am


Nothing wrong in the log, I can see that everything initializes properly.
I don't see a browser connection though. When you connect a browser you should see lot's and lot's of SSL handshake related messages.

Please capture another set of logs, restart your node then connect Firefox using https on port 7876 and let it fail, then post the resulting log again.
Also please post the exact error message you received from Firefox.
Then restart the node again, connect using Chrome until loading the signon page and post another log here.

Allright, there is another debug log :

http://nxt1.y.cz/nxt-debug.log-20160414.gz

Interestingly, I tried the connect :
     * firstly over FF (firefox-45.0.1-2.fc23.x86_64)
     * secondly over Chromium (chromium-49.0.2623.108-1.fc23.x86_64)
     * thirdly over Gnome Web (epiphany-3.18.5-1.fc23.x86_64)

It has been failed in every cases. This would be related messages from nxt debug :

Code: [Select]
qtp2030036700-62, fatal error: 80: problem unwrapping net record
java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available

And also Epiphany tells something like : "Peer failed to perform TLS handshake".


Really strange. In any case, many thanks for your help and co-operation, Riker !

OutSL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 332
    • View Profile
  • Karma: +60/-0
Re: NRS v1.8.1
April 14, 2016, 06:25:08 pm


Nothing wrong in the log, I can see that everything initializes properly.
I don't see a browser connection though. When you connect a browser you should see lot's and lot's of SSL handshake related messages.

Please capture another set of logs, restart your node then connect Firefox using https on port 7876 and let it fail, then post the resulting log again.
Also please post the exact error message you received from Firefox.
Then restart the node again, connect using Chrome until loading the signon page and post another log here.

Allright, there is another debug log :

http://nxt1.y.cz/nxt-debug.log-20160414.gz

Interestingly, I tried the connect :
     * firstly over FF (firefox-45.0.1-2.fc23.x86_64)
     * secondly over Chromium (chromium-49.0.2623.108-1.fc23.x86_64)
     * thirdly over Gnome Web (epiphany-3.18.5-1.fc23.x86_64)

It has been failed in every cases. This would be related messages from nxt debug :

Code: [Select]
qtp2030036700-62, fatal error: 80: problem unwrapping net record
java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available

And also Epiphany tells something like : "Peer failed to perform TLS handshake".


Really strange. In any case, many thanks for your help and co-operation, Riker !
use let's encrypt certificates... you get your files ready to use in 2 seconds 2 commands
i installed it with the commands for the apache plugins and got my site under https at the end of the operations without any additional settings...
https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04
i converted the stuff as this:
https://nxtforum.org/index.php?topic=10626.msg215919#msg215919

and the result is here  :D
https://nxt3d.net:7876/index.html

Thank you all and @++
Thank you for your financial help, your donations will be used in the R&D related to the implementation of NXT in the virtual worlds running under OpenSimulator.org | Donations Box : NXT-PC8Q-ZW86-7UYK-CC4XJ
Visit The NXT Community Virtal World! Your NXT 3D Chat Service

ScripterRon

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 455
    • View Profile
  • Karma: +72/-2
Re: NRS v1.8.1
April 14, 2016, 08:55:43 pm

Allright, there is another debug log :

http://nxt1.y.cz/nxt-debug.log-20160414.gz

Interestingly, I tried the connect :
     * firstly over FF (firefox-45.0.1-2.fc23.x86_64)
     * secondly over Chromium (chromium-49.0.2623.108-1.fc23.x86_64)
     * thirdly over Gnome Web (epiphany-3.18.5-1.fc23.x86_64)

It has been failed in every cases. This would be related messages from nxt debug :

Code: [Select]
qtp2030036700-62, fatal error: 80: problem unwrapping net record
java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available

And also Epiphany tells something like : "Peer failed to perform TLS handshake".


Really strange. In any case, many thanks for your help and co-operation, Riker !
It sounds like the TLS handshake is using an encryption algorithm that is not available.  The EC algorithms are part of the SunEC provider.  This provider is not shipped with OpenJDK.  Your debug log lists the TLS_ECDH_* algorithms as unavailable.  Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1167153.  There are some suggestions on how to overcome this problem.  Also http://stackoverflow.com/questions/31971499/ecdhe-cipher-suites-not-supported-on-openjdk-8-installed-on-ec2-linux-machine.

I don't know why it works with Nxt 1.7 and not with Nxt 1.8.  My guess is the different Jetty versions are the cause.  You could try replacing the jetty-* and websocket-* libraries in Nxt 1.8 with the libraries from Nxt 1.7 and see if that corrects the problem.
NXT-XM86-4ZNA-65L5-CDWUE

ScripterRon

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 455
    • View Profile
  • Karma: +72/-2
Re: NRS v1.8.1
April 14, 2016, 09:08:17 pm

By the way, if you want to see if the problem is in your browser, try connecting to https://nrs.scripterron.org:7877.  I am able to connect using Chrome and Edge on Windows 10 and Firefox on Ubuntu 14.04.
NXT-XM86-4ZNA-65L5-CDWUE

ScripterRon

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 455
    • View Profile
  • Karma: +72/-2
Re: NRS v1.8.1
April 14, 2016, 11:25:05 pm

It sounds like the TLS handshake is using an encryption algorithm that is not available.  The EC algorithms are part of the SunEC provider.  This provider is not shipped with OpenJDK.  Your debug log lists the TLS_ECDH_* algorithms as unavailable.  Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1167153.  There are some suggestions on how to overcome this problem.  Also http://stackoverflow.com/questions/31971499/ecdhe-cipher-suites-not-supported-on-openjdk-8-installed-on-ec2-linux-machine.

I don't know why it works with Nxt 1.7 and not with Nxt 1.8.  My guess is the different Jetty versions are the cause.  You could try replacing the jetty-* and websocket-* libraries in Nxt 1.8 with the libraries from Nxt 1.7 and see if that corrects the problem.
Something else to try:

Create conf/logging.properties with the following line:
  org.eclipse.jetty.util.ssl.level=FINE

Then start your Nxt 1.8 server and look in Nxt.log for the list of selected provider ciphers.  Do the same for your Nxt 1.7 server and see if the list is different.

Here is the list for my Nxt 1.8 server:
Code: [Select]
Selected Ciphers   [
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV] of [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_DH_anon_WITH_AES_128_GCM_SHA256,
TLS_DH_anon_WITH_AES_128_CBC_SHA256, TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA,
 SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_RSA_WITH_NULL_SHA256, TLS_ECDHE_ECDSA_WITH_NULL_SHA,
TLS_ECDHE_RSA_WITH_NULL_SHA, SSL_RSA_WITH_NULL_SHA, TLS_ECDH_ECDSA_WITH_NULL_SHA,
TLS_ECDH_RSA_WITH_NULL_SHA, TLS_ECDH_anon_WITH_NULL_SHA, SSL_RSA_WITH_NULL_MD5,
TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5]

NRS also logs a debug message with the selected ciphers after the SSL context has been created.  Here is what my server logs:
Code: [Select]
API SSL Ciphers: [
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
See if this list is different for you between 1.7 and 1.8.
« Last Edit: April 15, 2016, 12:00:53 am by ScripterRon »
NXT-XM86-4ZNA-65L5-CDWUE

Klokan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 269
    • View Profile
  • Karma: +27/-5
Re: NRS v1.8.1
April 16, 2016, 01:25:18 pm


It sounds like the TLS handshake is using an encryption algorithm that is not available.  The EC algorithms are part of the SunEC provider.  This provider is not shipped with OpenJDK.  Your debug log lists the TLS_ECDH_* algorithms as unavailable.  Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1167153.  There are some suggestions on how to overcome this problem.  Also http://stackoverflow.com/questions/31971499/ecdhe-cipher-suites-not-supported-on-openjdk-8-installed-on-ec2-linux-machine.

I don't know why it works with Nxt 1.7 and not with Nxt 1.8.  My guess is the different Jetty versions are the cause.  You could try replacing the jetty-* and websocket-* libraries in Nxt 1.8 with the libraries from Nxt 1.7 and see if that corrects the problem.

Yep, ScripterRon, you win the bet ;-). I tested it and -- websocket it's not necessary to replace (newer websocket-*9.3.8*jar files works as good as older websocket-*9.3.6*jar files), but jetty-*.jar files are the issue! When I replace the current 9.3.8 by the 9.3.6 older ones, everything starts to work well (as before).

So, many thanks, and a final question - would it be possible to repair it in 1.8.2 NRS version, or you cannot edit/fix in jetty jar files (almost) anything ?

ScripterRon

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 455
    • View Profile
  • Karma: +72/-2
Re: NRS v1.8.1
April 16, 2016, 03:43:10 pm


It sounds like the TLS handshake is using an encryption algorithm that is not available.  The EC algorithms are part of the SunEC provider.  This provider is not shipped with OpenJDK.  Your debug log lists the TLS_ECDH_* algorithms as unavailable.  Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1167153.  There are some suggestions on how to overcome this problem.  Also http://stackoverflow.com/questions/31971499/ecdhe-cipher-suites-not-supported-on-openjdk-8-installed-on-ec2-linux-machine.

I don't know why it works with Nxt 1.7 and not with Nxt 1.8.  My guess is the different Jetty versions are the cause.  You could try replacing the jetty-* and websocket-* libraries in Nxt 1.8 with the libraries from Nxt 1.7 and see if that corrects the problem.

Yep, ScripterRon, you win the bet ;-). I tested it and -- websocket it's not necessary to replace (newer websocket-*9.3.8*jar files works as good as older websocket-*9.3.6*jar files), but jetty-*.jar files are the issue! When I replace the current 9.3.8 by the 9.3.6 older ones, everything starts to work well (as before).

So, many thanks, and a final question - would it be possible to repair it in 1.8.2 NRS version, or you cannot edit/fix in jetty jar files (almost) anything ?
No, we can't change the Jetty files. And Jetty might  not consider this a bug since they removed less secure ciphers in favor of the EC ciphers (which are more secure). If you can't install the EC ciphers on your system, you can try enabling the old ciphers. There is a nxt property to specify the ciphers to be used. Unfortunately, I don't remember the name and I'm out of town and can't look at the code. If you look in nxt-default.properties, you will see a list of ciphers commented out. Copy this list to nxt.properties, uncomment it and add the missing ciphers. Hopefully, this will allow Jetty to select the cipher that you need.
NXT-XM86-4ZNA-65L5-CDWUE

ScripterRon

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 455
    • View Profile
  • Karma: +72/-2
Re: NRS v1.8.1
April 16, 2016, 04:01:48 pm

By the way, the Jetty SSL debug log should tell you what cipher was selected for the successful connection. This is the one you need to add if it is not already in the list.
NXT-XM86-4ZNA-65L5-CDWUE

OutSL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 332
    • View Profile
  • Karma: +60/-0
Re: NRS v1.8.1
April 16, 2016, 07:28:40 pm

Hi  :D

a suggestion for the next... for a public use of the graphical interface of NRS ... add a configuration that allows the deactivation of the options that are supposed to be used in localhost or for a private use
example, the setting page must not allow some changes for the normal public users, i have disabled manually on the code  but it will be better if it was configurable in nxt.proprieties
see the setting page here:
https://nxt3d.net:7876/index.html

Thank you and @++
Thank you for your financial help, your donations will be used in the R&D related to the implementation of NXT in the virtual worlds running under OpenSimulator.org | Donations Box : NXT-PC8Q-ZW86-7UYK-CC4XJ
Visit The NXT Community Virtal World! Your NXT 3D Chat Service

Riker

  • Core Dev
  • Hero Member
  • *****
  • Online Online
  • Posts: 1500
    • View Profile
  • Karma: +396/-42
Re: NRS v1.8.1
April 16, 2016, 08:34:50 pm

Hi  :D

a suggestion for the next... for a public use of the graphical interface of NRS ... add a configuration that allows the deactivation of the options that are supposed to be used in localhost or for a private use
example, the setting page must not allow some changes for the normal public users, i have disabled manually on the code  but it will be better if it was configurable in nxt.proprieties
see the setting page here:
https://nxt3d.net:7876/index.html

Thank you and @++

The settings in the settings page are stored per browser per account so even for public nodes setting changes of one user does not affect the other users even if they are using the same browser.
In light of this, which settings would you like to be able to disable ?
NXT Core Dev
Account: NXT-HBFW-X8TE-WXPW-DZFAG
Public Key: D8311651 Key fingerprint: 0560 443B 035C EE08 0EC0  D2DD 275E 94A7 D831 1651

OutSL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 332
    • View Profile
  • Karma: +60/-0
Re: NRS v1.8.1
April 17, 2016, 07:29:07 pm

Hi  :D

Hi  :D

a suggestion for the next... for a public use of the graphical interface of NRS ... add a configuration that allows the deactivation of the options that are supposed to be used in localhost or for a private use
example, the setting page must not allow some changes for the normal public users, i have disabled manually on the code  but it will be better if it was configurable in nxt.proprieties
see the setting page here:
https://nxt3d.net:7876/index.html

Thank you and @++

The settings in the settings page are stored per browser per account so even for public nodes setting changes of one user does not affect the other users even if they are using the same browser.
In light of this, which settings would you like to be able to disable ?

Ha! thank you for this info, is just to avoid that the users affect the others like a template change or affect the node by changing the admin password or the shapeshift api key... you know better than me that things  :D

but for example the "Remember Account" for the returning users or the remember passphrases in the settings... things like this may lead to a security risk if was stored locally in the node and the public user must don't have the access or a modification right for this features...

for the marketplace images, there is no way to go back to the product modal after the image modal... a "Back" button must be add in the image modal to allow the buyer to go back to the product if he/she want to purchase...
to reproduce (from the lands seller item):
https://nxt3d.net:7876/index.html?account=NXT-FG53-RQ5S-PWAR-HRLZS&modal=dgs_purchase_modal&goods=5262690982377691296
click the product image, will open the image modal but the purchase product modal will be closed and there is no way to go back to the purchase modal...

thank you and @++
Thank you for your financial help, your donations will be used in the R&D related to the implementation of NXT in the virtual worlds running under OpenSimulator.org | Donations Box : NXT-PC8Q-ZW86-7UYK-CC4XJ
Visit The NXT Community Virtal World! Your NXT 3D Chat Service

testdruif

  • Full Member
  • ***
  • Offline Offline
  • Posts: 224
    • View Profile
  • Karma: +71/-1
Re: NRS v1.8.1
April 17, 2016, 10:46:33 pm

for the marketplace images, there is no way to go back to the product modal after the image modal... a "Back" button must be add in the image modal to allow the buyer to go back to the product if he/she want to purchase...
to reproduce (from the lands seller item):
https://nxt3d.net:7876/index.html?account=NXT-FG53-RQ5S-PWAR-HRLZS&modal=dgs_purchase_modal&goods=5262690982377691296
click the product image, will open the image modal but the purchase product modal will be closed and there is no way to go back to the purchase modal...

I've added a back button (will be available with the next release)
The button will be shown when you approach the picture modal from either the purchase or product modal


« Last Edit: April 17, 2016, 11:01:03 pm by testdruif »
**Necessity is the mother of invention**
NXT-NNGD-V8TN-3MZR-DWWBE
https://arguseyes.net

VanBreuk

  • Administrator
  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2353
    • View Profile
  • Karma: +315/-18
Re: NRS v1.8.1
April 17, 2016, 11:53:25 pm

Just adding my experience with update to 1.8.1 using SSL and seeing
java.lang.IllegalStateException: no valid keystore
in the first run. In my cases the fix was simple, just replacing absolute keystore path with relative path in nxt.properties. from
nxt.keyStorePath=/home/user/ssl/keystore.jks
to
nxt.keyStorePath=../ssl/keystore.jks
being nxt path
/home/user/nxt
API SSL Ciphers came through nicely and the nodes are working.
GPG Fingerprint: B020 D1C1 F289 3B2C 3577  9EAD 455D D175 5913 C7F1

ScripterRon

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 455
    • View Profile
  • Karma: +72/-2
Re: NRS v1.8.1
April 18, 2016, 06:17:12 pm

Just adding my experience with update to 1.8.1 using SSL and seeing
java.lang.IllegalStateException: no valid keystore
in the first run. In my cases the fix was simple, just replacing absolute keystore path with relative path in nxt.properties. from
nxt.keyStorePath=/home/user/ssl/keystore.jks
to
nxt.keyStorePath=../ssl/keystore.jks
being nxt path
/home/user/nxt
API SSL Ciphers came through nicely and the nodes are working.
The problem with an absolute keystore path is fixed in 1.8.2.
NXT-XM86-4ZNA-65L5-CDWUE
Pages: 1 2 3 [4]  All