[mTLS][filebeat-logstash][beat-input-plugin] Client certificate hostname verification

Dear All,

I'm trying to set up mTLS between filebeat (client) and logstash (server).
I refer to the documents
Secure communication with Logstash | Filebeat Reference [7.14] | Elastic

Filebeat config:

output.logstash:
  hosts: ["logs.mycompany.com:5044"]
  ssl.certificate_authorities: ["/etc/ca.crt"]
  ssl.certificate: "/etc/client.crt"
  ssl.key: "/etc/client.key"

Logstash config:

input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate_authorities => ["/etc/ca.crt"]
    ssl_certificate => "/etc/server.crt"
    ssl_key => "/etc/server.key"
    ssl_verify_mode => "force_peer"
  }
}

After setup and test, I observed if I installed a wrong client certificate (Common Name's different with Client Hostname i.e. Common Name: xxxxfilebeat.abc.com while Client Hostname:filebeat.abc.com) but signed by trusted CA, mTLS connection can successfully be set up.

It seems that server's not verify client certificate hostname.
Could you please kindly hint me how to set beat input plugin if server is requested to verify client certificate hostname?

Moreover, for filebeat rather than beat input plugin, it can be configurated by verification mode set to full (Configure SSL | Filebeat Reference [7.14] | Elastic).

Thank you.

The host name verification is only one way. The client verifies the server certificate is trusted and the SAN/common name matches the address used to connect to it. The server then verifies the client cert is trusted. It has no way of validating the hostname of the client. In some mtls scenarios where there is also a username/pass, the server will validate the client cert matches the username.

Thank you so much for your reply.

If filebeat (client) and logstash (server), how to set that the server validates whether the client certificate matches the username? Moreover, what steps are set when server validates client certificate? CA? Validation periods? Will server check client Signatures?

Will client hostname validation's considered in future beat input plugin release?

There is no username/password for beats to logstash, just client cert.

What do you mean? The CA u provide logstash is what validates if a client cert is trusted.

This is not part of the TLS spec and I don't believe it will ever be. The server has no way of knowing the hostname of the client.

Thank you so much.

This is not part of the TLS spec and I don't believe it will ever be. The server has no way of knowing the hostname of the client.

Client hostname verification's designed in filebeat. However, it's removed from beats input plugin. Could you please kindly hint me the reasons? I felt confused and that's why I ask whether there's a plan to add additional client hostname verification in the future.

Configure SSL | Filebeat Reference [7.14] | Elastic

verification_mode
Controls the verification of client certificates. Valid values are:
full
Verifies that the provided certificate is signed by a trusted authority (CA) and also verifies that the server’s hostname (or IP address) matches the names identified within the certificate.

Beats input plugin | Logstash Reference [7.14] | Elastic

ssl_verify_mode
1.Value can be any of: none , peer , force_peer
2.Default value is "none"
By default the server doesn’t do any client verification.
peer will make the server ask the client to provide a certificate. If the client provides a certificate, it will be validated.
force_peer will make the server ask the client to provide a certificate. If the client doesn’t provide a certificate, the connection will be closed.
This option needs to be used with ssl_certificate_authorities and a defined list of CAs.

The verification that logstash is talking about is validating that the client cert is signed by a trusted CA. Filebeat can do hostname verification because it's what is initiating the connection to the logstash sever so it can verify that the cert is trusted and that the SANS/CN matches the address that it's trying to connect to.

I don't know what you mean here.

Thank you so much for your reply^^.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.