Quantcast
Channel: Questions in topic: "ssl"
Viewing all articles
Browse latest Browse all 425

Custom SSL certificate for deployment server SSLCommonNameToCheck

$
0
0
I am trying to troubleshoot where my issue lies in implementing my own SSL certificates to secure the deployment server to client configuration. DS server.conf: [sslConfig] caCertFile = cacert.crt caPath = $SPLUNK_HOME/etc/auth/myOrg requireClientCert = false sslKeysfile = splunk-ds.ser.cer sslKeysfilePassword = sslVersions = tls, -tls1.0 Client server.conf: [sslConfig] caCertFile = cacert.crt caPath = $SPLUNK_HOME/etc/apps/config_uf/auth sslKeysfile = splunk-uf.ser.cer sslKeysfilePassword = sslVersions = tls, -tls1.0 sslVerifyServerCert = true sslCommonNameToCheck = splunk-ds.myorg.com Now, it should be noted that my client is connecting to the deployment server by hostname, whereas the common name of the certificate is a DNS name. I have the FQDN listed under the Subject Alternative Name, and according to the documentation for 6.3 you cannot use the SAN list for deployment servers to client communication (I haven't tested this to see if it really doesn't work, that will be my next step). What I am asking for is if there is a better way to troubleshoot the issue because the splunkd.log is entirely unhelpful as to the issue since this is all it is telling me from the client side: 11-18-2015 14:02:02.132 -0500 INFO DC:DeploymentClient - channel=tenantService/handshake Will retry sending handshake message to DS; err=not_connected I have only done this to one of my clients, but I can't exactly sift through my deployment server logs very easily since there are over 12,000 systems hitting it. Any pointers? The common name provided in the client data IS the common name of the certificate used, it just isn't the hostname of the system. Edit: It looks like this is all I can see from the Deployment Server right after it sends all the successful messages stating that the downloaded updates were completed you see a reset of the connection (due to the forwarder restarting) and then this: 11-18-2015 13:34:16.773 -0500 WARN HttpListener - Socket error from 10.10.175.64: Connection reset by peer 11-18-2015 14:01:38.920 -0500 WARN HttpListener - Connection from 10.10.175.64 didn't send us any data, disconnecting 11-18-2015 14:03:25.709 -0500 WARN HttpListener - Connection from 10.10.175.64 didn't send us any data, disconnecting It is very odd that it takes a 30 minutes before it complains about not receiving any data, I get two messages, and then nothing further beyond that. This is also very unhelpful logs to identify the underlying issue.

Viewing all articles
Browse latest Browse all 425

Trending Articles