enhancement request: STARTTLS

Issue #204 closed
Ulrich Windl created an issue

I tried to configure monit to check our LDAP server. As all clients are required to use encrypted connections, so I'd like to check whether a vald TLS connection can be made to the ldap port (389).

Without TLS, the check succeeds, but all of TCPSSL fail. In the best case I get this: error : 'ds1' failed protocol test [LDAP3] at [ds1.domain]:389 [TCPSSL/IP] -- LDAP: error sending data -- Success

I guess monit is trying to talk SSL on the port, not using STARTTLS. As it seems monit cannot do STARTTLS, I'd like to add that to the wishlist.

Protocols affected obviously: LDAP, SMTP, MSP Additional checks for SSL/TLS server certificates could be: certificate ID (Subject Key Identifier), certificate expiration date (validity)

So you could find out when the certificate changed and whether it is expired or will expire soon.

Probably the idea needs some more thoughts or features like specifyinfg a client certificate also...

Comments (8)

  1. Tildeslash repo owner

    We plan to add the certificate expiration test, the STARTTLS for protocol checks will be also implemented, the ceritificate ID is very good idea. We're working on other stuff currently, putting temporarily on hold

  2. Ulrich Windl reporter

    When I tired to use "TLS" in a port check with monit-5.15, I see a "[TCP/IP SSL" Error sending data -- Success" message. Before I see a "ssh handshake error". My guess is that "SSL" and "TLS" are treated a synonyms in monit-5.15. Can you confirm that?

  3. Tildeslash repo owner

    Please can you show your port check configuration and send monit log?

    The "ssl" and "tls" are interchangeable now, but it doesn't affect backward compatibility ... if you wanted to use some TLS version in monit <= 5.14, you had to use "tlsv1", "tlsv11" or "tlsv12" - these are still unique options, the plain "tls" was never supported for setting TLS.

  4. Ulrich Windl reporter

    I had removed the configuration when it did not work as expected. The lines were:

    check host host2 with address "host2.domain.org" if failed ping then alert if failed port 389 type tcp tls protocol ldap3 with timeout 10 seconds then alert

    Lines in monit.log were: [CET Nov 3 09:36:47] error : SSL: write error -- error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure [CET Nov 3 09:36:47] error : 'rksapds1' failed protocol test [LDAP3] at [host2.domain.org]:389 [TCP/IP SSL] -- LDAP: error sending data -- Success

    I think the problem is that a "STARTTLS" would actually be required to use TLS with LDAP.

  5. Tildeslash repo owner

    The original statement had minor typo, which made it not to use SSL at all ... the option to set the connection into SSL/TLS mode was "type tcpssl" (without space between "tcp" and "ssl"). That "tcp" with space made the connection test to use plain TCP connection (unencrypted).

    The correct configuration for monit <= 5.14 using for example TLSv1.2 would be:

    check host host2 with address "host2.domain.org"
      if failed ping then alert
      if failed port 636 type tcpssl tlsv12 protocol ldap3 with timeout 10 seconds then alert
    

    Note that there are two different types of LDAP SSL/TLS support:

    1. either port 389 (unencrypted) where the client establishes plain connection and can use STARTTLS to switch to TLS

    2. or dedicated LDAPS port 636, which requires SSL/TLS handshake for connection

    Your configuration uses port 389 ... the STARTTLS is not supported in the LDAP protocol test - it performs just simple anonymous Bind and Unbind commands and checks responses, no credentials are send to the server, no encryption is necessary.

    The following configuration should work fine - shows test for both SSL and non-SSL ports, if you have just port 389, drop the line for port 636:

    check host host2 with address "host2.domain.org"
      if failed ping then alert
      if failed port 389 protocol ldap3 with timeout 10 seconds then alert
      if failed port 636 protocol ldap3 using ssl with timeout 10 seconds then alert
    
  6. Tildeslash repo owner

    The STARTTLS for LDAP protocol test is not necessary, monit does just bind+unbind during the protocol test ... that is sufficient for port 389 testing, the port 636 which requires SSL for connection can be tested too, by enabling the SSL using monit connection options.

  7. Ulrich Windl reporter

    Sorry for re-issuing: You can have a successful LDAP port 389 that still fails STARTTLS (e.g. due to mis-configuration, or most likely because of an expired certificate).

    I’m aware that LDAP STARTTLS is a bit messy, but still it would be nice to have.

    After binding, one would have to query the START_TLS extension, optionally set up preferred ciphers, CA path, verify requirements, then start TLS, checking for success.

    On success (so far), one could also query the cipher negotiated (like AES256-GCM-SHA384).

    One could also use “ldapsearch -ZZ …”, but then you cannot get any details on the certificate(s) being used.

    A very recent openssl can do: openssl s_client -connect ldap-server:389 -satrttls ldap --showcerts, but the certificates involved would still be in PEM format (BASE64).

    The main issue might be that you don’t want to include LDAP libraries in monit.

  8. Log in to comment