Getting Data In

OKTA TLS requires TLS/cipher

youngsuh
Path Finder

“BLUF: Looks like a TLS/cipher problem in addition to ca_bundel. I was able to connect without errors after specifying the ca_bundle file and explicitly specifying TLS version and ciphers.”

I'd then modified inputs.conf

 

[SSL]
cipherSuite = ecdhe-rsa-aes-128-gcm-sha-256

 

In addition, I'd added ca_bundel $splunk home dir%/etc/auth/

I am still getting SSL error.  Any idea how to get around getting the input working?

Tags (4)
0 Karma
1 Solution

youngsuh
Path Finder

We were using the beta version but, decided to upgrade to latest and greatest.  The latest greatest pervious version had malformed URL issue with the proxy.  But, the current version doesn't have the issue and support the cipher without configuration.  Looks like OKTA notice the issue and resolved.  Thanks for you feedback.

Here are the version for reference for others:  v 2.25.11 beta release

one with the malformed URL using proxy:  2.25.17

Working version with malformed URL & Proxy:  2.25.19  (works with DoD)

View solution in original post

Tags (1)
0 Karma

tscroggins
Builder

@youngsuh 

Assuming the cipher is the problem, try ECDHE-RSA-AES128-GCM-SHA256 (uppercase, no hyphen between AES and 128).

For Splunk-to-Okta connections, you can use https://www.ssllabs.com/ssltest/index.html to easily see which ciphers your okta.com endpoint advertises.

For example, their AWS US West services support TLS 1.2 and the following ciphers (in this order with IANA names):

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA

The default inputs.conf SSL cipherSuite value already contains supported ciphers (with OpenSSL names):

cipherSuite = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

That said, I'm not sure what you're trying to do. inputs.conf controls inbound connections, not outbound connections. Do you have an Okta service trying to push data to a Splunk instance rather than a Splunk add-on pulling data from Okta?

youngsuh
Path Finder

Q: Do you have an OKTA service trying to push data to a Splunk instance rather than a Splunk add-on pulling data fromOKTA? 

A: We're using the add-on to pull data.  We have a CIPHER issue via CURL.  I'd try the upper case with no luck in the inputs.conf.  We're not pushing data into OKTA.  I know that it's a CIPHER issue because CURL doesn't work without the CIPHER arg.   We're getting ssl.c:742 via Okta add-on.

Q:  Should I input all the CIPHER you listed into inputs.conf?

0 Karma

tscroggins
Builder

@youngsuh 

Which add-on are you using? There's more than one on Splunkbase. If you're using Okta Identity Cloud Add-on for Splunk, this issue is in the Okta add-on itself, not Splunk. You'll need to contact Okta directly. They may provide support for the add-on.

0 Karma

youngsuh
Path Finder

We were using the beta version but, decided to upgrade to latest and greatest.  The latest greatest pervious version had malformed URL issue with the proxy.  But, the current version doesn't have the issue and support the cipher without configuration.  Looks like OKTA notice the issue and resolved.  Thanks for you feedback.

Here are the version for reference for others:  v 2.25.11 beta release

one with the malformed URL using proxy:  2.25.17

Working version with malformed URL & Proxy:  2.25.19  (works with DoD)

View solution in original post

Tags (1)
0 Karma
.conf21 CFS Extended through 5/20!

Don't miss your chance
to share your Splunk
wisdom in-person or
virtually at .conf21!

Call for Speakers has
been extended through
Thursday, 5/20!