-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connection to Lets Encrypt secured server fails #445
Comments
Yeah, pretty crazy that it's doing that. Our fix was the following mokeypatch: require 'httpclient'
class HTTPClient
alias original_initialize initialize
def initialize(*args, &block)
original_initialize(*args, &block)
# Force use of the default system CA certs (instead of the 6 year old bundled ones)
@session_manager&.ssl_config&.set_default_paths
end
end |
Building off of @jhollinger, just calling client.ssl_config.set_default_paths without overriding the constructor seems to work
|
Just an FYI: this gem is a dependency for Rack::OAuth2.http_config do |c|
c.ssl_config.clear_cert_store
c.ssl_config.cert_store.set_default_paths
end |
Our application also uses WebFinger.http_config do |c|
c.ssl_config.clear_cert_store
c.ssl_config.cert_store.set_default_paths
end |
Thanks all, based on @jhollinger 's suggestion we hacked the library directly: livelink@c1b97a7#diff-2a6765023b9beb8295399d5c04286045360ce90aabfffead2dba5c2c3ef71173 |
Just FYI, the monkey patch is an ruby 2.3+ feature set. Not that I'm suggesting httpclient should specifically support ancient versions of ruby out there, it is worth noting that this gem has been fundamental since the days or rails 2, which love it or hate it still exist out there in the wild. For those coming across this and looking to fix a certificate error on an unsupported version of ruby, the problem you will be tripping over will be the &. (safe operator) littered through the patch.
Thinking about this (as we've had to patch some pre ruby 2.3 legacy code), you shouldn't need the safe operator, as the @ssl_config attribute should already be setup by the time you get to the end of the constructor anyway. |
* Workaround for old CAs in httpclient See nahi/httpclient#445. The default implementation uses a list of CAs from 2015, and resetting it to use default paths uses CA certificates from the underlying OS. * Refactor for rubocop/readability * Set proxy argument to nil Co-authored-by: Carlgo11 <[email protected]>
We had the same thing. OpenIDConnect.http_config do |c|
c.ssl_config.clear_cert_store
c.ssl_config.cert_store.set_default_paths
end
Rack::OAuth2.http_config do |c|
c.ssl_config.clear_cert_store
c.ssl_config.cert_store.set_default_paths
end
WebFinger.http_config do |c|
c.ssl_config.clear_cert_store
c.ssl_config.cert_store.set_default_paths
end |
Is this lib even actively maintained? There's not much commit activity at all. I've rarely seen anyone use |
It might have got hidden in the references above, but thanks to @nov there are now new versions of |
Something else brought me to here, but yeah, this is pretty bad. It would be super hard to update properly. The dependency to version 2.8.3 comes from google-apis-core (0.3.0), but there are some other gems depending on even older versions. We are using omniauth_openid_connect 0.3.5 (June 7, 2020), which uses openid_connect ~> 1.1 (March 23, 2017), which uses webfinger >= 1.0.1 (December 22, 2014), which uses httpclient >= 2.4 (June 8, 2014). The patch contributed here #2930 seems to be the best choice right now. Although it may need to be extended. We are looking into it |
The `httpclient` gem uses a CA certificate bundle from 2015 (as of version 2.8.3), see nahi/httpclient#445. When the Let's Encrypt root cert expired recently, this gem started failing SSL handshakes, because the CA bundle it was using did not contain an alternate trust path. Calling `set_default_paths` on the client's SSL store causes it to load the certs shipped with the Ruby runtime being used to execute dropsonde. In most cases, these certs will be more up-to-date, and should allow the connection to succeed. This is definitely true when running with puppet-agent's Ruby. With Windows system Ruby, this won't be sufficient. Recommended workaourn is to use puppet-agent's Ruby on Windows if possible.
This appears to have affected Thread first indicating the issue with apt-listbugs |
The `httpclient` gem uses a CA certificate bundle from 2015 (as of version 2.8.3), see nahi/httpclient#445. When the Let's Encrypt root cert expired recently, this gem started failing SSL handshakes, because the CA bundle it was using did not contain an alternate trust path. Calling `set_default_paths` on the client's SSL store causes it to load the certs shipped with the Ruby runtime being used to execute dropsonde. In most cases, these certs will be more up-to-date, and should allow the connection to succeed. This is definitely true when running with puppet-agent's Ruby. With Windows system Ruby, this won't be sufficient. Recommended workaround is to use puppet-agent's Ruby on Windows if possible.
Change-Id: I0bd8e66a77ab0a9830a793f98ff39f89c6045dae Reference: nahi/httpclient#445
The HTTPClient gem has a really dated trust store, so we know use the OS' default one. See nahi/httpclient#445
This issue was fixed in debians version of the package here, and like this: https://salsa.debian.org/ruby-team/ruby-httpclient/-/commit/542849f1b60e9c0cd24c328ad710b2a94cb42729 |
@nahi no action on this in over ayear may lead me to abandon HTTPClient, when I otherwise rather like it. :( |
If the host app is passing in a HTTPClient instance, this won't effect it. But that's probably a rarely used feature, and the host app is responsible for configuring the HTTPClient similarly in that case. Otherwise, tell HTTPClient to _not_ do it's insane default of using a 6-year-old cert package, but just to use the cert package on the OS. The bundled with HTTPClient cert package no longer works with letsencrypt certs. This change should resolve that for people using standard defaults. If someone really needs the old behavior, they can set setting `"solr_json_writer.use_packaged_certs"` to `true` or `"true"`. Just in case there's some edge case reason this change could break things and someone would need to go back to previous behavior. I am comfortable releasing this change in a minor release, considering it a bugfix. Ref #285 and nahi/httpclient#445
Is there any update or timeline when this issue can be released ? |
OMG this library uses a built-in list of CA certificates from 2015: π© π€¦ββοΈ
My quick fix for Debian/Ubuntu:
ln -sf /etc/ssl/certs/ca-certificates.crt $rubydir/2.7.0/gems/httpclient-2.8.3/lib/httpclient/cacert.pem
The text was updated successfully, but these errors were encountered: