That's not so easy. Because HTTP(S) is not the only one. 

If you would have an integrated ssl expiration date check than it has to support different protocols (ftp, smtp, ldap, rdp, and so on). Some protocols have there own syntax for starttls-like implementation. Additionally to that you have to differentiate mechanisms in the "same" protocol (e.g. LDAP+StartTLS and LDAPS). In some scenarios both variants could deliver different certificates.

Currently I use a own script based on openssl s_client, too.

Sure, it would be nice if this will be part of Zabbix. But if there is a protocol option missing, than you have to use the old script additionally ...

There is option in curl CURLOPT_CERTINFO but not sure how it fits in HTTP agent, could be similar to headers

Example of output:

Subject:C = US, ST = CA, L = San Francisco, O = "Cloudflare, Inc.", CN = zabbix.com
Issuer:C = US, ST = CA, L = San Francisco, O = "CloudFlare, Inc.", CN = CloudFlare Inc ECC CA-2
Version:2
Serial Number:0609affe4caeed2a5d1b400649673e30
Signature Algorithm:ecdsa-with-SHA256
Public Key Algorithm:id-ecPublicKey
X509v3 Authority Key Identifier:keyid:3E:74:2D:1F:CF:45:75:04:7E:3F:C0:A2:87:3E:4C:43:83:51:13:C6
X509v3 Subject Key Identifier:24:10:52:D2:C7:E8:73:74:78:4B:11:3F:B0:E4:4D:2D:EE:C0:63:D7
X509v3 Subject Alternative Name:DNS:*.zabbix.com,DNS:zabbix.com
X509v3 Key Usage:DigitalSignature
X509v3 Extended Key Usage:TLSWebServerAuthentication,TLSWebClientAuthentication
X509v3 CRL Distribution Points:, FullName:, URI:http://crl3.digicert.com/CloudFlareIncECCCA2.crl, 
FullName:, URI:http://crl4.digicert.com/CloudFlareIncECCCA2.crl
X509v3 Certificate Policies:Policy:2.16.840.1.114412.1.1, CPS:https://www.digicert.com/CPS, Policy:2.23.140.1.2.2
Authority Information Access:OCSP-URI:http://ocsp.digicert.com, CAIssuers-URI:http://cacerts.digicert.com/CloudFlareIncECCCA-2.crt
X509v3 Basic Constraints:CA:FALSE
CT Precertificate SCTs:SignedCertificateTimestamp:, Version:v1(0x0), LogID:A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:, 3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10, Timestamp:Dec416:00:58.1542019GMT, Extensions:none, Signature:ecdsa-with-SHA256, 30:45:02:20:6C:E3:35:C3:3C:EC:49:97:93:4E:77:53:, 4E:58:4A:30:D4:3F:DF:EE:41:A0:B9:B7:BA:D1:4B:A8:, 2F:8E:5C:84:02:21:00:DF:BC:DC:62:70:BF:29:38:8C:, A7:01:28:9B:4E:0F:50:F0:ED:60:81:75:EA:49:1D:29:, E7:76:78:F3:06:B0:CA, SignedCertificateTimestamp:, Version:v1(0x0), LogID:5E:A7
Start date:Dec  4 00:00:00 2019 GMT
Expire date:Oct  9 12:00:00 2020 GMT
Signature:30:45:02:20:46:87:79:25:20:36:30:84:f1:13:9f:30:b6:0b:07:1e:aa:0c:37:79:50:07:18:21:96:b3:41:e1:19:73:9a:aa:02:21:00:8d:69:22:85:be:45:7a:be:5a:00:7f:d2:dd:1a:ec:7e:de:e2:28:ad:df:76:ac:db:c7:99:6b:94:5e:a8:14:33:
Cert:-----BEGIN CERTIFICATE-----
MIIEvzCCBGWgAwIBAgIQBgmv/kyu7SpdG0AGSWc+MDAKBggqhkjOPQQDAjBvMQsw
CQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
GTAXBgNVBAoTEENsb3VkRmxhcmUsIEluYy4xIDAeBgNVBAMTF0Nsb3VkRmxhcmUg
SW5jIEVDQyBDQS0yMB4XDTE5MTIwNDAwMDAwMFoXDTIwMTAwOTEyMDAwMFowYjEL
MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2Nv
MRkwFwYDVQQKExBDbG91ZGZsYXJlLCBJbmMuMRMwEQYDVQQDEwp6YWJiaXguY29t
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEZpcY9/1N8CXxsoMWaqfAG6GfoMRZ
prCbV49E69BzxvzGnMe6uljXr3ppHgk0f0UdslbDhWlA+ff71Y+xCcyjY6OCAu4w
ggLqMB8GA1UdIwQYMBaAFD50LR/PRXUEfj/Aooc+TEODURPGMB0GA1UdDgQWBBQk
EFLSx+hzdHhLET+w5E0t7sBj1zAjBgNVHREEHDAaggwqLnphYmJpeC5jb22CCnph
YmJpeC5jb20wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjB5BgNVHR8EcjBwMDagNKAyhjBodHRwOi8vY3JsMy5kaWdpY2VydC5j
b20vQ2xvdWRGbGFyZUluY0VDQ0NBMi5jcmwwNqA0oDKGMGh0dHA6Ly9jcmw0LmRp
Z2ljZXJ0LmNvbS9DbG91ZEZsYXJlSW5jRUNDQ0EyLmNybDBMBgNVHSAERTBDMDcG
CWCGSAGG/WwBATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMAgGBmeBDAECAjB2BggrBgEFBQcBAQRqMGgwJAYIKwYBBQUHMAGGGGh0
dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0aHR0cDovL2NhY2Vy
dHMuZGlnaWNlcnQuY29tL0Nsb3VkRmxhcmVJbmNFQ0NDQS0yLmNydDAMBgNVHRMB
Af8EAjAAMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDvAHYApLkJkLQYWBSHuxOizGdw
Cjw1mAT5G9+443fNDsgN3BAAAAFu0aSjKgAABAMARzBFAiBs4zXDPOxJl5NOd1NO
WEow1D/f7kGgube60UuoL45chAIhAN+83GJwvyk4jKcBKJtOD1Dw7WCBdepJHSnn
dnjzBrDKAHUAXqdz+d9WwOe1Nkh90EngMnqRmgyEoRIShBh1loFxRVgAAAFu0aSi
wgAABAMARjBEAiBYXB9xf840lF95G8a4wcyxVnOur3oLd+5+/nBc4SO53gIgX4AN
bZYPmRPEn2DkVNd+wih8hX4NRzsXQ6q7SdyzbhQwCgYIKoZIzj0EAwIDSAAwRQIg
Rod5JSA2MITxE58wtgsHHqoMN3lQBxghlrNB4RlzmqoCIQCNaSKFvkV6vloAf9Ld
Gux+3uIord92rNvHmWuUXqgUMw==
-----END CERTIFICATE-----

Subject:C = US, ST = CA, L = San Francisco, O = "CloudFlare, Inc.", CN = CloudFlare Inc ECC CA-2
Issuer:C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
Version:2
Serial Number:0ff3e61639aa3d1a1265f41f8b34e5b6
Signature Algorithm:sha256WithRSAEncryption
Public Key Algorithm:id-ecPublicKey
X509v3 Basic Constraints:CA:TRUE,pathlen:0
X509v3 Key Usage:DigitalSignature,CertificateSign,CRLSign
Authority Information Access:OCSP-URI:http://ocsp.digicert.com
X509v3 CRL Distribution Points:, FullName:, URI:http://crl3.digicert.com/Omniroot2025.crl
X509v3 Certificate Policies:Policy:X509v3AnyPolicy, CPS:https://www.digicert.com/CPS
X509v3 Subject Key Identifier:3E:74:2D:1F:CF:45:75:04:7E:3F:C0:A2:87:3E:4C:43:83:51:13:C6
X509v3 Authority Key Identifier:keyid:E5:9D:59:30:82:47:58:CC:AC:FA:08:54:36:86:7B:3A:B5:04:4D:F0
Start date:Oct 14 12:00:00 2015 GMT
Expire date:Oct  9 12:00:00 2020 GMT
Signature:38:5f:a7:ff:fc:85:f2:73:32:e4:d5:a3:89:99:96:60:af:32:c1:03:b3:65:df:be:1e:03:ca:a5:ed:85:b2:8f:af:4b:8c:73:8f:2a:8c:a9:00:0e:01:24:17:f7:ec:52:85:76:c8:e5:1c:79:ca:c3:17:87:50:b6:04:33:36:9e:2a:9e:18:17:96:32:12:af:43:cc:57:18:de:db:c7:d8:88:25:83:e5:ca:06:25:31:fd:bd:5d:48:3b:51:01:dd:2c:14:c7:c1:60:51:e9:95:01:d8:b2:33:56:0e:47:66:8d:6c:cd:af:f9:85:d9:eb:1c:47:47:88:34:e8:f0:fa:c2:ab:4f:69:4e:09:59:d4:57:c6:cc:c1:c8:e3:e6:19:c1:58:38:52:e2:e2:83:85:de:22:34:dc:3f:a6:f7:af:24:bc:e0:6f:c0:ab:68:2d:52:c7:6b:05:57:2c:42:1b:2d:48:87:03:0c:90:ab:48:48:a9:28:be:34:8a:fb:ba:ed:f4:60:99:1d:15:78:11:aa:d9:6d:53:7f:69:28:bc:b7:6b:20:76:7f:a0:55:03:71:79:f5:67:a7:b0:a0:0a:17:57:b2:00:a9:ad:cf:ff:67:8c:3e:26:e5:a7:24:bc:c2:6f:10:e8:89:c6:70:a5:d2:1f:80:ed:0d:3f:27:13:
Cert:-----BEGIN CERTIFICATE-----
MIIDozCCAougAwIBAgIQD/PmFjmqPRoSZfQfizTltjANBgkqhkiG9w0BAQsFADBa
MQswCQYDVQQGEwJJRTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJl
clRydXN0MSIwIAYDVQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1
MTAxNDEyMDAwMFoXDTIwMTAwOTEyMDAwMFowbzELMAkGA1UEBhMCVVMxCzAJBgNV
BAgTAkNBMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBDbG91ZEZs
YXJlLCBJbmMuMSAwHgYDVQQDExdDbG91ZEZsYXJlIEluYyBFQ0MgQ0EtMjBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABNFW9Jy25DGg9aRSz+Oaeob/8oayXsy1WcwR
x07dZP1VnGDjoEvZeFT/SFC6ouGhWHWPx2A3RBZNVZns7tQzeiOjggEZMIIBFTAS
BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0BggrBgEFBQcBAQQo
MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vT21uaXJvb3QyMDI1
LmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUPnQtH89FdQR+P8Cihz5MQ4NR
E8YwHwYDVR0jBBgwFoAU5Z1ZMIJHWMys+ghUNoZ7OrUETfAwDQYJKoZIhvcNAQEL
BQADggEBADhfp//8hfJzMuTVo4mZlmCvMsEDs2Xfvh4DyqXthbKPr0uMc48qjKkA
DgEkF/fsUoV2yOUcecrDF4dQtgQzNp4qnhgXljISr0PMVxje28fYiCWD5coGJTH9
vV1IO1EB3SwUx8FgUemVAdiyM1YOR2aNbM2v+YXZ6xxHR4g06PD6wqtPaU4JWdRX
xszByOPmGcFYOFLi4oOF3iI03D+m968kvOBvwKtoLVLHawVXLEIbLUiHAwyQq0hI
qSi+NIr7uu30YJkdFXgRqtltU39pKLy3ayB2f6BVA3F59WensKAKF1eyAKmtz/9n
jD4m5ackvMJvEOiJxnCl0h+A7Q0/JxM=
-----END CERTIFICATE-----

The info chain is provided in a series of data in the format "name:content" where the content is for the specific named data.

AVAILABILITY

This option is only working in libcurl built with OpenSSL, NSS, Schannel or GSKit support. Schannel support added in 7.50.0

Added in 7.19.1

I think what user asks here is to implement it as part of Web Monitoring. I think it would be more convenient to have this functionality as part of that instead of introduce another set of items for agent.

I guess most often when you need to check a web site certificate you also need to make sure its functionality works. Imagine you have around 200 web sites to monitor and periodically you add/edit/remove them. You would have to adjust the agent checks accordingly each time.

While I agree that all certificates need monitoring, I think that the most important feature to address at first is HTTP TLS Monitoring. As Zabbix is already able to crawl a website, this feature can be added to the web scenario.

We can still fall back to openssl script to monitore other kind of certificates.

As a Zabbix use Curl in Web scenarios as well in HTTP agent it's pretty easy obtain certificate start, expiration dates, subject, issuer and so on. It's achievable by
basically with those two/three options to handle headers and certificate data: CURLOPT_VERBOSE, CURLOPT_HEADER, CURLINFO_CERTINFO ( -I and -v flags in CLI and -k for insecure connections - in case of self signed certificate). It would be really nice to have more useful new keys in this case.

CLI example

curl --insecure -v -I https://www.zabbix.com 2>&1
* About to connect() to www.zabbix.com port 443 (#0)
*   Trying 104.31.68.176...
* Connected to www.zabbix.com (104.31.68.176) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=zabbix.com,O="Cloudflare, Inc.",L=San Francisco,ST=CA,C=US
*       start date: Dec 04 00:00:00 2019 GMT
*       expire date: Oct 09 12:00:00 2020 GMT
*       common name: zabbix.com
*       issuer: CN=CloudFlare Inc ECC CA-2,O="CloudFlare, Inc.",L=San Francisco,ST=CA,C=US
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.zabbix.com
> Accept: */*
>
 

Now I'm using for SSL certificate expire date checks this simple bash oneliner (returned result is days till expire date)

[ns@sys]# expr "("  $(date '+%s' --date "`echo |openssl s_client -showcerts -servername www.zabbix.com -connect www.zabbix.com:443 2>/dev/null| openssl x509 -noout -dates | grep -i 'notAfter=' | sed 's#notAfter=##' `") - $(date '+%s') ")" / 24 / 3600
156

I would like to see it in HTTP Agent item i don't think you want to buid a webscenario for this kind of monitoring.

Hi Guys,

Just as a note for this in terms of potential additional items to detect certificate configuration issues.

We implemented checks for the common things such as

• TLS Expiry Date / TLS Future Date (i.e. currently inactive due to future start date)
• TLS Issuer
• TLS Serial
• TLS Signature Algorithm
• TLS Version
• TLS Subject
• TLS Subject Alternative Names

All of the above ensure the validity of the TLS certificate.

For us most importantly we check whether a specific set off subject alternative names exist or an individual one using regular expressions.

Cheers

James

How will this be solved?
Zabbix agent?
Zabbix agent2?
Web scenario?
HTTP agent?

Hello, starko

It will be a plugin for agent2.

Any reason for it not to be implemented in server/proxy side? Monitoring websites via agent sounds bad idea for my setup. Its too big, have too many ssl endpoints, and its too much distributed.

We think its easier to manage using the current distribution setup, that is using proxy.

Is that a new general direction on expanding Zabbix monitoring capabilities?

fpaternot, the current implementation is just yet another agent2 item - web.certificate.get[host], similar to web.page.get[]. So it's a natural choice to have such check in the agent along with other web.* items. Also, this gives you a pretty high degree of flexibility if you need to monitor a lot of websites without the additional overhead of managing proxies.

Sorry, I don't see the flexibility you mention.

When one creates a host (lets call it example.com), we have to give it an interface. Since we have it monitored via agent2, we have to point that interface to zabbix-agent-host.

Point one: a user looking for that host example.com, will see dns/ip of Zabbix-agent-host. That creates confusion.

Point two: we have an additional component to maintain, the Zabbix agent. We have to look/tune sessions for that plugin, and monitor its usage. Thats not well implemented yet, like the internal Zabbix itens for poller usage.

Point three: Zabbix agent is not currently required to monitor web pages, but it will be now, just to check just the certificate. From this point of view, I'd prefer to do an external script call, curl -v and preprocess the result. Of course it gives us a performance hit, but sounds better than adding agent to dependency list.

Point four: as Gatis Rumben mentioned here, its already available from lib curl, the current setup of Zabbix proxy/server. It's perfectly possible to either extend http agent or web scenario. I personally think http agent is more flexible to implement as it does not affect existing hosts and can be easily expanded as Zabbix Admin wants.

I can create a new feature request for it to be implemented on server/proxy side if you guys think its not a fit in this request.

Adding a few more comments:

• on Zabbix training (from 2.0 to 5.0 that I participated in), we see as good practice to add proxies even if you don't need them just yet. The point is that it reduces load on server, its easier to expand and provides additional capabilities to maintain Zabbix server and not loose data. In the long run, its the only way to distribute and grow Zabbix installations. So it's an additional overhead but a needed one if you are monitoring an IT environment.
• I just realized that the original feature request does asks for a web scenario or http agent implementation. So, I think we can improve on the subject at hand.

Looking forward for your reply.

Kind regards

yet another agent2 item - web.certificate.get[host], similar to web.page.get[]

It is funny to hear, because web.page.* items weren't even capable of SSL until very recently (see ZBXNEXT-287). If I get dates/versions right, HTTP Agent (ZBXNEXT-4358) was implemented before web.page.* became aware of HTTPS. This timeline makes me think that there are very few users in need of HTTPS monitoring who are still using agent's web.page.* items, they all must have switched to HTTP Agent as soon as it became available.

Zabbix repeatedly communicated that both of the agent implementations will be equal going forward.
Will this feature be added in the C agent as well?

In any case, having it on the agent seems like a mistake. Server/proxy level would be the usable one, otherwise it will be easier to reimplement the functionality as external checks, trapper items or whatever.

richlv wrote:

In any case, having it on the agent seems like a mistake. Server/proxy level would be the usable one, otherwise it will be easier to reimplement the functionality as external checks, trapper items or whatever.

I'm absolutely agree.

Additionally, I'd like to support fpaternot who reminded that the initial problem definition for this task (see Description field) was about Web-scenario or HTTP agent, i.e. server-side checks (Zabbix server or Zabbix proxy). A possibility to perform the agent-side checks could be a pleasant addition, but not a replacement for the server-side checks.

If Zabbix SIA does not change its mind and if there is sufficient demand I can probably develop a libcurl-based loadable module. If it happens, it will be possible to use it with server/proxy as Simple check or with old agent (not agent2) as Zabbix agent or Zabbix agent (active).

Disclaimer: I have not yet figured out how to package modules, so there will likely be some manual compilation involved (like that, no rocket science).

+1 for the arguments of fpaternot I dislike the fact, that this feature was implemented, without the original request in mind. We already have Web scenarios and http agent via proxies, now we have a third way. This is not logical.

Dear all, thanks for your feedback and criticism. I still believe this change will benefit many Zabbix users running Agent2, but I also understand there are use cases and constraints that may require alternative approaches. If you find that this solution is not applicable in your environment please feel free to add ZBXNEXTs with your proposals, as the certificate validation doesn't have to be an "either-or" feature.

With all due respect Kalimulin: But this is disrespectful towards Aldevar. This very request here ZBXNEXT-5931 is very clearly about adding a cert vadility check for web-scenarios and/or HTTP Agent. It was Zabbix SIA decision, to bring up a whole different solution. And now it's our part, the community, to create a new ZBXNEXT and collect votes from scratch, although we have 34 votes here?

IMHO Zabbix company should've created a fresh ZBXNEXT for the Agent2 approach, and let our ZBXNEXT untouched with all its votes. Now this ZBXNEXT will be closed, although no solution was provided, and we stay here, with empty hands, despite the 34 votes.

This is totally unfair regarding this community request. Not happy.

Ps.: To make this clear: I'm not unhappy about the new feature. I like the new feature. I'm unhappy about hijacking this ZBXNEXT and implementing something else, which was not the initial request and then closing it and then requesting us to start from scratch.

Dear starko, fpaternot, richlv, constantin.oshmyan, Voters and Watchers!

The work on loadable module has started. Feel free to join discussion on specification.

The specification for agent2 seems fine, the issue we seem to have in common is that we expect it to be available for Zabbix server monitoring (and proxy as usual), not the agent.

Discussed with Kalimulin to keep this ticket open for for server/proxy (web scenarios) implementation. Implementation for agent close in ZBXNEXT-6708. Therefore move merge comment into ZBXNEXT-6708 and close it as fixed. ZBXNEXT-5931 will be reopened and discussion continues. 

Discussed with Kalimulin to keep this ticket open for for server/proxy (web scenarios) implementation. [...] ZBXNEXT-5931 will be reopened and discussion continues.

Thank you, a wise decision!

This time I fully agree with the community that requested is one thing, but the implementation is quite different what was asked. As it requires additional resources, configuration and deployment on the monitored environment, which was not necessary until now. Imagine if its infrastructure is huge. It takes a very large amount of work to do this with this solution of Agent2.

Thanks so much for listening palivoda! Hope this issue will be solved sometime in the future, with Web-Scenario or HTTP-Agent in mind.

Hi all!

Please check out a loadable module implementing web.certificate.get for server/proxy and old agent. Your feedback is very much appreciated! Feel free to drop questions in discussions, report issues and propose changes.

Hello,

I see certificate like web scenario : an object, linked to a host with some automatics items :

• Date of "start"
• Date of expiration
• Serial number
• Authority's names
• Protocols available (TLS1.1, TLS 1.2, ...)
• Revocation status
• Maybe size of public key, cipher, etc...

Be careful, certificate are not only for web, you can have certificate for SMTP, OpenVPN, etc.

A page like that SSLChecker https://github.com/pernodpepper/SSLChecker

May I ask whether this implemented feature also covers SNI?

Many people have LBs which are also terminating the TLS on HTTPs sessions, reverse-proxying to normal http/fpm/whatever backends. They are service multiple sites using multiple certs. It is very important to be able to request a specific host's certificate from the LB, otherwise this feature will be limited to simply monitoring the default host's certificate.

phoemix, yes, it does support SNI.

I'm confused as to how this agent2-based check would work.  If I have 2 sites I want to check (www.google.com, www.aws.com) how would I set this up in Zabbix?  I don't have agents running on those sites.  How would I add 2 checks (one for each site) to be run by a single agent?  Do I now need to stand up multiple VM's each running an agent to check each site's certificates?

Gavin you only need to add a host for each website, all monitored by the same agent2 deployed (in localhost or monitored by proxy). Change the template inherited macros of each host to monitor the websites.

highpeak You can install Zabbix server module https://github.com/i-ky/sheepskin and monitor these without an agent.