Join GitHub today
Meaningless error message: bad header found ... #429
openjdk version "1.8.0_151"
When running two elasticsearch nodes for the very first time after installation, the following error is thrown:
This message is thrown when SSLRequestHelper.containsBadHeader() returns true, but contains nothing useful that would pin down the cause of the message.
The message contains the weasel words "typically".
The message makes reference to a "non node certificate" without explicitly defining what a "non node certificate" means.
The message says that the certificate might have no OID without the OID being specified in the error message.
The message says the searchguard.nodes_dn setting might be incorrectly configured, but does not say what kind of misconfiguration has occurred. If "misconfiguration" actually meant "mismatch", the error did not print the DN of the certificate presented (as opposed to the DN of the certificate the admin thinks they presented).
The message links to the full TLS documentation URL https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_certificates.md, which is too vague to be of any use. Obviously this part of the manual has been followed, or this error message would never appear.
To fix this, the following code needs to be fixed to include proper error handling:
This specific code needs to be fixed so that the "key" and the "prefix" are properly described in the error message, so that the admin can take some kind of meaningful action:
As it stands, you need blind luck to configure TLS - put one foot wrong and the entire server comes crashing down with no explanation.
Further testing shows more meaningless error messages in the log on server B when elasticsearch is restarted on server A.
None of these logged messages tell us what the error is:
[2017-12-18T22:43:10,562][ERROR][c.f.s.t.SearchGuardRequestHandler] Error validating headers
ssldump picks up the following, which seems to show a successfully negotiated TLS connection.
Starting program: /usr/sbin/ssldump port 9300
I would happily submit a PR, but to do so I need to understand more about what this code is trying to do.
What is a "header" in this context, and what makes it "bad"?
What is the significance of the prefix "sg_ssl", and why would this error be triggered if this prefix is somehow present?
Looking at the history of this code, it looks like an attempt was made to explain the bad header message here:
Unfortunately the explanation makes no sense to me, as an admin I need concrete steps that I need to take to make this work, but I am mystified as to what those steps are.
Are you able to explain the significance of what makes a header bad? It seems you've received a header that starts with sg_ssl*, but there is nothing to explain why this would be a bad thing.
Would it be possible to confirm?
Following the advice in the following thread:
Setting as follows avoids the error:
The original value was:
To start with, the error message needs to include the subject of the certificate, so it is clear what is being matched. At the moment it's a shot in the dark.
The next problem is wildcard handling - are multiple wildcards handled in a string, or does the wildcard handling only support wildcards under certain conditions?