Issue with public Spiceworks SSL

trevorpott · 2012-10-20T03:10:53.000Z

Dear Spiceworks, I have encountered the following SSL issue with your website.

SSL.png1024×716 141 KB

StorageNinja · 2012-10-20T03:46:09.000Z

Had this a few month ago. What cert/il you showing for the domain?

trevorpott · 2012-10-20T03:56:49.000Z

It only occurs about 1/5 or 1/6 login attempts.

ssl2.png507×593 9.95 KB

trevorpott · 2012-10-20T03:57:46.000Z

Based on behaviour, it looks like one of the servers behind the load balancer on the Spiceworks public site has a bad cert.

StorageNinja · 2012-10-20T11:19:01.000Z

Yep. They also CDN content so you can get stuff like this regionaly focused on occasion.

adam-s-spiceworks · 2012-10-22T13:09:32.000Z

Thanks for flagging this for us. I’ll have our guys take a look at this and update you on what we’ve found.

kris · 2012-10-22T13:25:59.000Z

None of our application servers actually handles SSL. SSL offload occurs at our edge load balancer. This looks like you are not picking up the entire cert chain, hence the untrusted site warning.

I am looking into it now.

Bryan-Young · 2012-10-22T13:41:22.000Z

Seems like its that rouge server again…

kris · 2012-10-22T13:49:38.000Z

I am having trouble replicating this issue. I pulled the CA certs from Firefox and then fed them into curl and am able to verify the secure connection every time.

[kris@charon ssl]$ curl -I --cacert ./VeriSignClass3PublicPrimaryCertificationAuthority-G5.crt --cacert VeriSignClass3SecureServerCA-G3.crt https://community.spiceworks.com
HTTP/1.1 200 OK
Set-Cookie: ACE_COOKIE=R1442411545; path=/
Date: Mon, 22 Oct 2012 15:47:27 GMT
Server: Apache-Coyote/1.1
X-UA-Compatible: IE=Edge,chrome=1
ETag: “ebac0337b0596b2a4c1046e919a56aa8”
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: ad60e29edea74cca4f68a4694c414f7f
X-Runtime: 0.066000
X-Rack-Cache: miss
Content-Type: text/html;charset=utf-8
Set-Cookie: spiceworks-community=7BkkiD3Nlc3Npb25faWQGOgZFRkkiJTMzYThjZTZjYjBkZDVjN2Q4MGFiMjNDQzY2VmYTg4BjsAVA%3D%3D–4c1316f2f65bc6c325c501eba78ff33a59f1; path=/; expires=Tue, 22-Oct-2013 15:47:28 GMT; HttpOnly
Vary: Accept-Encoding,User-Agent
Connection: close

trevorpott · 2012-10-22T15:05:07.000Z

@Kris, bizzare. I am getting it on multiple systems on multiple networks with multiple operating systems. Consistent element is that it is always Firefox that causes it. I can’t make IE/Chrome do it.

Also: Firefox does not do it all the time, as per above.

kris · 2012-10-22T15:09:09.000Z

Hmm… we saw a similar issue once before related to the cert chain and Firefox. I am going to write up a quick script to see if I can trigger it.

kris · 2012-10-22T15:13:35.000Z

What version of FF are you using? And are you on the development release or mainstream?

trevorpott · 2012-10-22T15:16:15.000Z

Issue present in 15.0.1 and 16.0.1, both mainstream release.

kris · 2012-10-22T15:37:01.000Z

I was able to reproduce the issue using an external SSL check utility. There is a problem with the Verisign/Symantec intermediate certificate. Working on a fix now.

kris · 2012-10-22T16:03:36.000Z

I fixed the intermediate cert and we are now passing the 3rd party check utilities that we were previously failing. Please give your end a go and see if the problem has cleared up.

trevorpott · 2012-10-22T17:10:12.000Z

Passes on all browsers, all OSes, all Installs.

kris · 2012-10-22T17:51:02.000Z

Good deal. Not sure why the concatenated certs were no longer valid, but the fix was to install each intermediate cert into a cert chain, then assign that new cert chain to the SSL proxy rule on the load balancer. A relatively simple and straight-forward fix, once you can see the issue, of course.

trevorpott · 2012-10-22T18:14:38.000Z

That is pretty bizzare. Considering I rely on a similar setup - httpd with $standalone_cert.$intermediate_cert I should probably look at stuffing them into a single chain. I wonder if I can reproduce this issue on my config with Firefox. Hmmm…