Filebeat ssl connection fail with CERT using Subject Alternative Name

Elastic Stack Beats
1

Hello. I am using filebeat version 1.2.1 (amd64).
I've setup logstash with input beats and ssl (ssl_verify_mode => force_peer) and self signed certificate containing additional Subject Alternative Name.
I am able to connect wi

I can connect fine from host using
from host connecting via
#filebeat.yml part output: logstash: hosts: ["<DNS ALT NAME>:5000"] tls: insecure: false
but connections via
#filebeat.yml part output: logstash: hosts: ["<CN field from cert>:5000"] tls: insecure: false
fail with:
2016/04/18 07:19:31.624512 transport.go:125: ERR SSL client failed to connect with: x509: certificate is valid for <DNS ALT NAME>, not <CN field from cert>

Is this a bug or it's just not implemented and I missed some FAQ/doc?

2

certificates are signed for domain names. When setting insecure: false (default), certificates will be validated + domain name is compared with certificate. Setting insecure: true should disable the domain name check (not recommended due to potential man-in-the-middle attacks).

3

I've implicitly turn on tls in config (certificate_authorities, certificate, certificate_keyca) and set "insecure: false" as I want only to preceed with connection when both server and client are validated via x509.

What I am saying is that filebeats (client) is denying to connect to server presenting valid certifitacte (it only validates against SubjectAltName skipping CN)

I checked connectivity with openssl s_client and cert IS valid for both for both STRINGS (one in CN other via SubjectAltName type DNS)

I think it is bug in filebeats.
I was able to overcome this by adding sime value as CN to additional SubjectAltName
So my cert has now
CN = X
SubjectAltName = X
SubjectAltName = Y
and only now I can connect via both X,Y

4

Just because it works with OpenSSL I wouldn't treat this as a bug in go libs. This stackoverflow post is very helpful on this matter (RFCs are quite hard to read): http://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together

5

OMG. I bought/used quite a few "SSL" certs and was quite sure I know what I am speaking about but you just wrecked me :slight_smile:
No more questions / thank you for fast answer and pointing me to more info.