Dropbox api server certificate changes

[rkennewell]

Dropbox certificate changes

Can anyone tell me if this applies to the Ruby api?

[b-integrated]

For what it's worth, but obviously take with a grain of salt...

The short answer is “very unlikely.”
Dropbox’s upcoming switch to a new root CA only breaks client libraries that embed (“pin”) the old root certificate in their code — chiefly the official Java, .NET and Python SDKs called out by Dropbox itself (dropbox.tech).
dropbox_api is a third-party Ruby gem that doesn’t pin any certificates: it uses the Faraday HTTP library (see its runtime dependency list) (rubygems.org, rubygems.org), and Faraday in turn delegates TLS to Ruby’s standard Net::HTTP. By default:

• Faraday leaves ssl.verify enabled (it inherits VERIFY_PEER) (github.com, rubydoc.info).

• Net::HTTP trusts whatever root certificates your operating system / OpenSSL store provides; it doesn’t bundle its own CA set or pin any roots (docs.ruby-lang.org, docs.ruby-lang.org).

Because there is no pinned root to update, dropbox_api will continue to connect as long as the host machine’s CA bundle knows Dropbox’s new root.

---

1 What Dropbox is changing

• On or after 1 January 2026 Dropbox will serve API certificates issued from a different root CA (dropbox.tech).

• Only SDKs that hard-code the outgoing root list (Java ≥7.0.0, .NET ≥7.0.0, Python ≥12.0.2, etc.) need upgrades; other clients “may or may not” be affected depending on their own pinning strategy (dropbox.tech).

---

2 How dropbox_api handles TLS

Layer	What it uses	Relevant evidence
Gem code	Faraday connection objects built in ConnectionBuilder (github.com)
HTTP client	Faraday’s default Net::HTTP adapter	Faraday example code shows ssl.verify true unless explicitly disabled (github.com, gist.github.com)
TLS verification	Ruby Net::HTTP	When use_ssl = true, default verify_mode = OpenSSL::SSL::VERIFY_PEER (checks the full chain against the system store) (docs.ruby-lang.org)

---

5 Bottom line

Unless you or your infrastructure has deliberately pinned the old Dropbox root certificate, the dropbox_api gem will handshake with Dropbox seamlessly after the 2026 rotation. Simply keep your runtime and CA certificates updated and you’re all set.

The short answer is **“very unlikely.”** Dropbox’s upcoming switch to a new root CA only breaks client libraries that **embed (“pin”) the old root certificate** in their code — chiefly the official Java, .NET and Python SDKs called out by Dropbox itself ([[dropbox.tech](https://dropbox.tech/developers/api-server-certificate-changes?utm_source=chatgpt.com)][1]). `dropbox_api` is a third-party Ruby gem that **doesn’t pin any certificates**: it uses the Faraday HTTP library (see its runtime dependency list) ([[rubygems.org](https://rubygems.org/gems/dropbox_api/versions/0.1.21?utm_source=chatgpt.com)][2], [[rubygems.org](https://rubygems.org/gems/dropbox_api/versions/0.1.15?locale=de&utm_source=chatgpt.com)][3]), and Faraday in turn delegates TLS to Ruby’s standard `Net::HTTP`. By default:

• Faraday leaves ssl.verify enabled (it inherits VERIFY_PEER) ([github.com]4, [rubydoc.info]5).
• Net::HTTP trusts whatever root certificates your operating system / OpenSSL store provides; it doesn’t bundle its own CA set or pin any roots ([docs.ruby-lang.org]6, [docs.ruby-lang.org]7).

Because there is no pinned root to update, dropbox_api will continue to connect as long as the host machine’s CA bundle knows Dropbox’s new root.

---

1 What Dropbox is changing

• On or after 1 January 2026 Dropbox will serve API certificates issued from a different root CA ([dropbox.tech]1).
• Only SDKs that hard-code the outgoing root list (Java ≥7.0.0, .NET ≥7.0.0, Python ≥12.0.2, etc.) need upgrades; other clients “may or may not” be affected depending on their own pinning strategy ([dropbox.tech]1).

---

2 How dropbox_api handles TLS

Layer	What it uses	Relevant evidence
Gem code	Faraday connection objects built in ConnectionBuilder ([github.com]8)
HTTP client	Faraday’s default Net::HTTP adapter	Faraday example code shows ssl.verify true unless explicitly disabled ([github.com]4, [gist.github.com]9)
TLS verification	Ruby Net::HTTP	When use_ssl = true, default verify_mode = OpenSSL::SSL::VERIFY_PEER (checks the full chain against the system store) ([docs.ruby-lang.org]6)

Nowhere in the gem, its Gemfile, or its source tree is there a bundled .pem, hard-coded fingerprint, or VERIFY_NONE override. That means the OS CA store is the single source of trust.

---

3 Why the gem is (almost certainly) safe

• No root pinning ⇒ nothing internal will reject Dropbox’s new chain.
• Peer verification stays on ⇒ security is preserved; you just need an up-to-date CA bundle.
• Faraday / Net::HTTP already survive other CA rotations for hundreds of HTTPS services every year; Dropbox’s change is no different.

The only scenarios in which you could still have issues are:

1. Very old runtimes (e.g., Ruby linked against an ancient OpenSSL that lacks the new root).
2. Manually overridden TLS settings (e.g., you set ssl[:ca_file] to a custom bundle that pins the old root, or you copied code snippets that set ssl.verify = false and later flip it back) ([stackoverflow.com]10).

---

4 Practical recommendations

Step	Why
Upgrade to the latest released gem (0.1.21, March 2022) and keep Faraday ≥0.17 if possible ([rubygems.org]2)	pulls in newer Net::HTTP/Faraday bug-fixes
Keep your OS/OpenSSL CA store current (e.g., apt-get install ca-certificates, brew update && brew upgrade)	new root will already be trusted by modern CA bundles
Audit custom SSL options in your codebase or initializers for ssl[:verify], :ca_file, VERIFY_NONE, etc.	avoid accidental pinning or disabled verification
Run an early integration test against Dropbox’s sandbox endpoints periodically; if a TLS failure appears, you have time to patch your container/base image	proactive check

---

5 Bottom line

Unless you or your infrastructure has deliberately pinned the old Dropbox root certificate, the dropbox_api gem will handshake with Dropbox seamlessly after the 2026 rotation. Simply keep your runtime and CA certificates updated and you’re all set.