# Winlogbeat Kafka output not reading SSL certs with "wrong" line ends

**URL:** <https://discuss.elastic.co/t/winlogbeat-kafka-output-not-reading-ssl-certs-with-wrong-line-ends/385257>\
**Category:** Beats\
**Tags:** winlogbeat\
**Created:** [February 26, 2026, 7:01pm UTC](https://discuss.elastic.co/t/winlogbeat-kafka-output-not-reading-ssl-certs-with-wrong-line-ends/385257 "2026-02-26T19:01:57Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ciranor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ciranor/32/147015_2.png) [@ciranor](https://discuss.elastic.co/u/ciranor)\
**Post date:** [February 26, 2026, 7:01pm UTC](https://discuss.elastic.co/t/winlogbeat-kafka-output-not-reading-ssl-certs-with-wrong-line-ends/385257/1 "2026-02-26T19:01:57Z")

</div>

I’m setting up Winlogbeat to output to Kafka with SSL certificates used to authenticate. The certificates will be generated, rotated and supplied automatically by another system. But when trying to configure it, `winlogbeat test config` fails if the files have unix line ends.

```auto
output.kafka:
  enabled: true
  hosts: ["example.com:9093"]
  topic: dummy-topic
  ssl:
    certificate: C:/users/simon/downloads/simon.unix.pem
    key: C:/users/simon/downloads/simon.unix.key
 

```

This throws an error:

```auto
Exiting: error initializing publisher: 1 error: no pem file C:/users/simon/downloads/simon.unix.pem

```

But if I replace the files with identical ones with Windows line ends it works fine.

```auto
get-content .\simon.unix.key | set-content simon.windows.key
get-content .\simon.unix.pem | set-content simon.windows.pem
# Update file names in config file
winlogbeat test config
Config OK

```

Is this expected behaviour? I would have expected it to happily read certificate files with either sort of line ends.

---

<div class="post-metadata">

**Author:** ![Rios](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rios/32/95745_2.png) [@Rios](https://discuss.elastic.co/u/Rios)\
**Post date:** [February 26, 2026, 9:00pm UTC](https://discuss.elastic.co/t/winlogbeat-kafka-output-not-reading-ssl-certs-with-wrong-line-ends/385257/2 "2026-02-26T21:00:20Z")

</div>

Does the user has right to access to pem and key.  
Did you ran as a process or a service?

Why don't use the backslashes?

```
certificate: C:\users\simon\downloads\simon.unix.pem
key: C:\users\simon\downloads\simon.unix.key

```

---

<div class="post-metadata">

**Author:** ![ciranor](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ciranor/32/147015_2.png) [@ciranor](https://discuss.elastic.co/u/ciranor)\
**Post date:** [February 26, 2026, 10:44pm UTC](https://discuss.elastic.co/t/winlogbeat-kafka-output-not-reading-ssl-certs-with-wrong-line-ends/385257/3 "2026-02-26T22:44:44Z")

</div>

It generally doesn’t make much of a difference these days about which slashes you use in Windows, as most utilities seem to accept either.

But while gathering data to indicate that it wasn’t any of the things you’d suggested, I ran the 2 `simon.unix.*` files through a hexdump, and noticed that the pair of them have somehow got 3 non-visible non-ASCII bytes at the very start of the files, which had actually also been stripped out while doing the `get-content | set-content` fixing up of line ends.

Removing those non-ASCII bytes from the files, the config test then actually works fine, with either unix or windows line ends in the certificates.

So the issue’s identified, and it’s nothing to do with the Kafka output. Sorry for the noise.

---

<div class="post-metadata">

**Author:** ![Rios](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rios/32/95745_2.png) [@Rios](https://discuss.elastic.co/u/Rios)\
**Post date:** [February 27, 2026, 10:41am UTC](https://discuss.elastic.co/t/winlogbeat-kafka-output-not-reading-ssl-certs-with-wrong-line-ends/385257/4 "2026-02-27T10:41:24Z")

</div>

You should see spec characters in Notepad++, View -\>Show Symbol-\>Show All Characters.

Anyway, we are glad to hear that the problem has been resolved.