Has anyone been able to successfully configure ssl on DSE 6+. Specifically for DSE Graph?
This question was
closed
by
Erick Ramirez for the following reason: The question is answered, right answer was accepted
How do you configure the Gremlin console to connect to an SSL-enabled cluster?
@scano_183208 Lots of users and customers have been using SSL with DSE Graph for a number of years. Let us know if you have any specific items you would like to know more about. Cheers!
Hi Erick, for starters how does the remote.yaml file work? When setting the SSL option to true what SSL configuration does it use? Is it the one that is set up in the Cassandra.yaml file?
I keep getting an SSL handshake error when I follow the steps in the guide (these involves creating local files aka trust store key store, keys, CA, etc.) then client to node and node to node configurations.
@scano_183208 Configure client SSL in remote.yaml for the Gremlin console (it is a client app). The SSL configuration in cassandra.yaml is for setting SSL properties on the server. Cheers!
My issue is that the document you sent me does not reflect the same settings that are in DSE 6.7 remote.yaml file.
For example : when I attempt t use the trustchain attribute it tells me it has been deprecated. Also, I am having issues creating trsutstore and keystore. I followed the steps but it did not work for me.
My apologies for providing you the document for DSE 5.1. This is the page for DSE 6.7.
Can you tell me what errors you are getting? Please place outputs in https://gist.github.com/ or another location since comments are limited to 400 characters. Cheers!
@scano_183208 In response to your followup questions, I've generated self-signed certificates locally following the steps in DSE 6.7 Creating local SSL certificate and keystore files.
I've used the keystore and truststore files I've created to enable client-to-node encryption on the DSE nodes. To validate that SSL is working, I've used the root certificate (rootca.crt) to connect to SSL-enabled nodes with cqlsh. For example, on node with IP 10.101.35.27:
$ export SSL_CERTFILE="/path/to/rootca.crt" $ cqlsh --ssl 10.101.35.27
After confirming that client-to-node encryption is setup correctly, I have configured Gremlin console to use SSL with the same PEM file (signing_request.crt_signed) from when I generated the certificates. Here is my complete remote.yaml:
hosts: [10.101.35.27]
port: 8182
serializer: { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV3d0,
config: { serializeResultToString: true, ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerIoRegistryV3d0] }}
connectionPool: {
enableSsl: true,
maxContentLength: 65536000,
maxInProcessPerConnection: 4,
maxSimultaneousUsagePerConnection: 16,
maxSize: 8,
maxWaitForConnection: 3000,
maxWaitForSessionClose: 3000,
minInProcessPerConnection: 1,
minSimultaneousUsagePerConnection: 8,
minSize: 2,
reconnectInterval: 1000,
resultIterationBatchSize: 64,
trustCertChainFile: /path/to/signing_request.crt_signed
}
Here's the output from my test connection:
$ dse gremlin-console 10.101.35.27:8182
...
gremlin> system.graph('test').create()
==>null
gremlin> system.graphs()
==>test
I can also see in the system.log that my connection to the server was successful:
INFO [gremlin-server-worker-1] 2020-01-23 20:08:16,951 GREMLIN Session.java:93 - New session established for 9c1c9069-e371-44cd-bde0-4f22153b62b
Without configuring SSL with a valid trustCertChainFile, you would see an error like this in system.log :
WARN [gremlin-server-worker-2] 2020-01-23 20:04:00,005 Slf4JLogger.java:151 - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 474554202f6772656d6c696e20485454502f312e310d0a757067726164653a20776562736f636b65740d0a636f6e6e656374696f6e3a20757067726164650d0a7365632d776562736f636b65742d6b65793a204f7a71644947686d586e703456732f514f39647a2b673d3d0d0a686f73743a206772656d6c696e2d362e372d73736c2d657269636b2e6473696e7465726e616c2e6f72673a383138320d0a7365632d776562736f636b65742d6f726967696e3a20687474703a2f2f6772656d6c696e2d362e372d73736c2d657269636b2e6473696e7465726e616c2e6f72673a383138320d0a7365632d776562736f636b65742d76657273696f6e3a2031330d0a0d0a
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:459)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:647)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:582)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:499)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:461)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)
at java.lang.Thread.run(Thread.java:748)
Caused by: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 474554202f6772656d6c696e20485454502f312e310d0a757067726164653a20776562736f636b65740d0a636f6e6e656374696f6e3a20757067726164650d0a7365632d776562736f636b65742d6b65793a204f7a71644947686d586e703456732f514f39647a2b673d3d0d0a686f73743a206772656d6c696e2d362e372d73736c2d657269636b2e6473696e7465726e616c2e6f72673a383138320d0a7365632d776562736f636b65742d6f726967696e3a20687474703a2f2f6772656d6c696e2d362e372d73736c2d657269636b2e6473696e7465726e616c2e6f72673a383138320d0a7365632d776562736f636b65742d76657273696f6e3a2031330d0a0d0a
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1156)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1221)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
Let me know how you go. Cheers!
Thank you! I will give this a try.
When I try to import the signed certificate into the keystore it says certificate has been installed not certificate has been added is this okay?
If possibly could we see the steps you took when creating these certs, keystores, and truststores?
By steps I really mean the information you put into the fields when following the doc. It would be very beneficial. Thank you Erick!
I had a single-node cluster to make it simple. The exact commands I ran on the one node are available here.
You'll see that the passwords I used were either keystore_password or truststore_password. Those are not variables but literal strings. Cheers!
Yes, the outputs of each command are slightly changed so it's OK as long as you didn't get any errors. Cheers!
How would the configuration change in a 3 node cluster. Should I create all key stores under one node (make the cn for the certs whatever the Domain name is based of of the host name) and then distribute them to the other nodes? Then create a generic trust store and distribute it across the nodes?
3 People are following this question.
