SSL error connecting to Stardog

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)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.