The Comms Room

« first day (1669 days earlier) ← previous day next day → last day (3327 days later) »

6:22 AM

Q: ELK stack cluster health yellow and Kibana doesn't work

I am trying-out installing and setting up ELK stack on AWS. However I'm having trouble with Logstash and Kibana. I currently have 2 Elastic search instances and they are load balanced and working well. However, when I hit http://load_balance_url:9200/_plugin/head/, I get the following result: ...

Can anyone answer this question plz?

Jenny D

6:55 AM

@EnglishMaster You'll need to include the server logs, they'll show why the server is responding with a 500 error. Usually this means that whatever script you're trying to run is failing for some reason, and that reason can only be found in the server logs.

EnglishMaster

@JennyD Ok, Im at work so I cannot get back to my AWS atm

But I'll post it here in few hours

Do you want Kibana server log?

Do you think an 500 error can occur due to security setups in my AWS?

Jenny D

7:11 AM

Since it's Kibana that's malfunctioning, that would be the right log. I'm not familiar enough with AWS security setup to give you a good answer to that question.

EnglishMaster

Right, thank you!

3 hours later…

TRiG

10:32 AM

Everything I read tells me that SSL certs are not cached. So I shouldn't be seeing what I'm seeing.

Jenny D

@TRiG It's mostly true that they're not cached.

TRiG

@JennyD I should probably put this together as a question on the main site, but I'm not sure I know enough to explain myself properly.

Jenny D

You might want to go do a search over at security.stackexchange.com first; there are a lot of cert questions there.

TRiG

I had a cert for example.net. It also protected www.example.net. It did not protect other subdomains. I have now purchased and installed a new cert for *.example.net (it also covers example.net). When I visit m.example.net, my browsers complain that they are seeing an expired cert for example.net. SSL Labs, by contrast, sees the wildcard cert and says everything is fine.

Which is just odd. I'll try sec SE.

Jenny D

This may fall under the "mostly true" exception. Do you have any webproxy in the way?

if you do ask a question, I think it'll be very hard for anyone to answer unless you use the actual site name.

Oh, also - do you by any chance have any host records pointing to e.g. a dev server that still has an old cert on it? It might be useful to check if there is actually a log entry on the actual server from the times when your browser complains about the certificate.

TRiG

10:46 AM

@JennyD m.tullamoreshow.com

Jenny D

It's still got the old cert there. Did you restart the webserver after you replaced the cert?

this is what Firefox says:

m.tullamoreshow.com uses an invalid security certificate. The certificate is only valid for the following names: www.tullamoreshow.com, tullamoreshow.com The certificate expired on 2014-04-14 04:19. The current time is 2015-04-07 12:46. (Error code: ssl_error_bad_cert_domain)

So this is obviously not a cache issue, since I'd not been there before.

TRiG

@JennyD And this is what Qualy's SSL Labs says:

Common names *.tullamoreshow.com
Alternative names *.tullamoreshow.com tullamoreshow.com
Prefix handling Not required for subdomains
Valid from Sun Apr 05 07:03:05 PDT 2015
Valid until Thu Apr 07 14:53:49 PDT 2016 (expires in 1 year)
Key RSA 2048 bits (e 65537)

I always feel a bit of a fraud on this site. I'm a programmer, not a server admin. But we don't have any sysadmins in this tiny company, so I sort of do that job. And we use Plesk. (At this stage of my knowledge, Plesk is still more helpful than annoying, but the balance is beginning to tip the other way.)

Jenny D

That's really interesting, because I get that cert when I connect from the command line with openssl. But I get the other one when using a browser.

I've never seen this happen before.

TRiG

Seeing the expired cert in both Firefox and Chromium on Ubuntu and in Chrome on Mac.

Jenny D

Yeah, I get the same thing when I try with any browser. I even tried it with Firefox from my VPS which runs FreeBSD...

TRiG

11:00 AM

I think that FF uses NSS on all platforms, while Google Chrome uses NSS on some platforms and OpenSSL on others.

Jenny D

This may be some weird Plesk thing..

I tried Safari too

TRiG

@JennyD And fixed. It was a weird Plesk thing.

Jenny D

Cool, what was it?

TRiG

I need enter the settings for each subdomain and tell it which cert to use.

Jenny D

That's... special.

TRiG

11:03 AM

(That doesn't explain why it was serving the right cert to Qualy's and the wrong one to everyone else.)

Jenny D

I think it might be some SNI thing

OpenSSL doesn't do SNI, but all modern browsers do

TRiG

Possibly, but Qualy's usually puts up a big marker saying "this site requires SNI support", which it didn't in this case.

(I've been bitten by that before, so I checked.)

Q: Why is site serving different SSL certs to different browsers?

The SSL certificate on menswearireland.com and on www.menswearireland.com works fine on Safari, Chrome, SeaMonkey, K-Meleon, QtWeb, Firefox, and Opera. However, Internet Explorer claims that there is an error: The security certificate presented by this website was not issued by a trusted ce...

ssl-certificate internet-explorer

There'll be a blue bar on ssllabs.com/ssltest/analyze.html?d=timothy.green.name.

Jenny D

It's definitely SNI. The thing is, if you don't use SNI, then the first VirtualHost in the list will be used. And in your case, that would be the domain that had the wildcard certificate. And since the wildcard certificate does match m.tullamoreshow.com, then SSLLabs (and openssl s_client from the command line) will get the correct cert. They would also get the wrong site content, but that doesn't show when you just check the certificate!

But when you use a browser, that uses SNI, then your server will serve the certificate for that VirtualHost - so you'd get the wrong certificate but the right content

this is a real bitch to figure out

Also, I wouldn't just blame Plesk - you'd get the same thing using a "clean" apache. But it might be easier to locate, depending on how you configure logging etc.

well, I got something interesting to work with while waiting for my client to fix my login on their system... thanks for that :-)

TRiG

@JennyD Thank you!

« first day (1669 days earlier) ← previous day next day → last day (3327 days later) »

all rooms