http tls: expected host name is not properly set

[eldargab]

Bug Report

Consider the following setup

[OUTPUT]
    Name  http
    Match *
    Host some_ip_address
    Port 8443
    tls on
    tls.ca_file /path/to/ca.crt
    ...

Output fails with

[2019/12/08 11:29:27] [error] [io_tls] flb_io_tls.c:355 X509 - Certificate verification failed, e.g. CRL, CA or signature check

As a workaround you can explicitly specify tls.vhost

[OUTPUT]
    Name  http
    Match *
    Host some_ip_address
    Port 8443
    tls on
    tls.vhost some_ip_address:8443
    tls.ca_file /path/to/ca.crt
    ...

This works, but it should work without explicit tls.vhost as well.

Your Environment

• Version used: Fluent Bit v1.3.3

[edsiper]

@eldargab thanks for opening this ticket.

do you mean that by default we should always set the SNI (tls.vhost) to the original host and port in use ?

@fujimotos what do you think ?

[fujimotos]

@edsiper @eldargab I actually can confirm that Fluent Bit is able
to connect to HTTP servers without tls.vhost on such a setup.

I generated a certificate with the following chain.

 0 s:C = JP, ST = Tokyo, O = Fluent Bit, CN = 127.0.0.1
   i:C = JP, ST = Tokyo, O = Fluent Bit, CN = 127.0.0.1

and I launched Fluent Bit as follows:

$ fluent-bit -i dummy -o http -p Host=127.0.0.1 -p Port=8000 \
             -p tls=On -p tls.ca_file=fluent.crt
...
[2019/12/11 11:23:48] [ info] [out_http] 127.0.0.1:8000, HTTP status=200

So Fluent Bit is able to post data via TLS and is getting 200 responses.

This works, but it should work without explicit tls.vhost as well.

My guess is that the certificate has a port number in its CN field,
and this is the root cause of the issue.

@eldargab Can you check your certificate using the folloing command and
see if it is actually the case?

$ openssl s_client -showcerts -connect some_ip_address:8443

[eldargab]

Yes, CN contains port number. Didn't know that it is not a common practice.

What confused me is that

openssl s_client -verify 1 -connect some_ip:8443 -CAfile server.crt -verify_return_error

connects without an error.

[fujimotos]

@eldargab It seems that openssl won't do any hostname verification by default.
We needed to use -verify_hostname to make it happen.

$ openssl s_client -verify_hostname 127.0.0.1 -connect 127.0.0.1:8000 -CAfile fluent.crt 
...
Verification error: Hostname mismatch

From another angle, HTTP clients such as curl and wget complain if our
cert contains a port number. For example:

$ curl --cacert fluent.crt  https://127.0.0.1:8000/
curl: (60) SSL: certificate subject name '127.0.0.1:8000' does not
match target host name '127.0.0.1'

So I believe a certificate verification should fail in such a case.

Yes, CN contains port number. Didn't know that it is not a common practice.

My understanding here is that the Common Name field has no concept of
"port number" at all.

So if we set 127.0.0.1:8000 to CN, it actually means "the server should
have '127.0.0.1:8000' as its hostname".

That may happen to work, but it's literally a "happen to work because SSL
libraries happen to accept an arbitrary string as CN, even if it is not a valid
hostname", not a design thing.

[eldargab]

@fujimotos, thank you for clarification!