If you are using internal pollers, we are having issues from our internal pollers:
From their support team:
AES_128_GCM is currently not supported on our on-premise pollers. As per the update from our development team, we have started working on the on premise poller upgrade to support AES_128_GCM cipher suite. It might take at least 2 months to have this developed and released. We will keep you updated on further development in this regard.
I am not using an internal poller. The signing CA is "GeoTrust", who is not one of the Blacklisted CAs mentioned in "SSL Certificate Monitor" config. I've attached my monitor config in case I did something wrong. Signature Algorithm is sha256WithRSAEncryption, signature method is ecdsa-with-SHA256
(trying to use the "insert/edit image" feature of this forum but it won't accept the *.png file screenshot, so look here instead: https://puu.sh/v8263/604bf440cd.png )
(sorry about being cagey about the hostname; it's a client and I want not to use their name publically without permission)
Can you try it with the Ignore trust certificate path set to Yes?
No longer refusing; correctly reports "Valid for 138 day(s)" and shows data about the cert and GeoTrust's signing cert.
Thank you.
You may want to look at the SSL chain. Seems there's something causing the issue somewhere along the line. I'm not an SSL expert so can't offer more help. Try this to start: https://www.digicert.com/help/
It looks correct-ish... but digicert's diagram of the certificate chain goes
"server cert: blah-da.com
intermediate cert: blah-da.com
intermediate cert: GeoTrust, Inc."
I wonder why it tells me the first two links of the chain are the same cert? It's worth investigating. Thanks!
Maybe these can help?
whatismychaincert.com says things are correct.
vanrees.org says to test it with `curl` and `wget` and python's requests module `requests.get()` ... and none of these complain.
So it's just site24x7 and //digicert.com/help/ that have trouble.
There must be something missing on the Site24x7 end then, similar to
what I experienced with the poller.
I hope they actually get to your issue soon. Have you sent in a
support request to them? I usually email support@site24x7.com, they are
pretty quick.
The most common reason for a public CA's certificates being untrusted is an improperly configured chain on the server. The server should exactly return:
- The server certificate
- Any intermediate certificate(s)
- Optionally, the root CA certificate
Some client applications are able to make do with just the server certificate as they either cache the intermediate certificates from other websites that use the same CA, or attempt to download them from the authority information embeded in the server certificate.
Site24x7 performs strict validation and requires a valid chain upto and including any intermediate certificates. They must also chain to one of the root certificates present in our key store. i.e. any root certificate in the chain is ignored.
You can safely enable the "Ignore trust" option if you manually verify the certificate details on the monitor details page after adding the monitor. We will still alert you if the certificate is modified.
Please open a support ticket to share the URL privately so that we can investigate why your certificate is untrusted.
I did find something unusual: the certs are served by a squid3 instance:
https_port 443 accel vhost options=NO_SSLv3:NO_SSLv2 defaultsite=sitename.com cert=/etc/squid3/sitename_com.sslcert key=/etc/squid3/sitename_com.sslkey cafile=/etc/squid3/sitename_com.cacert
... and the sitename_com.sslcert has a block of text that is identical to the contents of sitename_com.cacert file. But if I remove that extra copy of the cacert and try to restart squid3, it complains that the cert is invalid.
Technically the certificate chain is still valid, since the server cert depends on a valid ("intermediate") cacert that is provided, it's just provided twice. Don't know why digicert thinks it was the server cert provided twice.
Still, it's an anomaly on my part. I'll resolve that and test it again before asking for a support ticket.
There's isn't much documentation on the cafile parameter. You could try the two options below and see if one works.
1. Edit the cert file to contain only the server certificate, and edit the cacert file to contain both the intermediate certificate and the root certificate one below the other.
2. Edit the cert file to contain the entire chain one below the other, and comment out the cafile line.
You may need to download the intermediate certificate if you don't already have it. I suggest opening the website in a browser and saving the individual certificates from the padlock icon so you have a known valid chain.