[syslog-ng] Mutual TLS issues

[Matthew Pounsett]

I'm trying to get mutual TLS validation working and seem to be having
issues with the config.  The situation I've got is that I'm trying to
accept a stream from another organization.  And so my preferred
configuration involves two CA's.. mine and theirs.  My syslog-ng server
needs to validate their server certificate using their CA certificate, and
their syslog-ng client needs to validate my server certificate using my CA
certificate. I've set up a test using the server that will be production,
and a handy VM I control.

I assumed that it would be as simple as using the example configs from the
manual [0], and anywhere a CA cert is involved just pick the appropriate
one: store their CA on my server, and my CA on "their" server (the test
VM).  That didn't work.

I've backed down to trying to get this working using all certificates
signed by my CA, but I can't seem to make that work either.  The error
timing I'm getting doesn't quite match similar errors I can see reported
online.

If I don't have the correct CA cert on the client, then I see a connect,
immediate disconnect, and a "SSL routines:ssl3_read_bytes:tlsv1 alert
unknown ca" error on the server.  If I do have the CA cert on the client, I
see a connect ... and then nothing until I try to send a message.  Then I
get the same error on the server and a logged "Certificate validation
failed" error on the client referencing the server's cert, and a disconnect.

Server logs:
Sep 17 23:17:49 adm syslog-ng[31128]: Syslog connection accepted; fd='24',
client='AF_INET(216.235.10.40:54063)', local='AF_INET(64.191.0.17:6514)'
Sep 17 23:18:01 adm syslog-ng[31128]: SSL error while reading stream;
tls_error='SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca'
Sep 17 23:18:01 adm syslog-ng[31128]: I/O error occurred while reading;
fd='24', error='Connection reset by peer (104)'
Sep 17 23:18:01 adm syslog-ng[31128]: Syslog connection closed; fd='24',
client='AF_INET(216.235.10.40:54063)', local='AF_INET(64.191.0.17:6514)'

Client logs:
Sep 17 23:17:48 ubuntu syslog-ng[4603]: syslog-ng starting up;
version='3.13.2'
Sep 17 23:17:48 ubuntu syslog-ng[4603]: Syslog connection established;
fd='13', server='AF_INET(64.191.0.17:6514)', local='AF_INET(0.0.0.0:0)'
Sep 17 23:18:00 ubuntu syslog-ng[4603]: Certificate validation failed;
subject='emailAddress=xxx at dns-oarc.net, CN=64.191.0.17, O=OARC\, Inc.,
L=Indianapolis, ST=Indiana, C=US', issuer='emailAddress=xxx at dns-oarc.net,
CN=OARC Inc. Certificate Authority, O=OARC\, Inc., ST=Indiana, C=US',
error='unable to get local issuer certificate', depth='0'
Sep 17 23:18:00 ubuntu syslog-ng[4603]: SSL error while writing stream;
tls_error='SSL routines:tls_process_server_certificate:certificate verify
failed'
Sep 17 23:18:00 ubuntu syslog-ng[4603]: I/O error occurred while writing;
fd='13', error='Broken pipe (32)'
Sep 17 23:18:00 ubuntu syslog-ng[4603]: Syslog connection broken; fd='13',
server='AF_INET(64.191.0.17:6514)', time_reopen='60'

Note the 12 second gap between startup and cert validation failure.  The
failure coincides with logging a message that should be sent from the
client to the server.

Server config:
source tls_source {
network(ip(64.191.0.17) port(6514)
transport("tls")
tls(
key-file("/etc/ssl/private/64.191.0.17.key")
cert-file("/etc/ssl/certs/64.191.0.17.crt")
ca-dir("/etc/ssl/certs")
)
);
};

Client config:
destination d_tls {
network("64.191.0.17" port(6514)
transport("tls")
tls(
ca-dir("/etc/ssl/certs")
key-file("/etc/ssl/private/216.235.10.40.key")
cert-file("/etc/ssl/certs/216.235.10.40.crt")
)
);
};

I have the CA cert stored as /etc/ssl/certs/server_ca.pem on both systems.

Any idea what's wrong here? And, should I be able to get this to work using
different CAs for the client and server certs?

Thanks

[0]: <https://www.syslog-ng.com/technical-documents/doc/
syslog-ng-open-source-edition/3.16/mutual-authentication-
using-tls#TOPIC-956368>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20180918/abf0e432/attachment.html>