with ssl certificate fails to verify

[betelgeuse]

with config.secure = true I get:

rake aborted!
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:586:in `connect'
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:586:in `connect'
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:553:in `do_start'
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:542:in `start'
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:1035:in `__request__'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rest-client-1.6.1/lib/restclient/net_http_ext.rb:17:in `request'
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:845:in `post'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/airbrake-3.0.4/lib/airbrake/sender.rb:44:in `send_to_airbrake'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/airbrake-3.0.4/lib/airbrake.rb:134:in `send_notice'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/airbrake-3.0.4/lib/airbrake.rb:110:in `notify_or_ignore'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/airbrake-3.0.4/lib/airbrake/rails/action_controller_catcher.rb:17:in `rescue_action_in_public'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/airbrake-3.0.4/lib/airbrake/tasks.rb:50:in `rescue_action'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/actionpack-2.3.11/lib/action_controller/rescue.rb:162:in `perform_action_without_flash'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/actionpack-2.3.11/lib/action_controller/flash.rb:151:in `perform_action'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/actionpack-2.3.11/lib/action_controller/base.rb:532:in `send'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/actionpack-2.3.11/lib/action_controller/base.rb:532:in `process_without_filters'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/actionpack-2.3.11/lib/action_controller/filters.rb:606:in `process'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/airbrake-3.0.4/lib/airbrake/tasks.rb:80
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:636:in `call'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:636:in `execute'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:631:in `each'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain'
/Users/betelgeuse/.rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/gems/rake-0.8.7/bin/rake:31
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/bin/rake:19:in `load'
/Users/betelgeuse/.rvm/gems/ree-1.8.7-2011.03/bin/rake:19

This happens on both OS X and on Heroku.

[manuelmeurer]

+1 Same issue here (although I'm not sure it's Airbrake specific). I'm on Ruby 1.9.2.

[manuelmeurer]

Removing config.secure = true fixed the issue for now.

[betelgeuse]

I used ree 1.8.7.

[nick-desteffen]

+1 We are using Ruby 1.8.7 on EngineYard AppCloud

[nirvdrum]

Confirmed as an issue. My guess is the intermediary chain certs weren't installed. The Comodo EssentialSSL ones aren't installed by default on any server configuration that I'm aware of.

Simpler case illustrating issue:

http = Net::HTTP.new('airbrakeapp.com', 443)

http.use_ssl = true
http.ca_file = OpenSSL::X509::DEFAULT_CERT_FILE if File.exist?(OpenSSL::X509::DEFAULT_CERT_FILE)
http.verify_mode = OpenSSL::SSL::VERIFY_PEER

http.get('/')

OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
    from /usr/local//rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:586:in `connect'
    from /usr/local//rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:586:in `connect'
    from /usr/local//rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:553:in `do_start'
    from /usr/local//rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:542:in `start'
    from /usr/local//rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:1035:in `__request__'
    from /mnt/mogotest-production/shared/bundle/ruby/1.8/gems/rest-client-1.6.1/lib/restclient/net_http_ext.rb:17:in `request'
    from /usr/local//rvm/rubies/ree-1.8.7-2011.03/lib/ruby/1.8/net/http.rb:772:in `get'
    from (irb):5

This is on an Ubuntu 11.04 machine.

[Fitzsimmons]

What's the status on this? I would have thought that this was a very simple issue to fix. Have thoughtbot been notified that their certificates are bad?

[jyurek]

Sorry about the delay, everyone. We're looking into this now and will keep you posted.

[skippy]

+1 as well.... disabling in production for now.

Jyurek, this is a bit off topic, but the stack trace caused me to look through the code and I noticed that airbrake notify will wait for up-to 5 seconds, holding up the thread, while it sends a msg. Why isn't that multi-threaded? This error causes any time hoptoad is triggered to cause an exception on the app rather than continuing on and failing silently (perhaps putting an error in the logs). Shouldn't the ideal behavior be that if hoptoad fails that it does so without taking down the app?

thanks

[airbrakeben]

Hi All,

Sorry for the delayed response. We take security very seriously and want to get this fixed ASAP. I have been assigned this issue and I'm working with our hosting provider to solve it.

This is the response from our hosting provider.

---

Hi Ben,

We took a look at your SSL certificate and everything is looking good on our side, we installed the key on July 15th and we have not changed it since then. Our file includes the entire SSL chain.

We did verify your SSL certificate with an external source and they report that the chain is fine: http://www.sslshopper.com/ssl-checker.html#hostname=airbrakeapp.com

I ran the same code that your Github user used on a CentOS release 5.6 server and it worked fine. Can you please have the user add a puts line like the one following so we can see where their default certificate file lives?

http.use_ssl = true http.ca_file = OpenSSL::X509::DEFAULT_CERT_FILE if File.exist?(OpenSSL::X509::DEFAULT_CERT_FILE)

puts(http.ca_file) http.verify_mode = OpenSSL::SSL::VERIFY_PEER

We took a look at the default certs on a Ubuntu 11.04 machine (stored in /etc/ssl/certs/ca-certificates.crt) and the last certificate in your chain is included in the Ubuntu distribution, so we do not know why that code would be failing on the Github user's machine unless they were pointing at a different default certificate file. Or there is a chance that some parts of your chain have been revoked.

We did notice that the chain is quite long, and there have been compromised Comodo certificates that were revoked earlier in the year. You may want to consider purchasing a certificate from another authority.

---

We are going to be contacting EssentialSSL; to see if they can fix an issue with the chain. We don't believe the comodo certificate was revoked.

I hope to have this issue solved by the end of the week. If you feel it's not getting the correct attention please contact support@airbrakeapp.com

[shedd]

Any news on this? I just upgraded our entire app, to switch from the Hoptoad gem to the Airbrake gem and hit this.

[airbrakeben]

Hi Shedd & Everyone,

I finally got a reply from our SSL cert provider at DNSsimple, some clients will have removed the Comodo intermediary certificate from their systems, either on purpose or through an upgrade, due to the fact that there were issues with certain Comodo certificates being compromised. Our specific certificate wasn't compromised, but Comodo seems to be blocked by some providers. I'm going to work with our hosts at bluebox.net to update our certificate today. I expect this issue to be resolved within 24hrs.

[airbrakeben]

We've updated the SSL certificate on http://www.airbrakeapp.com http://www.digicert.com/help/index.htm?host=airbrakeapp.com&order_id=00262636 It looks Ok from our end, but can someone else please check that the're still having issues?

[skippy]

still failing on Airbrake 3.0.4...checking updated version now (ed: with a fresh restart)

[skippy]

yep, still failing (no new gem released so still using 3.0.4). I've tried rake airbrake:test on our dev(osx & ubuntu), staging(ubuntu), and test(ubuntu) servers

[shedd]

I am also still seeing the same certificate validation failure:

rake aborted! SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

[skippy]

https://gist.github.com/1299824

[airbrakeben]

Thanks for double checking @shedd and @skippy. I'm escalating this issue within our team. More updates to come.

[shedd]

Based on the replies on the Airbrake support forum, it seemed like this might only apply to error reports being sent to https://airbrakeapp.com I tried configuring my config.host setting to hoptoadapp.com and airbrake.io and got the same error with those hostnames, too, which was surprising. We haven't seen this issue with the Hoptoad gem, which is still running in our production environment. Is there a code issue in the Airbrake gem associated with this cert issue? The output from those tests are here: https://gist.github.com/1299851

[shedd]

Rather than rollback our upgrades from the Airbrake gem to the Hoptoad gem, I came across this post

http://jimneath.org/2011/10/19/ruby-ssl-certificate-verify-failed.html

Following the instructions of the post and including the CRT bundle + the SSL fix initializer into our Rails 2.3.14 application allowed the Airbrake test task to succeed from our staging environment without issue. Hopefully this helps anyone else that needs to remain on SSL but resolve this issue quickly!

[skippy]

hey @shedd, I saw this too, but the approach bothered me for two reasons:

• the source of the ca.crt that is in that link is totally unverified; it could contain bad certificates, etc. You can go through and create your own directly from a certified repository but I wouldn't use that one in the link.
• this approach stabilizes the ca cert, but it also means that if there is a breach, and the CA cert on your server is updated but your app is not, your app will happily continue to send data using a potentially black-listed CA. Perhaps that is OK for hoptoad stuff (I would argue not; if you need SSL then it should be valid ssl) but this hack makes the change universal for all uses of SSL, so anytime you make an authenticated ssl backed call you will be exposing the datastream to sites using potentially black-listed CA's.

I'm not a security expert (ah, how we all say that, yet here we are!), but this solution seems just as bad as the previous one that hit the ruby community, which had code examples with VERIFY::NONE

[shedd]

@skippy - certainly very good points, thanks, especially around the source of the cert file. The source of the link is actually the cURL distribution site, so seeing that it wasn't a total unknown gave me enough comfort to test it, but you are right to point out the potential security issues with this approach. (The cURL site also provides a script to build a similar file out of your own Firefox install (http://curl.haxx.se/docs/caextract.html -- more info: http://curl.haxx.se/docs/sslcerts.html).) In any case, as you point out, this isn't a good production strategy - hopefully, we'll see a permanent fix from the Airbrake folks shortly.

[skippy]

ahh! Thanks @shedd; I hadn't taken a close look at the url.

but the fact that it worked for you in a test environment does seems to confirm the underlying issue, which is an SSL cert from a black-listed ca?

[shedd]

@skippy - given that the test worked, yes, it does seem to confirm that the issue is the CA for the cert. Apparently Airbrake just switched their cert again, per the ticket on the Airbrake support site: http://help.airbrake.io/discussions/problems/2066-update-on-ssl-certificate-validation-failure However, it still didn't work for me. Quite a perplexing issue.

[skippy]

it doesn't look like their certificate is setup properly... but the problem is I don't know enough about ssl to pinpoint what that error is... some common ones might be having a CA with a password or an expired cert, but not sure.

Anyway, I updated my gist with the openssl --showcert output for airbrake.io: https://gist.github.com/1299824

update: hmmm..this might be a red herring; the hoptoadapp.com returns the same sort of error (-20)

[airbrakeben]

Hi @skippy and @shedd; Thanks for helping us with this issue. We're working with our hosts at http:///www.bluebox.net to make sure it's correctly setup on their servers. Thank you for your patience.

[airbrakeben]

Hi @skippy & @shedd . We've been onto our new SSL provider. We now have an intermediate certificate cross-signed by Entrust.net. Can you please re-run your tests, and let me know the outcome. Our hosts at www.bluebox.net saw this issue resolved after they installed this certificate. I'm leaving this ticket open until I get confirmation that it's working across all machines.

[skippy]

@airbrakeben, which domain should we be testing against? airbrake.io routes to an IP, but that IP doesn't exist anymore... so are we back to airbrakeapp.com?

[skippy]

@airbrakenben, have you tried rake airbrake:test? It is still failing for me

[airbrakeben]

@skippy airbrake.io still points to http://208.85.144.248/ . Certificates on airbrakeapp.com and airbrake.io have been updated. Feel free to add me on IM for more support ben@airbrakeapp.com

[shedd]

I just tried it again. It's still failing for me.

[airbrakeben]

@skippy Are you using a directory that contains trusted root certificates from all the CA's? Or are they using a specific trusted root? What is your DEFAULT_CERT_FILE if DEFAULT_CERT_FILE is a file, it needs to be a file that contains the Entrust.net trusted root. If it is a directory, it needs to be a directory that includes the Entrust.net trusted root and has been properly hashed.

[skippy]

hey @airbrakeben,

ah!!! So on my 10.6 system (I'm behind one security patch...mum's the word), it fails. However, my coworkers who are all on 10.7 reported no problems and things work like a charm on our dev, testing, and staging servers on EC2. I wonder if I have a cached certificate somewhere? I definitely don't do the DEFAULT_CERT_FILE hack thing, so that isn't it.

But I'm glad that it is working for everyone else in the office! ;)

@airbrakeben, thank you for your help

[marcweil]

Any more movement on this? This issue is preventing us from pushing to production, and I'd rather not have to hack the setups of each of our servers with the suggestions in this thread involving custom cert lists and the like.

We are running Ubuntu 11.04 on EC2 with all the latest security updates.

[skippy]

damn; it is failing again. sigh.... I'll ask people at the office to test again but on the staging and test servers, where it passed 3 days ago, it is now failing. At the time of pass I didn't grab the trace for rake airbrake:test or openssl s_client -connect airbrake.io:443 -showcerts, so I'm not sure if the certificate changed back or not.

can anyone get this to work? I feel like I"m going nutz here.

[marcweil]

Okay update: I did finally get this working. Someone mentioned this link above, but I'll mention it again: http://jimneath.org/2011/10/19/ruby-ssl-certificate-verify-failed.html.

I just made the initializer pretty much exactly the same as this guy did except I used my Ubuntu distro's default cert bundle (at /etc/ssl/certs/ca-certificates.crt) instead of the custom one he made. Now it seems that all is well in the world.

For posterity, here's the contents of my entire initializer located at config/initializers/ssl.rb: https://gist.github.com/1311255

[thbar]

Hi,

I just did a test today, as I'm migrating to airbrake.io domain and I get the same error:

Airbrake.notify(:error_class => 'Test', :error_message => 'Hello')

The output is:

OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

[airbrakeben]

Hi All,

I'm working with our team here to come up with a comprehensive solution for this issue. I will update this issue before Friday.

Ben

[thbar]

@airbrakeben thanks! Good luck :)

[usiegj00]

All--looking at best practices here, we're seeing that many gems package a set of canonical certificates to feed to OpenSSL to ensure the SSL chain validates regardless of the certs installed on a given machine. This seems like a kluge at first, but we're now leaning towards it. We are going to wrap this into the next release to use a bundled certificate chain by default. Please comment here (+1/-1 OK).

[imajes]

i think this is a bad idea; much better is a howto for users to implement themselves (a wiki page) and also better handling of the verify error; saving the error locally/emailing someone, catching that exception and issuing a logger notice.

[betelgeuse]

Ruby is the only programming language that I have noticed having these problems so there must be a clean way to solve this. How do python or C programs solve this issue?

[imajes]

it may be that the ruby library is more stringent about certs; certainly this changed recently as more understanding and knowledge as to how they work came about... and the py/c programs are all doing verify_none (or similar..)

On Wed, Nov 2, 2011 at 14:54, Petteri Räty reply@reply.github.com wrote:

Ruby is the only programming language that I have noticed having these problems so there must be a clean way to solve this. How do python or C programs solve this issue?

Reply to this email directly or view it on GitHub: https://github.com/airbrake/airbrake/issues/17#issuecomment-2607801

[usiegj00]

@betelgeuse -- we haven't seen this to be ruby specific, but most libraries do VERIFY_NONE as James suggested. Almost unanimously all languages use the openssl lib which you can try on the command line with: openssl s_client -connect airbrake.io:443 -showcerts

@imajes -- Hey James! How's London? Jonathan here... the SSL issue is becoming our most-frequent support inquiry and we spend a lot of time debugging user certs that have never been updated (in the system). Often this is not in the developer's control in production. A correctly updated distro will not have an issue with our previous code, but the new code simply bundles a mature cert chain. Since it's us on both ends of the connection it's valid to trust our authentication method for our cert identity. In case you want to regenerate and validate the cert chain yourself, see the resources/README.md file.

Any other specific concerns?

[imajes]

Jonathan: ping me on im?

On Wed, Nov 2, 2011 at 15:09, usiegj00 reply@reply.github.com wrote:

@betelgeuse -- we haven't seen this to be ruby specific, but most libraries do VERIFY_NONE as James suggested. Almost unanimously all languages use the openssl lib which you can try on the command line with: openssl s_client -connect airbrake.io:443 -showcerts

@imajes -- Hey James! How's London? Jonathan here... the SSL issue is becoming our most-frequent support inquiry and we spend a lot of time debugging user certs that have never been updated (in the system). Often this is not in the developer's control in production. A correctly updated distro will not have an issue with our previous code, but the new code simply bundles a mature cert chain. Since it's us on both ends of the connection it's valid to trust our authentication method for our cert identity. In case you want to regenerate and validate the cert chain yourself, see the resources/README.md file.

Any other specific concerns?

Reply to this email directly or view it on GitHub: https://github.com/airbrake/airbrake/issues/17#issuecomment-2607996

James Cox, Consultant, Raconteur, Photographer, Entrepreneur t: +1 347 433 0567  e: james@imaj.es w: http://imaj.es/ talk: http://twitter.com/imajes photos: http://flickr.com/imajes

[skippy]

is bundling the cert chain a security concern? What if I happen to put my own CA in there, and then I can release certificates for google.com, etc?

I'm not sure if that is a valid concern, but it pops out to me as the big security question here; you are telling ruby here is a trusted CA, but when in fact it is not trusted at all anymore (sure, I could trust you guys, but what about some other plugin, etc...? I should be able to trust the distro source, but probably not anyone else).

please let me know if I'm barking up the wrong tree.

@usiegj00; airbrake fails on engineyard; I've tried to ring them twice on this issue and I've gotten zero response from them (color me frustrated). But I imagine many of your complaining customers, like me, are on their platform.

[imajes]

Yep. It's security via obscurity. Developers won't know that has happened, so it's the same as not having a cert at all, since i don't control any part of the chain. And as mentioned, it's worse if there is a breach and that cert has to get revoked. Since this cert would be loaded into rails, is it possible that it would 'infect' other ssl using apps?

-james

On Wed, Nov 2, 2011 at 15:35, Adam Greene reply@reply.github.com wrote:

is bundling the cert chain a security concern?  What if I happen to put my own CA in there, and then I can release certificates for google.com, etc?

I'm not sure if that is a valid concern, but it pops out to me as the big security question here; you are telling ruby here is a trusted CA, but when in fact it is not trusted at all anymore (sure, I could trust you guys, but what about some other plugin, etc...?  I should be able to trust the distro source, but probably not anyone else).

please let me know if I'm barking up the wrong tree.

@usiegj00; airbrake fails on engineyard; I've tried to ring them twice on this issue and I've gotten zero response from them (color me frustrated).  But I imagine many of your complaining customers, like me, are on their platform.

Reply to this email directly or view it on GitHub: https://github.com/airbrake/airbrake/issues/17#issuecomment-2608352

[skippy]

@imajes, from what I've seen it is a global constant as well as local; the key is not setting the global one (as some websites recommend) as it will be set for every ssl call made from ruby; that seems pretty darn scary.

@uiegj00, what about creating a wiki like so: https://github.com/intridea/omniauth/wiki/Setting-up-SSL-certificate-locations-in-Linux, and having code like this (in sender.rb ~ ln37):

if File.exist?(OpenSSL::X509::DEFAULT_CERT_FILE)
  http.ca_file     = OpenSSL::X509::DEFAULT_CERT_FILE 
  http.verify_mode = OpenSSL::SSL::VERIFY_PEER
else
  Airbrake.write_verbose_log("SSL is enabled but the default certificate file '#{OpenSSL::X509::DEFAULT_CERT_FILE}' was not found on your system.  Please read http://DOCUMENTATION_LINK to enable tighter airbrake security")
end

and then call it good? That way it will still have SSL, it informs the user as to the root problem, but also allows it to continue on. A fair trade?

[usiegj00]

@imajes/@skippy--I don't think we are setting any global changes. Try this:

require "rubygems"
require "net/http"
http = Net::HTTP.new("google.com")
puts http.ca_file
http.ca_file = "resources/ca-bundle.crt"
puts http.ca_file
http2 = Net::HTTP.new("google.com")
puts http2.ca_file
puts http2.ca_file == http.ca_file

Also--it's not security through obscurity. The reason to validate Airbrake's cert is to avoid a man-in-the-middle attack. Say your DNS is hacked and sent to another server--we use cert identity verification to make sure you are connected to the Airbrake proper. In this change we've bundled a current cert chain. If you think about it--it's us saying trust us. And more than that, if you don't trust us, you can validate we're using a current cert chain by following our build instructions here and ensuring our method for building the cert chain:

https://github.com/airbrake/airbrake/tree/master/resources

We are not opposed to adding warnings or even more options to the configuration, but feel the current security model is impeccable under scrutiny. Please continue to give your feedback!

[skippy]

fair enough. thanks @usiegj00

[skippy]

@usiegj00; a bit of a silly question, but I ask only if you know off the top of your head; how can I get my servers to correctly load the CA cert from the linux server into ruby?