Hi there. We recently started running Stardog 5.3.4 with security on and we can connect with our Java app, and can connect using the web console (if I tell my browser to ignore the cert), but I can't get Stardog Studio to connect. If it matters, the address I'm using is https://localhost:5820. I even tried turning on the self-signed cert option. Studio just sits there and spins until it gives up with no errors. Any ideas?
Can you check if there's anything helpful in either the Stardog log file or the Studio log file? Studio logs are at ~/Library/Logs/Stardog\ Studio/log.log for MacOS and %USERPROFILE%\AppData\Roaming\Stardog Studio\log.log on Windows.
[2019-10-04 13:39:50.875] [error] Error: Request Aborted
at c.on (file:///Applications/Stardog%20Studio.app/Contents/Resources/app.asar/renderer.e573364b8afc221b0489.js:1:614289)
at CallbacksRegistry.apply (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/callbacks-registry.js:47:25)
at handleMessage (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:285:21)
at EventEmitter.ipcRenderer.on.args (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:275:7)
at EventEmitter.emit (events.js:182:13)
[2019-10-04 13:39:50.886] [error] Request Aborted
[2019-10-04 13:39:54.097] [error] Error: net::ERR_EMPTY_RESPONSE
[2019-10-04 13:39:54.097] [error] net::ERR_EMPTY_RESPONSE
[2019-10-04 13:39:54.236] [error] Error: net::ERR_EMPTY_RESPONSE
[2019-10-04 13:39:54.236] [error] net::ERR_EMPTY_RESPONSE
[2019-10-04 13:40:04.279] [error] Error: net::ERR_EMPTY_RESPONSE
[2019-10-04 13:40:04.280] [error] net::ERR_EMPTY_RESPONSE
[2019-10-04 13:40:09.316] [error] Error: net::ERR_EMPTY_RESPONSE
[2019-10-04 13:40:09.316] [error] net::ERR_EMPTY_RESPONSE
[2019-10-04 13:41:15.158] [error] Error: Request Aborted
at c.on (file:///Applications/Stardog%20Studio.app/Contents/Resources/app.asar/renderer.e573364b8afc221b0489.js:1:614289)
at CallbacksRegistry.apply (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/callbacks-registry.js:47:25)
at handleMessage (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:285:21)
at EventEmitter.ipcRenderer.on.args (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:275:7)
at EventEmitter.emit (events.js:182:13)
[2019-10-04 13:41:15.159] [error] Request Aborted
[2019-10-04 13:42:46.325] [error] Error: Request Aborted
at c.on (file:///Applications/Stardog%20Studio.app/Contents/Resources/app.asar/renderer.e573364b8afc221b0489.js:1:614289)
at CallbacksRegistry.apply (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/callbacks-registry.js:47:25)
at handleMessage (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:285:21)
at EventEmitter.ipcRenderer.on.args (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:275:7)
at EventEmitter.emit (events.js:182:13)
[2019-10-04 13:42:46.326] [error] Request Aborted
[2019-10-04 13:56:17.151] [error] Error: Request Aborted
at c.on (file:///Applications/Stardog%20Studio.app/Contents/Resources/app.asar/renderer.e573364b8afc221b0489.js:1:614289)
at CallbacksRegistry.apply (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/callbacks-registry.js:47:25)
at handleMessage (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:285:21)
at EventEmitter.ipcRenderer.on.args (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:275:7)
at EventEmitter.emit (events.js:182:13)
[2019-10-04 13:56:17.154] [error] Request Aborted
1 Like
Sorry for the inconvenience here, and thanks for providing the log. The error messages shown there occur when Studio makes a request and receives no response for 60 seconds, so it seems that Studio is failing to get any response at all back from your endpoint (consistent with the "spins until it gives up" behavior you're seeing). Can you let us know what version of Studio you're using? (If you're on a version older than v1.12.0, it's possible that upgrading could help you.) Also, I assume you don't see any errors in your stardog.log file when attempting to connect with Studio? Are you using a proxy of any kind?
We'll be creating a ticket for this internally and investigating. In the meantime, any answers to the above questions could help us narrow things down.
Thanks,
Jason
Thanks, Jason. I'm using 1.12.0, no proxy, and I don't see any errors in stardog.log.
Hi Jason. I'm just checking in to see if you were able to replicate my issue. I miss my Stardog Studio! 
@borgendorf Sorry it's been so long since we've been in touch. I was just following up on this today and was unable to reproduce any issues with self-signed certificates using Stardog Studio v1.14.3. I tried against Stardog 5.3.4, Stardog 6.1.2, and Stardog 7.1.0 and didn't have any issues. I'm curious whether you have the latest Studio version and whether this issue persists for you.
If the issue is persisting, can you tell us what operating system you're on?
Thanks,
Jason
I really appreciate you testing on your end. Yes, it's still happening to me. I made a quick video so you can see what I see. Thanks!
@borgendorf Thanks for the video; it's very helpful. So far, the only difference I can see between what you're doing and what I'm doing locally to try to reproduce is the fact that you're starting Stardog from some other application. Have you tried starting Stardog manually via the command line and seeing whether that works?
For what it's worth, here is how I start my Stardog server:
STARDOG_SERVER_JAVA_ARGS="-Djavax.net.ssl.keyStore=my-selfsigned-keystore.jks -Djavax.net.ssl.keyStorePassword=MY_PASSWORD_HERE" stardog-admin server start --require-ssl
The server args here just tell Stardog to use the self-signed cert I've generated when using SSL.
After I execute that command, the server starts up in essentially the same way that yours appears to:
And here's what I do in Studio, which appears to be the exact same thing you're doing:
So, I have two questions that may help us:
- Can you re-confirm that there is no proxy being used in your browser? I'm not sure where the proxy settings are in Vivaldi, but hopefully you can find them and take a look (and maybe also check that there is no proxy being used at the OS level, as well; Studio may need to be made aware of that, if there is one).
- Do you have the same problem when you start Studio from the command line in the way that I do, above?
Thanks,
Jason
Hi Jason. Here's what our code uses to start Stardog:
STARDOG_JAVA_ARGS=-Xmx2g -Xms2g -XX:MaxDirectMemorySize=4g -Dfile.encoding=UTF-8 -Djavax.net.ssl.keyStorePassword=<store-password> -Djavax.net.ssl.keyStore=C:/<PathToStardog>/app/stardog.ks -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.trustStorePassword=<trust-password> -Djavax.net.ssl.trustStore=C:/<pathToKeystore>/keystores/champion.ts -Djavax.net.ssl.trustStoreType=jceks C:/<pathToStardog>/app/bin/stardog-admin.bat server start --home C:/<pathToStardogHome>/db --require-ssl --upgrade
Are there any spaces in <pathToStardog> and are you running that as a single command or two commands?
No spaces, and two commands.
try putting export in front of STARDOG_JAVA_ARGS
Thanks for the suggestions, but it doesn’t make a difference. For another datapoint, the behavior from Studio is the same (timeout) if I try to connect to a remote Stardog https instance, so it’s not merely a localhost problem.
I'm sure you've tried it but it appeared in the video like you selected "accept self signed certificates" while it was trying to connect but didn't try connecting after you had selected it.
You can try debugging the TLS connection with openssl in client mode. Here's a decent website on using it https://www.poftut.com/use-openssl-s_client-check-verify-ssltls-https-webserver/
Yeah, I mention it in the audio but didn’t go through all the permutations in the video. It times out even if I check the self-signed box before connecting. It also doesn’t matter what the username and password are set to. I used s_client
to connect to it and I can see the self-signed cert, the handshake, and a return code of “0 (ok)”. I guess the part I don’t understand is why our app and the browser don’t have problems connecting, but Studio does.
@borgendorf The only other difference I noticed between what you're doing and what I'm doing is that you're using a pkcs12 type of key. However, I've now generated such a key locally and used it to start Stardog, and unfortunately still cannot reproduce your issue. I've confirmed that Studio fails to connect when I try to connect without "Allow connections with self-signed certificates" checked, but succeeds in connecting when it is checked.
Are you able to answer either of my questions #1 and #2 above? I.e., are you positive there is no proxy the browser might be aware of that Studio is not, and are you able to start Stardog manually from the command line and connect with Studio?
The only remaining difference that I notice between your setup and mine is that you are on Windows and I am on macOS at the moment. However, I believe you mentioned that you have the same issue on macOS.
Thanks,
Jason
So strange…I really appreciate you checking and trying so many things. I'm on a Mac as well, and no one else in our company can do it either. I’m sorry I didn’t answer those other questions before, but there is no web proxy on the browsers and if we run Stardog manually we still cannot connect. We are going to try generating a new key just to see if it helps.
Incidentally, I found the Studio log file on my Mac, but I'm not sure it helps any.
[2020-01-09 11:56:43.169] [error] Error: Request Aborted
at l.on (file:///Applications/Stardog%20Studio.app/Contents/Resources/app.asar/renderer.43bcadd8484dd8cce5ee.js:1:719519)
at CallbacksRegistry.apply (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/callbacks-registry.js:47:25)
at handleMessage (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:285:21)
at EventEmitter.ipcRenderer.on.args (/Applications/Stardog Studio.app/Contents/Resources/electron.asar/renderer/api/remote.js:275:7)
at EventEmitter.emit (events.js:182:13)
[2020-01-09 11:56:43.179] [error] The request was aborted. Please check the status of your Stardog Server.It could be having trouble negotiating a cipher suite. I don't know what library Studio is using but it could be using openssl which could be old and your JDK might have disabled the old cipher suites because of the Heartbleed, Poodle, etc attacks.
You might be able to see this if you enable logging in for ssl in the JVM. Try adding
-Djavax.net.debug=ssl:handshake:verbose
You might be on to something here...thanks for that flag. When we run verbose we can see Studio make contact with Stardog. Here are the ciphers that are being ignored. Maybe one of them is used by Studio?
Disabled/Unsupported Cipher List
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_256_CBC_SHA256
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_DES_CBC_MD5
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
Ignoring disabled cipher suite: SSL_DH_anon_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_3DES_EDE_CBC_MD5
Ignoring disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_RSA_WITH_NULL_SHA256
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_NULL_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_DES_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_RC4_40_SHA
Ignoring disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_RC4_128_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_AES_256_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
Ignoring disabled cipher suite: TLS_KRB5_EXPORT_WITH_RC4_40_MD5
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_AES_128_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: TLS_KRB5_WITH_RC4_128_MD5
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_NULL_SHA
Ignoring disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_SHA
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_128_CBC_SHA256
Ignoring disabled cipher suite: SSL_RSA_WITH_NULL_MD5
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_128_GCM_SHA256
Ignoring disabled cipher suite: TLS_DH_anon_WITH_AES_256_GCM_SHA384
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
Ignoring disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1