Glowsome
July 7, 2025, 10:23pm
1
CMK version: 2.3.0p34 OS version: RockyLinux 9.6
Rule configured: Check Certificate(s)
The port used is a/the LDAP(s) port of a server to check its certificate attatched.
Most likely i made a logic error in configuring a/the rule, but fail to see it so i would appreciate some extra eyes.
Update:
So i am doubting if this is a rule-config error, but a limitation of a/the rule ?
Glowsome
July 26, 2025, 11:43pm
2
As no reply is/has been made and the issue still exists, i will assume for now that i’m dealing with a bug.
@Sara can you raise this with devs please ?
mimimi
July 27, 2025, 11:21am
3
Can you reproduce this issue with the https://self-signed.badssl.com/ endpoint of https://badssl.com/ ?
Are issuer and subject of the cert the same?
Check with something like this (just out of my head, may need adjustments):
openssl s_client -connect <ldapserver>:636 < /dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates
What happens if you add the CA cert to the globals truststore (be aware there is also a site specific trust store)
Glowsome
July 27, 2025, 10:07pm
4
I have no issues when using a/the rule and having a self-signed on a HTTPS -connection.
I was not planning on that because of the option to allow self-signed’s
Update: I have done some digging regarding this:
Compared to a ‘regular’ self-signed certificate i see that the LDAP-certificate in my case has a chain:
~/lib/nagios/plugins$ ./check_cert -v --url myhost.domain.tld --port 443 --not-after 3456000 1728000 --allow-self-signed
INFO: start check-cert
INFO: load trust store...
INFO: loaded 154 certificates
INFO: contact host...
INFO: received chain of 1 certificates from host
INFO: check certificate...
INFO: 1/3 - check fetching process
INFO: 2/3 - verify certificate with trust store
INFO: 3/3 - check certificate
INFO: check certificate... done
Certificate obtained in 93 ms, Verification: OK, Certificate expires in 314 day(s) (Jun 7 00:21:32 2026 +00:00) | overall_response_time=0.093127s;60.000000;90.000000;; certificate_remaining_validity=27135688s;3456000;1728000;;
Certificate chain verification OK: self-signed certificate
If i look at the output from the LDAP -host:
~/lib/nagios/plugins$ ./check_cert -v --url my-ldap-host.domain.tld --port 636 --not-after 3456000 1728000 --allow-self-signed
INFO: start check-cert
INFO: load trust store...
INFO: loaded 154 certificates
INFO: contact host...
INFO: received chain of 2 certificates from host
INFO: check certificate...
INFO: 1/3 - check fetching process
INFO: 2/3 - verify certificate with trust store
INFO: 3/3 - check certificate
INFO: check certificate... done
Certificate obtained in 115 ms, Certificate chain verification failed: self-signed certificate in certificate chain (!), Certificate expires in 3568 day(s) (May 5 19:53:25 2035 +00:00) | overall_response_time=0.115143s;60.000000;90.000000;; certificate_remaining_validity=308350770s;3456000;1728000;;
So it seems that the ignore self-signed only works for a/the non-chained/leaf-certificate.
It would be my expectation that no matter how long a/the chain is it would ignore all self-signed in a/the chain.
Glowsome:
Certificate obtained in 115 ms, Certificate chain verification failed: self-signed certificate in certificate chain (!), Certificate expires in 3568 day(s) (May 5 19:53:25 2035 +00:00) | overall_response_time=0.115143s;60.000000;90.000000;; certificate_remaining_validity=308350770s;3456000;1728000;;
As a test, could you try the following?
./check_cert --url my-ldap-host.domain.tld --port 636 --ca-file /path/to/selfsigned-root.crt
Apart from this, what is the output of the below command? What is the 'Verify return code:" ?
openssl s_client -connect my-ldap-host.domain.tld:636 -showcerts
Glowsome
August 5, 2025, 7:21pm
6
As a test, could you try the following?./check_cert --url my-ldap-host.domain.tld --port 636 --ca-file /path/to/selfsigned-root.crt
i’ll have to export it first to be able to run that.
Apart from this, what is the output of the below command? What is the 'Verify return code:" ?openssl s_client -connect my-ldap-host.domain.tld:636 -showcerts
See the code returned below:
Verify return code: 19 (self-signed certificate in certificate chain)
Could it be that your LDAP server sends a certificate chain (not just the server cert).
Usually:
Leaf cert (the server)
Issuer cert (your Tree CA)
So, even if --allow-self-signed is specified, the plugin tries to verify the chain using the trust store.
The Tree CA is not in the system/Global setting trust store , so the verification fails.
I tried with my test PostgreSQL server which is presenting on 127.0.0.1 only a self-signed certificate, without a chain , and:
The cert is self-issued (same subject and issuer).
There’s no intermediate CA , just one cert.
In my case, the --allow-self-signed allows the plugin to bypass trust store verification , as long as :
The certificate is self-signed , and
There’s no full chain being verified
For example:
$ check-cert --url 127.0.0.1 -p 5432 --allow-self-signed
Verification: self-signed certificate (allowed), Subject CN: localhost, Server certificate validity: 364 day(s) | overall_response_time=0.025580s;;;; certificate_remaining_validity=31531144s;;;;
Glowsome
August 5, 2025, 8:06pm
8
Yes this is exactly what is sent if i look at the response from the prevous command ( for the verify return code)
See below for full output:
Connecting to 172.16.0.70
CONNECTED(00000003)
depth=1 OU=Organizational CA, O=IDVAULT
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 OU=Organizational CA, O=IDVAULT
verify return:1
depth=0 O=IDVAULT, CN=vm-lx-08
verify return:1
---
Certificate chain
0 s:O=IDVAULT, CN=vm-lx-08
i:OU=Organizational CA, O=IDVAULT
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: May 7 19:53:25 2025 GMT; NotAfter: May 5 19:53:25 2035 GMT
-----BEGIN CERTIFICATE-----
MIIInTCCBoWgAwIBAgIUdjgqAulT1BhMwqXISaM1u6LN4+EwDQYJKoZIhvcNAQEM
BQAwLjEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExEDAOBgNVBAoTB0lEVkFV
TFQwHhcNMjUwNTA3MTk1MzI1WhcNMzUwNTA1MTk1MzI1WjAlMRAwDgYDVQQKEwdJ
RFZBVUxUMREwDwYDVQQDEwh2bS1seC0wODCCAiIwDQYJKoZIhvcNAQEBBQADggIP
ADCCAgoCggIBAK7bK0LpofscdZxh+FKHlXZRRnXyjM3oErgZOyj1A3nKKM807NbT
sPGe+bPhUIfddDTQkGGh8/Z1smwVI25UbTvYtRcfTlQa9SDSKijV05NeOGKwuZ56
eomiQmdU/s0lqASSDeDeBP+ez+0fpErYFOK6ZX58hTb7oYW6NS0WwCcKuLPpEj/z
f4drieS5bLZqCZWj2ByM3B18NoMkQZbdtbJm49eVUOnj1D72f5R7Y1zBVTaXjB/F
uAjU5atB0Y1tTGDHiy9qF0RiKHeYufeC+Ch+XcZ3RBIJWNVhmvPhE/EhmLS1BJJe
I2mUuEpdhfnb1oy1mAEs++MCrt6mPthRGkF0ndbggzw4SatxrSstJC9upNYul72r
X5GAqp619GP9mfGStKJoPEaI37sp2VlEWiG6/pn9fUl1jEczCh0/R/qMOSDQREaS
dbKaNJ4Yqmmb/yQcoVlIx8LHPuRDcKsvmfb6ceP4hF0Xt+yWafl0LbUFyXaB5qvW
iI0fTxvNJpJ/Nvc/pR3zv95kSlg6mUo37lSZm0vCx/lpLS2SCUaIcTRgkQCY38Ru
TwVn+mEE6Cgn6J5bBiJFd01GdW0/4yQ6/k9vYUL+3SrITj9z2B/qWbxb2Kjiiy75
GLx2vK5myYskVntwnrPArGJnin6lmH/Tn5kJDKRJnEaxYDvnA/bMKSftAgMBAAGj
ggO6MIIDtjAdBgNVHQ4EFgQUsNhQp/ZsmregpgZm43Y6JjoVUO4wHwYDVR0jBBgw
FoAUCyonitE7QZB3QSZg26SRTY1u1l4wDwYDVR0RBAgwBocErBAARjALBgNVHQ8E
--------------- Redacted-----------------
-----END CERTIFICATE-----
1 s:OU=Organizational CA, O=IDVAULT
i:OU=Organizational CA, O=IDVAULT
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: May 5 21:53:23 2025 GMT; NotAfter: May 5 21:53:23 2035 GMT
-----BEGIN CERTIFICATE-----
MIIHGzCCBQOgAwIBAgIUTc+vF1GPLaiWelLm+aLzeLx1aoUwDQYJKoZIhvcNAQEM
BQAwLjEaMBgGA1UECxMRT3JnYW5pemF0aW9uYWwgQ0ExEDAOBgNVBAoTB0lEVkFV
TFQwHhcNMjUwNTA1MjE1MzIzWhcNMzUwNTA1MjE1MzIzWjAuMRowGAYDVQQLExFP
cmdhbml6YXRpb25hbCBDQTEQMA4GA1UEChMHSURWQVVMVDCCAiIwDQYJKoZIhvcN
--------------- Redacted-----------------
-----END CERTIFICATE-----
---
Server certificate
subject=O=IDVAULT, CN=vm-lx-08
issuer=OU=Organizational CA, O=IDVAULT
---
No client certificate CA names sent
---
SSL handshake has read 4375 bytes and written 905 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384
Session-ID: 6A7DC819EB9E2116975AF3AD17FB233BAFF15FFAEEB7084EDC--------------- Redacted-----------------
Session-ID-ctx:
Master-Key: D96182AB1109FDCA4F01F84189CDC439859FBD969BC6B98E2EDBF7430557A734 --------------- Redacted-----------------
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 91 f8 a9 01 57 2d b1 b5-f6 14 6c 91 c7 e4 1f ec ....W-....l.....
0010 - 07 3b 69 a8 c0 e5 9a 82-96 ea 3f b1 e3 11 48 63 .;i.......?...Hc
0020 - 85 ff 65 3d 1a 4d c9 37-1f e7 2d 75 5f 83 a6 23 ..e=.M.7..-u_..#
0030 - cb 21 cb 4f ac 14 a2 e7-99 1c 32 36 a0 4e 73 92 .!.O......26.Ns.
0040 - e1 bc 20 fc 60 25 cf 0b-fc f5 a4 d6 1a b7 74 a1 .. .`%........t.
0050 - 9c 07 d7 5b 1b 4d fb 22-68 4a 56 90 4c 41 65 69 ...[.M."hJV.LAei
0060 - b5 a2 eb 4e 8d 6e f0 26-82 68 fd 07 d6 0a fe 27 ...N.n.&.h.....'
0070 - 9e 4e 50 fe 4e d9 ea 8b-58 71 a6 7e 35 2e a4 4d .NP.N...Xq.~5..M
0080 - b5 08 3f c3 c0 5c 8f 64-86 1b d9 c2 9b 2e 39 03 ..?..\.d......9.
0090 - c5 ec 9c 4e f6 2a 07 59-c8 ed 36 d8 89 35 db 5f ...N.*.Y..6..5._
00a0 - 32 27 53 63 3a 66 a9 e0-f5 e3 01 f6 26 46 72 c7 2'Sc:f......&Fr.
00b0 - a8 d0 b4 df 12 a0 80 b4-af 6d 3e af 77 4d 70 74 .........m>.wMpt
Start Time: 1754421586
Timeout : 7200 (sec)
Verify return code: 19 (self-signed certificate in certificate chain)
Extended master secret: no
Josef
February 24, 2026, 2:45pm
9
We have the same problem - any solution yet?
Is it because the chain has a self signed one and not the server itself ?
Josef
n3m0
March 20, 2026, 11:09am
10
I would be interested in a solution as well.
Any updates?
BR,
