aleliaert
commented
6 years ago It turned out that we needed to provide a key and cert for mutual TLS into our bosh director's nats server.
We now have a fork that:
- Builds against the latest Lager and golang 1.8.x
- Accepts a mutual TLS key and cert as files specified via parameters on the command line
- Accepts extra fields to be added to nats message body
- Extra flag to suppress NATS messages themselves from going to stdout (wasn't sure if this was a bug or an intended feature)
We can submit a PR if these are welcome into master. Thanks!
ghost
My team been using nats_to_syslog for a long time against nats on older bosh directors... With a new director, it appears that the director requires TLS and so we're trying to play along. The adventure thus far:
nats: secure connection required errorand so we updated our URL prefix to betls://instead ofnats://x509: certificate signed by unknown authority, resolved by placing the NATS server CA cert on the host running nats_to_syslogremote error: bad certificate, presumably due to having an IP address in our URL but the cert having CN ofdefault.nats-ca.bosh-internal(and no subject alternative names matching the IP address)I see that Golang offers a brute force way to allow insecure TLS via InsecureSkipVerify. That is appropriate for our use case (several layers deep within private networks) but not aligned with the "greater good" if we submit a PR back to master.
Some internet sleuthing suggests that Golang offers a way to specify expected server name in cases where reaching TLS server via IP address. Per this on StackOverflow, it seems that we could have the app allow a server name such as
default.nats-ca.bosh-internalto be passed in via argument, and then internally it could set tls.Config.ServerName to this value. Or have a "resolve" argument similar tocurl --resolve, where one could use the cert-matching name in the URL but provide the desired name-to-IP mapping.Any advice on how to proceed?
Thanks!