sg_config.yml (the only thing I believe I changed was the authc section):
searchguard:
dynamic:
http:
anonymous_auth_enabled: false
xff:
enabled: false
internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern
remoteIpHeader: ‘x-forwarded-for’
proxiesHeader: ‘x-forwarded-by’
authc:
sic_internal_auth_domain:
enabled: true
order: 1
http_authenticator:
type: basic
challenge: true
authentication_backend:
type: internal
clientcert_auth_domain:
enabled: true
order: 0
http_authenticator:
type: clientcert
config:
username_attribute: CN=demouser
challenge: false
authentication_backend:
type: noop
authz:
roles_from_myldap:
http_enabled: false
transport_enabled: false
authorization_backend:
config:
enable_ssl: false
enable_start_tls: false
enable_ssl_client_auth: false
verify_hostnames: true
hosts:
bind_dn: null
password: null
rolebase: ‘ou=groups,dc=example,dc=com’
rolesearch: ‘(member={0})’
userroleattribute: null
userrolename: disabled
rolename: cn
resolve_nested_roles: true
userbase: ‘ou=people,dc=example,dc=com’
usersearch: ‘(uid={0})’
roles_from_another_ldap:
enabled: false
authorization_backend:
type: ldap # NOT FREE FOR COMMERCIAL USE
In my elasticsearch.yml I have searchguard.ssl.http.clientauth_mode: OPTIONAL
The only logfile that changes after I set the tls-logging instructions and issue curl is elasticsearch.log
I have attached the entire file, the only thing that is logged when I run the curl command is
[2018-07-11T09:16:33,110][DEBUG][c.f.s.a.BackendRegistry ] Try to extract auth creds from basic http authenticator
``
I hope this helps. Once again, thank you so much for your time and effort! Great support for this product.
elasticsearch.log (34.1 KB)
···
On Tuesday, July 10, 2018 at 4:32:33 PM UTC-4, Jochen Kressin wrote:
So from the output it seems that you also run an HTTP Basic authentication domain. That’s where the WWW-Authenticate: Basic realm=“Search Guard” comes from. And it also shows that the “challenge” flag in this authentication domain is set to true.
Can you please post the full content of your sg_config.yml here?
For a quick check:
- Make sure that the client cert authentication domain comes first in the chain (order: 0)
- If you also need Basic Authentication, this should come second (order: 1)
The check if you enabled TLS client certificates on HTTP level in elasticsearch.yml:
searchguard.ssl.http.clientauth_mode: OPTIONAL
``
If this is all correct, please set the log level to debug by following these instructions:
https://docs.search-guard.com/latest/troubleshooting-tls
Then restart Elasticsearch, issue the curl call again, and post the ES logfiles.
On Tuesday, July 10, 2018 at 3:34:59 PM UTC+2, Alexander Villamar wrote:
Maybe my issue is in how I am trying to access the cluster via curl?
I first tried to convert the key file to jkcs #8 as I saw somewhere that the key may not be in that format. I issued this command:
“openssl pkcs8 -topk8 -in demouser.key.pem -out demouser.key -nocrypt”
I then verified that the new key requires no password and matches the old one.
I then issued the curl command:
curl -vk --cert ./demouser.crtfull.pem --key ./demouser.key “https://localhost:9200”
and got this output:
- About to connect() to localhost port 9200 (#0)
- Connected to localhost (::1) port 9200 (#0)
- Initializing NSS with certpath: sql:/etc/pki/nssdb
- skipping SSL peer certificate verification
- NSS: client certificate from file
- SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:9200
Accept: /
< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: Basic realm=“Search Guard”
< content-type: text/plain; charset=UTF-8
< content-length: 12
<
- Connection #0 to host localhost left intact
Unauthorized
On Monday, July 9, 2018 at 6:03:00 PM UTC-4, Jochen Kressin wrote:
Hm, your mapping seems correct. For certificate-based authentication, the username is the DN of the certificate so ‘CN=demouser’ would be the right one.
If you use certificate-based authentication, the internal_users.yml is not really relevant, and therefore also the user attributes entries are not relevant. The general process for cert based auth is like:
- Receive the client TLS certificate from the HTTP request (dependant on the ‘searchguard.ssl.http.clientauth_mode’ setting, can be NONE, OPTIONAL or REQUIRED)
- Validate the certificate
- Map the DN of the certificate to Search Guard roles
On Monday, July 9, 2018 at 3:08:07 PM UTC+2, Alexander Villamar wrote:
sg and es versions: 6.3.0
openjdk 1.8.0_171
So I am trying to set up TLS on my cluster. I currently have my single node cluster running using the truststore and keystore files provided with the online cert generator. I am now trying to use the demouser certificates also provided to access the cluster through curl. I tried to follow the documentation to set up client cert authentication. Within sg_config.yml I have this:
clientcert_auth_domain:
enabled: true
order: 0
http_authenticator:
type: clientcert
config:
username_attribute: demouse
challenge: false
authentication_backend:
type: noop
Now, I am not 100% sure what to actually put in the username_attribute field. In my sg_roles_mapping.yml I have this:
sg_role_starfleet:
users:
backendroles:
I am also not sure what to put in for users. The name of my certificate and key that I am trying to get sg to authorize are demouser.crtfull.pem and demouser.key.pem. Using openssl x509 shell command on the certificate file I get this:
"Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=zeta, OU=zeta Signing CA, CN=zeta Signing CA
Validity
Not Before: Jul 3 13:03:52 2018 GMT
Not After : Jul 2 13:03:52 2020 GMT
Subject: CN=demouser
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus: (more here but not important)"
I am just confused as how I can get searchguard to authenticate this certificate and key pair.
Thanks