Fluentd does not support certificate chains #2699
Labels
Comments
Closed
facebook-github-bot
pushed a commit
to magma/magma
that referenced
this issue
Nov 19, 2019
…controller (#890) Summary: Pull Request resolved: #890 - For some reason, fluentd's TLS plugin can't seem to handle legit digicert x.509 version 3 certificates: ``` $ openssl s_client -showcerts -connect hostname:24224 -debug CONNECTED(00000005) write to 0x7f9e7d800080 [0x7f9e7e00a803] (200 bytes => 200 (0xC8)) 0000 - 16 03 01 00 c3 01 00 00-bf 03 03 d2 df fa 28 86 ..............(. 0010 - be 3b 24 95 05 27 d3 94-7a 53 c0 91 01 94 77 7e .;$..'..zS....w~ 0020 - 0d be 81 1b 49 8f a8 2f-1f 02 82 00 00 60 c0 30 ....I../.....`.0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 9f 00 6b 00 39 .,.(.$.......k.9 0040 - cc a9 cc a8 cc aa ff 85-00 c4 00 88 00 81 00 9d ................ 0050 - 00 3d 00 35 00 c0 00 84-c0 2f c0 2b c0 27 c0 23 .=.5...../.+.'.# 0060 - c0 13 c0 09 00 9e 00 67-00 33 00 be 00 45 00 9c .......g.3...E.. 0070 - 00 3c 00 2f 00 ba 00 41-c0 11 c0 07 00 05 00 04 .<./...A........ 0080 - c0 12 c0 08 00 16 00 0a-00 15 00 09 00 ff 01 00 ................ 0090 - 00 36 00 0b 00 02 01 00-00 0a 00 08 00 06 00 1d .6.............. 00a0 - 00 17 00 18 00 23 00 00-00 0d 00 1c 00 1a 06 01 .....#.......... 00b0 - 06 03 ef ef 05 01 05 03-04 01 04 03 ee ee ed ed ................ 00c0 - 03 01 03 03 02 01 02 03- ........ read from 0x7f9e7d800080 [0x7f9e7e006603] (5 bytes => 5 (0x5)) 0000 - 15 03 03 00 02 ..... read from 0x7f9e7d800080 [0x7f9e7e006608] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 4701910636:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL alert number 40 4701910636:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:585: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Start Time: 1573808339 Timeout : 7200 (sec) Verify return code: 0 (ok) --- ``` - Note the SSL record above comes back immediately with type 0x15 (SSL3_RT_ALERT), which means that the server is unable to proceed with the handshake after the client's hello packet (the 200 bytes written). This is possibly related to fluent/fluentd#2699 - This is reproducible with both a chained cert file from digicert and just the leaf cert by itself. Specifying a `-servername` parameter for SNI doesn't solve anything in either case. - However, if we use an x.509 version 1 cert signed by a self-signed root CA, fluentd is able to negotiate the SSL/TLS handshake successfully - Since we aren't validating TLS in the fluent-bit config, the fact that the rootCA on the gateway won't validate the SSL cert provided by the server won't matter, so we can safely use the self-signed cert. We really just care that the traffic is TLS-encrypted and TLS mutual authentication happens using the controller's certifier CAcert. - So instead of re-using the controller.crt/controller.key legit SSL certs, use fluentd.pem/fluentd.key for the forwarder pod Reviewed By: Scott8440 Differential Revision: D18543114 fbshipit-source-id: e0d636fd725de990276da0c6b143fd47a3e8e016
gjalves
pushed a commit
to gjalves/magma
that referenced
this issue
Nov 19, 2019
…controller (magma#890) Summary: Pull Request resolved: magma#890 - For some reason, fluentd's TLS plugin can't seem to handle legit digicert x.509 version 3 certificates: ``` $ openssl s_client -showcerts -connect hostname:24224 -debug CONNECTED(00000005) write to 0x7f9e7d800080 [0x7f9e7e00a803] (200 bytes => 200 (0xC8)) 0000 - 16 03 01 00 c3 01 00 00-bf 03 03 d2 df fa 28 86 ..............(. 0010 - be 3b 24 95 05 27 d3 94-7a 53 c0 91 01 94 77 7e .;$..'..zS....w~ 0020 - 0d be 81 1b 49 8f a8 2f-1f 02 82 00 00 60 c0 30 ....I../.....`.0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 9f 00 6b 00 39 .,.(.$.......k.9 0040 - cc a9 cc a8 cc aa ff 85-00 c4 00 88 00 81 00 9d ................ 0050 - 00 3d 00 35 00 c0 00 84-c0 2f c0 2b c0 27 c0 23 .=.5...../.+.'.# 0060 - c0 13 c0 09 00 9e 00 67-00 33 00 be 00 45 00 9c .......g.3...E.. 0070 - 00 3c 00 2f 00 ba 00 41-c0 11 c0 07 00 05 00 04 .<./...A........ 0080 - c0 12 c0 08 00 16 00 0a-00 15 00 09 00 ff 01 00 ................ 0090 - 00 36 00 0b 00 02 01 00-00 0a 00 08 00 06 00 1d .6.............. 00a0 - 00 17 00 18 00 23 00 00-00 0d 00 1c 00 1a 06 01 .....#.......... 00b0 - 06 03 ef ef 05 01 05 03-04 01 04 03 ee ee ed ed ................ 00c0 - 03 01 03 03 02 01 02 03- ........ read from 0x7f9e7d800080 [0x7f9e7e006603] (5 bytes => 5 (0x5)) 0000 - 15 03 03 00 02 ..... read from 0x7f9e7d800080 [0x7f9e7e006608] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 4701910636:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL alert number 40 4701910636:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/ssl/ssl_pkt.c:585: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Start Time: 1573808339 Timeout : 7200 (sec) Verify return code: 0 (ok) --- ``` - Note the SSL record above comes back immediately with type 0x15 (SSL3_RT_ALERT), which means that the server is unable to proceed with the handshake after the client's hello packet (the 200 bytes written). This is possibly related to fluent/fluentd#2699 - This is reproducible with both a chained cert file from digicert and just the leaf cert by itself. Specifying a `-servername` parameter for SNI doesn't solve anything in either case. - However, if we use an x.509 version 1 cert signed by a self-signed root CA, fluentd is able to negotiate the SSL/TLS handshake successfully - Since we aren't validating TLS in the fluent-bit config, the fact that the rootCA on the gateway won't validate the SSL cert provided by the server won't matter, so we can safely use the self-signed cert. We really just care that the traffic is TLS-encrypted and TLS mutual authentication happens using the controller's certifier CAcert. - So instead of re-using the controller.crt/controller.key legit SSL certs, use fluentd.pem/fluentd.key for the forwarder pod Reviewed By: Scott8440 Differential Revision: D18543114 fbshipit-source-id: e0d636fd725de990276da0c6b143fd47a3e8e016
This was referenced Apr 3, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
X509 certificate files often contain the leaf certificate and all intermediate CA certificates excluding the root. Fluentd should support such files, otherwise only certificates signed directly by the root CA can be used.
Describe the solution you'd like
Load all certs in the provided file into the OpenSSL context.
Describe alternatives you've considered
The only alternative is to issue certificates directly from the root, which is bad practice.
Additional context
About to open a PR - this issue is mostly for documentation purposes.
The text was updated successfully, but these errors were encountered: