# Logstash beat force\_peer authentication doesn't check hostname info

**URL:** <https://discuss.elastic.co/t/logstash-beat-force-peer-authentication-doesnt-check-hostname-info/229683>\
**Category:** Logstash\
**Created:** [April 24, 2020, 3:34pm UTC](https://discuss.elastic.co/t/logstash-beat-force-peer-authentication-doesnt-check-hostname-info/229683 "2020-04-24T15:34:23Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![iorfix](https://avatars.discourse-cdn.com/v4/letter/i/9fc348/32.png) [@iorfix](https://discuss.elastic.co/u/iorfix)\
**Post date:** [April 24, 2020, 3:34pm UTC](https://discuss.elastic.co/t/logstash-beat-force-peer-authentication-doesnt-check-hostname-info/229683/1 "2020-04-24T15:34:24Z")

</div>

Hi there,  
I'm trying to force mutual authentication between Beats and Logstash.  
However, while beats correctly check logstash hostname before sending data, looking at _subject_ or at _dns_ list, the same doesn't happen on logstash when validating beats certificates.  
Logstash verifies the correctness of the certificate (expiration date, CA issuer), but doesn't check correspondence between agent hostname and _subject_ or _dns_ certificate info.  
So, for example, a client certificate issued to [foo.beat.com](http://foo.beat.com) is considered valid when used by hostname [foo.beat.com](http://foo.beat.com) (correct) or by hostname [bar.logstash.co.uk](http://bar.logstash.co.uk) (wrong).

I set all ssl values at "maximum", these are the relevant section of configuration files (version 7.6.2):

### Beat config

```auto
output.logstash:
  hosts: ["logstash.example.com:5044"]
  ssl.certificate_authorities: ["/path/cert/ca.pem"]
  ssl.verification_mode: full
  protocol: "https"

  ssl.certificate: "/usr/share/metricbeat/cert/cert1.pem"
  ssl.key: "/usr/share/metricbeat/cert/cert1.key"

```

### Logstash config

```auto
input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate => "/etc/logstash/cert/logstash.crt"
    ssl_certificate_authorities => ["/etc/logstash/cert/ca.pem"]
    ssl_key => "/etc/logstash/cert/logstash_pkcs8.key"
    ssl_verify_mode => "force_peer"
    ssl_peer_metadata => true
  }
}

```

Is there any way to force this additional check?

---

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [April 24, 2020, 4:30pm UTC](https://discuss.elastic.co/t/logstash-beat-force-peer-authentication-doesnt-check-hostname-info/229683/2 "2020-04-24T16:30:49Z")

</div>

> [@iorfix](#):
>
> a client certificate issued to [foo.beat.com](http://foo.beat.com) is considered valid when used by hostname [foo.beat.com](http://foo.beat.com) (correct) or by hostname [bar.logstash.co.uk](http://bar.logstash.co.uk) (wrong).

I have never seen any system that does name matching on client certificates. I do not believe logstash will do it.

---

<div class="post-metadata">

**Author:** ![iorfix](https://avatars.discourse-cdn.com/v4/letter/i/9fc348/32.png) [@iorfix](https://discuss.elastic.co/u/iorfix)\
**Post date:** [April 27, 2020, 6:10am UTC](https://discuss.elastic.co/t/logstash-beat-force-peer-authentication-doesnt-check-hostname-info/229683/3 "2020-04-27T06:10:09Z")

</div>

Hi Badger, thank you for the reply.  
I'd like to have an additional _ssl\_verify\_mode_ to add this behaviour (_strong\_peer_), even if I agree with you it is not common to check for client hostname.  
As an alternative, it would be also good to add DNS info in _ssl\_peer\_metadata_, to perform the check directly in Logstash pipeline.  
Do you think is it possible?  
Regards,  
Dario

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 25, 2020, 6:14am UTC](https://discuss.elastic.co/t/logstash-beat-force-peer-authentication-doesnt-check-hostname-info/229683/4 "2020-05-25T06:14:15Z")

</div>

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