mirror of
https://github.com/tubearchivist/tubearchivist-jf-plugin.git
synced 2026-03-23 20:37:14 +00:00
[GH-ISSUE #59] [Bug]: tubearchivist-jf-plugin does not connect to tubearchivist over https (RevocationStatusUnknown, OfflineRevocation) #45
Labels
No labels
bug
enhancement
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tubearchivist/archived-tubearchivist-jf-plugin#45
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @IeP4nieF on GitHub (Aug 11, 2025).
Original GitHub issue: https://github.com/tubearchivist/tubearchivist-jf-plugin/issues/59
Originally assigned to: @DarkFighterLuke on GitHub.
I've read the documentation
Operating System
Linux (Debian 12 in lxc-container)
Your Bug Report
Describe the bug
tubearchivist-jf-plugindoes not conect to tubearchivist due to ssl error. I run tubearchivist with a certificate from my CA. The root-certificate of the CA is installed on the host which runsjellyfin(wget https://tubearchivistURLruns fine from this host).Because of "RevocationStatusUnknown, OfflineRevocation" in the logs I added a CRL Distribution Point to the certificate of
tubearchivist:But this does not change anything. The plugin is not trying to download the CRL (shown by webserverlogs).
Steps To Reproduce
Use
tubearchivist-jf-pluginwith antubearchivist-setup which uses a certificate of your own CA.Expected behavior
The plugin should connect to the tubearchivist server and fetch metadata.
Relevant Jellyfin log output
Anything else?
No response
@voice06 commented on GitHub (Sep 9, 2025):
There definitely needs to be an option to disable these SSL integrity checks. Theres no need for that kind of security for a internal-only service.
@DarkFighterLuke commented on GitHub (Oct 23, 2025):
This is not a bug, but a feature request. Btw, I'll put it on the list :)
@IeP4nieF commented on GitHub (Oct 24, 2025):
Thank you!
(Nevertheless I would say, that one can discuss if this has to be called a bug or a feature request. The point is, that the plugin ignores the root certificates, which are installed on the host. Everyone expect a service running on a host to take into account the installed root certificates.)
@IeP4nieF commented on GitHub (Oct 24, 2025):
I don't agree. The idea of "secure" internal networks seems to be a little bit out of time. I would not suggest adding an option to disable SSL integrity checks. Instead the plugin should take the installed root certificates into account.
@kraftnix commented on GitHub (Nov 2, 2025):
I would also appreciate the plugin using the host's root certificates so I can actually use this plugin.
@kraftnix commented on GitHub (Nov 14, 2025):
If anyone wants a silly workaround, I am using Caddy to hackily workaround the cert issue.
Make a caddyfile like
Run the proxy with
caddy run --config /path/to/abovefile --adapter caddyfileAnd then set the url in the metadata plugin to http://127.0.0.1:3949