SSL accept error: error:00000000:lib(0):func(0):reason(0)

Issue #1078 resolved
codiflow created an issue

All my external Monit instances are logging the following error ~ every minute: in /var/log/user.log

monit[475]: SSL accept error: error:00000000:lib(0):func(0):reason(0)

The SSL stuff in the configuration file .monitrc is as follows:

set ssl {
    verify     : enable, # verify SSL certificates (disabled by default but STRONGLY RECOMMENDED)
    selfsigned : reject   # allow self signed SSL certificates (reject by default)
}

[...]

set httpd port 2812 and
    use address X.X.X.X  # only accept connection from localhost (drop if you use M/Monit)
    allow domain.de           # allow localhost to connect to the server and
    allow admin:XXXX      # require user 'admin' with password 'monit'
    with ssl {            # enable SSL/TLS and set path to server certificate
        pemfile: /etc/ssl/monit.pem
    }

The /etc/ssl/monit.pem contains

cat /root/.acme.sh/domain.de_ecc/domain.de.key /root/.acme.sh/domain.de_ecc/fullchain.cer > /etc/ssl/monit.pem

Running openssl s_client -connect domain.de:443 returns the following:

CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
verify return:1
depth=1 C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
verify return:1
depth=0 CN = domain.de
verify return:1
---
Certificate chain
 0 s:CN = domain.de
   i:C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
 1 s:C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=CN = domain.de

issuer=C = AT, O = ZeroSSL, CN = ZeroSSL ECC Domain Secure Site CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 3288 bytes and written 467 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 3DBD898A74DA32A6BAD3D2C61BB70BE5A72535BA6FA00960C0D2BA0EBCB12EC5
    Session-ID-ctx: 
    Master-Key: 7099B7369302DFFE7EE7BB67B694BEBB11C2B30660FE732B568681D11A3FC267DD0D00D97F6438CD1643618989F38A33
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1687882143
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes

Changing verify : enable to verify : disable does not change anything.

I think this behaviour appeared after I switched from Let’s Encrypt to ZeroSSL. But as both CAs are trusted it should not return this kind of error.

Maybe it is helpful to notice that the cert for domain.de is a wildcard cert now.

Apart from that everything works fine – so the logs are only annoying and I couldn’t identify anything not working related to them.

Some articles related to similar problems (not monit related unfortunately):

https://community.microstrategy.com/s/article/SSL-accept-error-error-00000000-lib-0-func-0-reason-0-error-appears-in-the-DSSErrors-log-while-the-SSL-authentication-works-both-on-Developer-and-Web-in-MicroStrateg?language=en_US

https://openssl-dev.openssl.narkive.com/1eoBAAYa/ssl-negotiation-failed-error-00000000-lib-0-func-0-reason-0

Comments (6)

  1. Tildeslash repo owner

    Unfortunately I have no easy way to reproduce this. It does not seem to be an TLS error per se, though, more a client disconnect. If this is logged every minute, what is trying to connect to Monit then every minute? Or is this from a test where Monit tries to connect and test something over SSL? Finally, do check the server with ssllabs to see if there are anything amiss in the SSL/TLS setup. Anyway, if you can, build Monit from source and try to debug and let us know if you find anything

  2. codiflow reporter

    Sorry for the late answer.

    The SSLLabs test says A+ for the M/Monit domain.

    what is trying to connect to Monit then every minute

    Seems like it has to do with my other monitoring instance connecting to 2812 to check whether monit is running. This would make make sense as it is just “disconnecting” if it was successful.

    The code to check my instances is as follows:

    check host monit-my-server with address PUBLICIPADDRESSOFREMOTESERVERHERE
        if failed
           port 2812
        then alert
    

    Is there another way to check for a running monit webserver on my servers than through check host?

    Anyway, if you can, build Monit from source and try to debug and let us know if you find anything

    I ran monit -vv and this was the result:

    SSL accept error: error:00000000:lib(0):func(0):reason(0)
    -------------------------------------------------------------------------------
    monit() [0x4206db]
    monit() [0x421364]
    monit() [0x45c78e]
    monit() [0x4247e3]
    monit() [0x44857e]
    monit() [0x42031e]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7) [0x7f480fbccea7]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f480fa7ba2f]
    -------------------------------------------------------------------------------
    

  3. codiflow reporter

    I think I resolved it by myself – thanks for your hint with the “disconnects”.

    I replaced my check host section as follows and the error is gone:

    check host monit-my-server with address PUBLICIPADDRESSOFREMOTESERVERHERE
        if failed
            port 2812
            with protocol https
            with request /
            with http headers [Authorization: Basic YWRtaW46MTIzNDU=]
            status = 200
            and certificate valid > 10 days
            for 3 cycles
        then alert
    

    An alternative would be to check for status = 401 and remove the with http headers [Authorization: Basic YWRtaW46MTIzNDU=]. But this would lead to HttpRequest: access denied -- client [PUBLICIPOFMONITORINGINSTANCE]: missing or invalid Authorization header being logged on the remote monit host.

  4. Log in to comment