Go to All Forums

"SSL certificate untrusted" ?

I'm trying to create a new SSL certificate monitor.  I'm pointing it at a client's website.  It has a valid SSL cert that will expire notAfter=Aug 19 23:59:59 2017 GMT.  I can talk to the website using `openssl s_client` and Google Chrome and Mozilla Firefox.  But when I try to create an SSL certificate monitor, I get an error message telling me I didn't configure the monitor correctly because "SSL certificate untrusted".

openssl s_client -servername ${HOSTNAME} -tlsextdebug -msg -connect ${HOSTNAME}:443 </dev/null | openssl x509  -noout -subject -issuer -dates

subject= /CN=[hostname omitted]
issuer= /C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
notBefore=Jun 21 00:00:00 2016 GMT
notAfter=Aug 19 23:59:59 2017 GMT

Why would site24x7 balking?  Is there a blacklist I should be aware of?
Like (1) Reply
Replies (12)

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.

Like (0) Reply

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)

 

Like (0) Reply

Can you try it with the Ignore trust certificate path set to Yes?

Like (0) Reply

No longer refusing; correctly reports "Valid for 138 day(s)" and shows data about the cert and GeoTrust's signing cert.

Thank you.

 

 

Like (0) Reply

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/

Like (0) Reply

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!

Like (0) Reply


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.

 

Like (0) Reply

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 [email protected], they are pretty quick.

Like (0) Reply

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:

  1. The server certificate
  2. Any intermediate certificate(s)
  3. 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.

 

Like (0) Reply

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.

Like (0) Reply

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.

Like (0) Reply

Was this post helpful?