Handle SSL certificate errors to enable channel loading #43

New issue

Closed

opened 2026-07-03 07:55:55 -07:00 by serrebi · 1 comment

serrebi commented

2026-07-03 07:55:55 -07:00

Owner

Error:
HTTP 0: Failed to perform, curl: (60) SSL certificate problem: unable to get local issuer certificate. See https://curl.se/libcurl/c/libcurl-errors.html first for more details.

Given that RSS feeds are typically used to distribute public information without transmitting sensitive data or requiring authentication, ensuring feed availability is considered more critical than enforcing strict SSL validation. Therefore, it is proposed to adjust the behavior so that BlindRSS can proceed with loading the channel despite SSL certificate issues.

Proposed Solution

It is proposed to modify the HTTP request handling to tolerate certain SSL certificate problems while maintaining a reasonable security stance. Specifically:

Configure the underlying cURL instance to disable strict certificate verification for feed retrieval (e.g., via CURLOPT_SSL_VERIFYPEER set to 0 or equivalent in the used language binding).
Optionally, introduce a configuration flag (enabled by default) that controls whether SSL errors are ignored for feed loading. This allows advanced users or deployments with stricter security policies to enforce validation if needed.
Log SSL warnings internally (e.g., in the application log or a dedicated diagnostics view) without blocking the feed retrieval.

This approach balances usability and security: it ensures that public feeds remain accessible even with imperfect certificates, while still providing visibility into potential issues for debugging or auditing.

Expected Behavior

After implementation, the following behavior is expected:

Channel Loading

BlindRSS should successfully retrieve and parse RSS feeds even when encountering SSL certificate problems such as untrusted issuers, self‑signed certificates, or missing intermediate certificates.
The user interface should not display the current blocking error for these cases; instead, the feed should load normally.

Error Handling and Visibility

SSL‑related warnings should be recorded in the internal logs or in a non‑blocking diagnostics panel, including details such as the affected URL and the specific certificate issue.
No user‑facing interruption or confirmation dialog should be required to proceed with loading the feed.

Configuration Flexibility

A setting should be available (via preferences or config file) to re‑enable strict SSL validation if desired.
By default, SSL errors should be tolerated to maximize feed availability.

Additional Notes

This change specifically targets feed retrieval logic and should not affect other network operations in the application (e.g., API calls, updates, or authentication flows) that may require stricter security guarantees.
Testing should include feeds served over HTTPS with various SSL issues (self‑signed, expired, incomplete chain) to confirm successful loading and proper logging.

It is required to address the failure to load RSS channels when the server presents an invalid or untrusted SSL certificate. Currently, BlindRSS blocks such channels, resulting in the following error being displayed in the error view: ``` Error: HTTP 0: Failed to perform, curl: (60) SSL certificate problem: unable to get local issuer certificate. See https://curl.se/libcurl/c/libcurl-errors.html first for more details. ``` Given that RSS feeds are typically used to distribute public information without transmitting sensitive data or requiring authentication, ensuring feed availability is considered more critical than enforcing strict SSL validation. Therefore, it is proposed to adjust the behavior so that BlindRSS can proceed with loading the channel despite SSL certificate issues. --- #### Proposed Solution It is proposed to modify the HTTP request handling to tolerate certain SSL certificate problems while maintaining a reasonable security stance. Specifically: - Configure the underlying cURL instance to disable strict certificate verification for feed retrieval (e.g., via `CURLOPT_SSL_VERIFYPEER` set to `0` or equivalent in the used language binding). - Optionally, introduce a configuration flag (enabled by default) that controls whether SSL errors are ignored for feed loading. This allows advanced users or deployments with stricter security policies to enforce validation if needed. - Log SSL warnings internally (e.g., in the application log or a dedicated diagnostics view) without blocking the feed retrieval. This approach balances usability and security: it ensures that public feeds remain accessible even with imperfect certificates, while still providing visibility into potential issues for debugging or auditing. --- #### Expected Behavior After implementation, the following behavior is expected: ##### Channel Loading - BlindRSS should successfully retrieve and parse RSS feeds even when encountering SSL certificate problems such as untrusted issuers, self‑signed certificates, or missing intermediate certificates. - The user interface should not display the current blocking error for these cases; instead, the feed should load normally. ##### Error Handling and Visibility - SSL‑related warnings should be recorded in the internal logs or in a non‑blocking diagnostics panel, including details such as the affected URL and the specific certificate issue. - No user‑facing interruption or confirmation dialog should be required to proceed with loading the feed. ##### Configuration Flexibility - A setting should be available (via preferences or config file) to re‑enable strict SSL validation if desired. - By default, SSL errors should be tolerated to maximize feed availability. --- #### Additional Notes - This change specifically targets feed retrieval logic and should not affect other network operations in the application (e.g., API calls, updates, or authentication flows) that may require stricter security guarantees. - Testing should include feeds served over HTTPS with various SSL issues (self‑signed, expired, incomplete chain) to confirm successful loading and proper logging.

serrebi closed this issue

2026-07-03 08:37:10 -07:00

serrebi commented

2026-07-03 08:37:11 -07:00

Author

Owner

Fixed in v1.77.4.

The implementation is slightly more conservative than disabling verification outright, but gives you the behavior you asked for:

A feed fetch that fails certificate validation (untrusted issuer, self-signed, expired, incomplete chain — including the curl: (60) case you hit) now logs a warning and immediately retries without certificate verification, so the channel loads normally with no user-facing error or dialog.
The SSL problem is recorded in the application log with the feed and the specific certificate error, so it stays visible for diagnostics without blocking anything.
This is on by default. Advanced users can enforce strict validation by setting "ignore_feed_ssl_errors": false in config.json.
As you noted, this applies to feed retrieval only — other network operations keep full certificate verification.

Thanks for the report!

Fixed in [v1.77.4](https://github.com/serrebidev/BlindRSS/releases/tag/v1.77.4). The implementation is slightly more conservative than disabling verification outright, but gives you the behavior you asked for: - A feed fetch that fails certificate validation (untrusted issuer, self-signed, expired, incomplete chain — including the `curl: (60)` case you hit) now logs a warning and immediately retries without certificate verification, so the channel loads normally with no user-facing error or dialog. - The SSL problem is recorded in the application log with the feed and the specific certificate error, so it stays visible for diagnostics without blocking anything. - This is on by default. Advanced users can enforce strict validation by setting `"ignore_feed_ssl_errors": false` in `config.json`. - As you noted, this applies to feed retrieval only — other network operations keep full certificate verification. Thanks for the report!