nextcloud
Certificate manager fallback
- Resolves: https://github.com/nextcloud/server/issues/42464#issuecomment-1891009733 https://github.com/nextcloud/integration_google/issues/132
Summary
CertificateManager doesn't seem to work propertly if the files_external app is disabled (the files get put in /tmp for no reason I know of), so let's store directly in /data/certificate_manager the bundled certificates. This always has to be done on local disk (even with primary ObjectStorage) as curl currently requires a path to the cert bundle.
Another way of doing it would be directly using a file given by the ITempManager, but it would need rebuilding the bundle and rewriting the file after each cron call. 😱
When we require PHP 8.1 we will be able to simply store the certificate bundle in database/memory/cache and pass it through the CURLOPT_SSLCERT_BLOB option.
TODO
- [ ] adapt tests
Checklist
- Code is properly formatted
- Sign-off message is added to all commits
- [ ] Tests (unit, integration, api and/or acceptance) are included
- [ ] Screenshots before/after for front-end changes
- [ ] Documentation (manuals or wiki) has been updated or is not required
- [ ] Backports requested where applicable (ex: critical bugfixes)
Once upon a time, the whole logic was in files_external, iirc, as it started to with the support of custom CAs against file serves.
The path (and data) will be different when switching on or off files_external, right. That's a little unpredictable and confusing. When going to a different location, go fully there, and do a migration of the old data, if existing.
I can do that, yeah.
I was wondering if there was a special reason of using files_external for that in the first place, but it doesn't seem to me 5d61b85a1dace6ebb41025deaad019af8b3e5145
We are using S3 storage and see the SSL cert error due to not having files_external enabled, this PR is fantastic.
