Certificate error with sabNZB

[r3tr0mkv]

Is anyone else experiencing the ssl certificate error with sabNZB? It randomly started at the end of September and hasn't yet been rectified.
I heard it was a problem for providers that use Letsencrypt for their ssl certificates but others report no problem when using other nzb programs (NZBget, etc.)

[BigBirdFinger]

NZBGet was giving me errors. I turned off the SSL check in the program.

[anon]

The usual cause for this is subject names in the certificate not matching the one you set for server connection. This can happen when you use alternate domains, plain IP addresses, or your Usenet provider simply didn't include all of their subdomains or a wildcard for them. That's why SABnzbd has three levels of validation: off, normal (check signing path only) and strong (check signing path and hostname).

The Let's Encrypt drama from September 30th was caused by the DST Root X3 CA expiring, but their certificates have included an alternate signing path from ISRG Root X1 in anticipation of this, so it shouldn't cause trouble... unless your trust stores do not include ISRG (two of my browsers didn't) or your software always checks the longest signing path instead of simply looking for any that "wins". I don't know which is the case here; the former may be fixable by importing the cert into SAB's store, the latter is typically a behavior defined by the TLS library and not configurable.

By the way, here are the identifiers for ISRG (or at least the one currently used by all Let's Encrypt sites I visit) in case you need them for cross-checking.


SHA-256 Fingerprint
96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
SHA1 Fingerprint
CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8
Serial Number
00:82:10:CF:B0:D2:40:E3:59:44:63:E0:BB:63:82:8B:00

[det427]

If using window this should fix it:
Steps I took:

1. Open Run and type mmc.exe
2. Select <File>, <Add/Remove Snap-In..>
3. Choose <Certificates>
4. Select <My User Account>, and click<OK>
5. Expand <Certificates - Current User>
6. Expand <Intermediate Certificate Authorities>, and Click <Certificates>
7. Find the expired R3 and delete it.

[anon]

If that is confirmed to work, then SABnzbd is using the system certificate store, and yours is an acceptable solution as nothing should be relying on the DST root CA exclusively by now.

[r3tr0mkv]

The usual cause for this is subject names in the certificate not matching the one you set for server connection. This can happen when you use alternate domains, plain IP addresses, or your Usenet provider simply didn't include all of their subdomains or a wildcard for them. That's why SABnzbd has three levels of validation: off, normal (check signing path only) and strong (check signing path and hostname).

The Let's Encrypt drama from September 30th was caused by the DST Root X3 CA expiring, but their certificates have included an alternate signing path from ISRG Root X1 in anticipation of this, so it shouldn't cause trouble... unless your trust stores do not include ISRG (two of my browsers didn't) or your software always checks the longest signing path instead of simply looking for any that "wins". I don't know which is the case here; the former may be fixable by importing the cert into SAB's store, the latter is typically a behavior defined by the TLS library and not configurable.

By the way, here are the identifiers for ISRG (or at least the one currently used by all Let's Encrypt sites I visit) in case you need them for cross-checking.


SHA-256 Fingerprint
96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
SHA1 Fingerprint
CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8
Serial Number
00:82:10:CF:B0:D2:40:E3:59:44:63:E0:BB:63:82:8B:00





If using window this should fix it:
Steps I took:

1. Open Run and type mmc.exe
2. Select <File>, <Add/Remove Snap-In..>
3. Choose <Certificates>
4. Select <My User Account>, and click<OK>
5. Expand <Certificates - Current User>
6. Expand <Intermediate Certificate Authorities>, and Click <Certificates>
7. Find the expired R3 and delete it.

That worked perfectly!


If that is confirmed to work, then SABnzbd is using the system certificate store, and yours is an acceptable solution as nothing should be relying on the DST root CA exclusively by now.


Thank you both very much for your help.

[jojobrown911]

NZBGet was giving me errors. I turned off the SSL check in the program.

+1, I too was having the same issues and ended up doing the same thing for the fix. I am not sure if it was a software issue on their part because i was using SSL prior to the update without any issues.

[anon]

That worked perfectly!

Nice! For the record, the following command has the same result as what det427 posted if run as administrator.


certutil -delstore "AuthRoot" "DST Root CA X3"


If by any chance you don't have the the ISRG Root X1 certificate installed, you can download it from https://crt.sh/?id=9314791 and import it like this.


certutil -addstore "AuthRoot" "9314791.crt"


However, if you actually need to follow this step you have bigger problems to worry about, like missing a few years of security updates...


+1, I too was having the same issues and ended up doing the same thing for the fix.

I never used TLS in the first place, it slows down my computer at high speeds. NSA wants to know which old anime and warez I'm downloading, they can have it.

[r3tr0mkv]

Nice! For the record, the following command has the same result as what det427 posted if run as administrator.


certutil -delstore "AuthRoot" "DST Root CA X3"


If by any chance you don't have the the ISRG Root X1 certificate installed, you can download it from https://crt.sh/?id=9314791 and import it like this.


certutil -addstore "AuthRoot" "9314791.crt"


However, if you actually need to follow this step you have bigger problems to worry about, like missing a few years of security updates...

Good to know. Genuine thanks once again.