We are getting the error:
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='1.1.1.1', port=5821): Max retries exceeded with url: /admin/databases (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x000001E497014AC0>: Failed to establish a new connection: [WinError 10061] No connection could be made because the target machine actively refused it'))
On an Ubuntu image 18.04.
Sorry but how should we clear this?
Andrea
Is there any possibility that your Stardog instance is behind a reverse proxy? If it was and one of your servers has a misconfigured firewall that might explain the seemingly random errors connecting. The "the target machine actively refused it" means it made a connection and the machine explicitly said, "Nope!" which you see when a firewall actively closes connections. If it happens all the time it might just be a firewall config problem.
No proxies.
And, we killed the Stardog VM and reset our connection pool.
Same error.
Andrea
After reboot and restart, we are seeing ...
requests.exceptions.SSLError: HTTPSConnectionPool(host='10.108.17.144', port=5820): Max retries exceeded with url: /admin/databases (Caused by SSLError(SSLError("bad handshake: SysCallError(-1, 'Unexpected EOF')")))
Ideas?
Andrea
Now it looks like you’re having a problem negotiating a TLS cypher suite. I’ll take a look at the pystardog code and see if I can come up with some suggestions.
TLS1.3 is reported for the Stardog VM.
Andrea
When a local query was tried (ssh into the VM) ... Got the error:
- ubuntu@bbn-stardog:/var/opt/stardog$ stardog query https://1.1.1.1:5821 'select * WHERE {?s ?p ?o} LIMIT 10'
ERROR 2020-05-04 19:03:21,380 [main] com.complexible.stardog.security.PasswordFile:getCredentials(242): Server URL provided to password file was not valid
java.net.URISyntaxException: Expected authority at index 8: https://
at java.net.URI$Parser.fail(URI.java:2848) ~[?:1.8.0_252]
at java.net.URI$Parser.failExpecting(URI.java:2854) ~[?:1.8.0_252]
at java.net.URI$Parser.parseHierarchical(URI.java:3102) ~[?:1.8.0_252]
at java.net.URI$Parser.parse(URI.java:3053) ~[?:1.8.0_252]
at java.net.URI.(URI.java:588) ~[?:1.8.0_252]
at com.complexible.stardog.security.PasswordFile.getCredentials(PasswordFile.java:239) [stardog-core-shared-7.2.1.jar:?]
at com.complexible.stardog.cli.impl.BaseStardogCommand.computeCredentials(BaseStardogCommand.java:99) [stardog-cli-7.2.1.jar:?]
at com.complexible.stardog.cli.impl.BaseStardogCommand.getCredentials(BaseStardogCommand.java:86) [stardog-cli-7.2.1.jar:?]
at com.complexible.stardog.cli.impl.ConnectionCommand.connect(ConnectionCommand.java:127) [stardog-cli-7.2.1.jar:?]
at com.complexible.stardog.cli.impl.ConnectionCommand.call(ConnectionCommand.java:74) [stardog-cli-7.2.1.jar:?]
at com.complexible.stardog.cli.CLIBase.execute(CLIBase.java:56) [stardog-cli-7.2.1.jar:?]
at com.complexible.stardog.cli.CLI.main(CLI.java:111) [stardog-cli-7.2.1.jar:?]
Remote host closed connection during handshake
The username password was set in the home directory in .sdpass.
Are you setting the stardog.passwd.file system property and if you are is it pointing to your sdpass file? If not is the .sdpass file in the home directory of the user your running as?
For the SSL issue you should check to make sure you're running the latest version of openssl. This should be on the Ubuntu client running pystardog
Version is 1.1.1 but not 1.1.1g.
It is on an AWS client.
Andrea
Also, when I do a stardog-admin server start ... It seems to be listening on a IPv6 (tcp6) address (:::5821).
That seems strange to me.
Andrea
Forced Stardog to listen on IPv4 via export _JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true", but still can't get an external connection using HTTPS.
I can connect using HTTP (since I only started Stardog with --enable-ssl and not --require-ssl).
Andrea
Here is the detailed curl error ... curl -v https://localhost:5821
- Rebuilt URL to: https://localhost:5821/
- Trying 127.0.0.1...
- TCP_NODELAY set
- Connected to localhost (127.0.0.1) port 5821 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:5821
- stopped the pause stream!
- Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:5821
Seems to be the TLS handshake.
Andrea
And, here is more info ... openssl s_client -cipher ALL -connect localhost:5821
CONNECTED(00000005)
write:errno=0
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 405 bytes
Verification: OK
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Also, I have to use a self-signed cert. When I connect to the server using Studio, I can connect using http:. But, when I use https:, and indicate in advanced options that I have a self-signed cert, the connection is still refused.
Andrea
What version JRE are you using? There was a bug submitted for OpenJDK that may be related to this problem
https://bugs.openjdk.java.net/browse/JDK-8210846
Running ....
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~18.04-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)