- edited description
SSL accept error: error:00000000:lib(0):func(0):reason(0)
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):
Comments (6)
-
reporter -
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
-
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] -------------------------------------------------------------------------------
-
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 thewith http headers [Authorization: Basic YWRtaW46MTIzNDU=]
. But this would lead toHttpRequest: access denied -- client [PUBLICIPOFMONITORINGINSTANCE]: missing or invalid Authorization header
being logged on the remote monit host. -
- changed status to open
-
- changed status to resolved
- Log in to comment