Ubuntu – Fix Failed TLS Handshake Due to Missing IP SANs

logstashsslssl-certificatetlsUbuntu

I'm trying to set up logstash forwarder, but I have issues with making a proper secure channel. Trying to configure this with two ubuntu (server 14.04) machines running in virtualbox. They are 100% clean (not touched hosts file or installed any other packages other than the required java, ngix, elastisearch, etc, for logstash)

I do not believe this is a logstash issue, but improper handling of certificates or something not set correct either on the logstash ubuntu or forwarder machine.

I generated the keys:

sudo openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout private/logstash-forwarder.key -out certs/logstash-forwarder.crt

My input conf on logstash server:

input {
  lumberjack {
    port => 5000
    type => "logs"
    ssl_certificate => "/etc/pki/tls/certs/logstash-forwarder.crt"
    ssl_key => "/etc/pki/tls/private/logstash-forwarder.key"
  }
}

Keys were copied to forwarder host, which has the following config.

{
  "network": {
    "servers": [ "192.168.2.107:5000" ],
    "timeout": 15,
    "ssl ca": "/etc/pki/tls/certs/logstash-forwarder.crt"
    "ssl key": "/etc/pki/tls/certs/logstash-forwarder.key"
  },
  "files": [
    {
      "paths": [
        "/var/log/syslog",
        "/var/log/auth.log"
       ],
      "fields": { "type": "syslog" }
    }
   ]
}

With logstash server running, I 'sudo service logstash-forwarder start' on the forwarder machine, giving me the following repeated error:

Jul  9 05:06:21 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:21.589762 Connecting to [192.168.2.107]:5000 (192.168.2.107)
Jul  9 05:06:21 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:21.595105 Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs
Jul  9 05:06:22 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:22.595971 Connecting to [192.168.2.107]:5000 (192.168.2.107)
Jul  9 05:06:22 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:22.602024 Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs

As I mentioned earlier, I do not believe this is a logstash issue, but certificate/machine config issue. Problem is, I can't seem to solve it. Hopefully some clever minds here can help me out?

Thanks

Best Answer

... Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs

SSL needs identification of the peer, otherwise your connection might be against a man-in-the-middle which decrypts + sniffs/modifies the data and then forwards them encrypted again to the real target. Identification is done with x509 certificates which need to be validated against a trusted CA and which need to identify the target you want to connect to.

Usually the target is given as a hostname and this is checked against the subject and subject alternative names of the certificate. In this case your target is a IP. The validate the certifcate successfully the IP must be given n the certificate inside the subject alternative names section, but not as an DNS entry (e.g. hostname) but instead as IP.

So what you need to is:

Edit your /etc/ssl/openssl.cnf on the logstash host - add subjectAltName = IP:192.168.2.107 in [v3_ca] section.
Recreate the certificate
Copy the cert and key to both hosts

PS Consider adding -days 365 or more to the certificate creation commandline as the default certificate validity is just 30 days and you probably do not want to recreate it every month..

Related Solutions

Ssl – TLS and how does it compare to SSL

TLS and SSL are closely related technologies.

First, email and Opportunistic TLS. ESMTP has the option of performing the actual data transfer portion of the conversation over an encrypted link. This is part of the protocol and has been called TLS for most of its existence. It works roughly like this:

-> EHLO foreignmailer.example.com
<- 250 Howdy, stranger
<- [list of capabilities, of which TLS is listed]
-> [Indicates it wants to start a TLS session]
<- [accepts negotioation]
-> [Mail actions, of which LOGIN might be one]

Once the TLS session has been started, new login methods might be available. This is an example of a protocol that includes Transaction Layer Security in it directly. The certificates used are the same kind of certificates used for SSL over HTTP.

For an example of a service that doesn't include TLS directly, take POP3-over-SSL. In that case, the secure session is negotiated before the actual protocol is negotiated. In essence, POP3 is being encapsulated inside a secure session.

In general, if a service supports SSL it can be extended to support TLS. Whether or not that has been done is up to the maintainers of the service. This does mean that TLS can replace SSL in "SSL VPNs".

SSL VPNs are distinct from their IPSec based cousins in that the secure session is done at a different level. SSL VPNs do their work much the same way that POP3-over-SSL does, in that traffic is encapsulated over an existing TCP connection. IPSec VPNs create an IP-level secure tunnel, where SSL VPNs create a TCP-level secure tunnel. The reason SSL VPNs seem to be taking over is that they're easier to set up and are more tolerant of bad network conditions. SSL VPNs can and do use the TLS protocol for securing the session, though it does depend on the maker of the VPN itself.

As for the exact protocol level differences between SSL and TLS, that I can't get into. TLS as a standard was arrived at later than SSL and therefore includes some of the lessons learned in the early SSL versions. SSLv3 was ratified back in 1996 and TLS1.0 in 1999, and further protocol development appears to be limited to the TLS suite. It has taken a LONG time for SSLv1 and v2 to go away. TLS is the clear successor of the SSL suite.

Logstash-forwarder is throwing SSL errors

The certificate you are using does not have any valid IP SAN's as mentioned in the message:

Failed to tls handshake with x.x.x.x x509: cannot validate certificate for x.x.x.x because 
it doesn't contain any IP SANs

If you connect using an IP address then your certificate must contain a matching IP SAN to pass validation with Go 1.3 and higher. This is not (yet?) mentioned in any README file or documentation but there are some issues ( #226 , #221 ) open at the project github repo.
To permit IP address as the server name, the SSL cert must include IP address as a subjectAltName field.

To solve that you can use following procedure for the creation of the SSL cert and key:

Create a file notsec.cfr (or any other name) containing output like:

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = TG
ST = Togo
L =  Lome
O = Private company
CN = *

[v3_req]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:TRUE
subjectAltName = @alt_names

[alt_names]
DNS.1 = *
DNS.2 = *.*
DNS.3 = *.*.*
DNS.4 = *.*.*.*
DNS.5 = *.*.*.*.*
DNS.6 = *.*.*.*.*.*
DNS.7 = *.*.*.*.*.*.*
IP.1 = 192.168.1.1
IP.2 = 192.168.69.14

If you connect via host names, you can remove the IP SAN's, otherwise add your logstash server IP address.

Create the certificate and key with following command (using the file from point 1):

openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout notsecure.key -out notsecure.crt -config notsec.cnf -days 1825

This will create a kind of wildcard certificate accepting any hostname and the IP addresses mentioned it that file. Of course this is just a simple example and you wil need to adjust the settings to your needs.

Best Answer

Related Solutions

Ssl – TLS and how does it compare to SSL

Logstash-forwarder is throwing SSL errors

Related Topic