I previously have had Sonarr working with a self-signed certificate that recently expired. I figured this would be the time to go ahead and utilize a public CA-signed cert. I’m using the guide located here.
I’ve installed Sonarr without the service configuration. The system automatically logs on as an administrator and launches the various servers (Sonarr and SABnzbd and whatever). A shortcut to to nzbdrone.console.exe is in the user’s Startup programs.
I issued a cert from StartSSL and have managed to import it successfully into SABnzbd and Deluge without trouble. I’ve created a PFX with the full cert path and have installed it in the Personal store for the user account running Sonarr. I’ve selected the correct certificate, grabbed the fingerprint, stripped spaces (including trailing), and pasted it into the web form. Failing that I also manually pasted the value into the config.xml with no change. I’m launching the console application as the local user which has admin privileges, launching as the user “Administrator” also doesn’t resolve the issue. In all cases, the non-SSL port lights up as expected and the SSL port does not respond. The Windows firewall is disabled on this system.
I’ve enabled trace logging, deleted the existing logs, started up Sonarr, waited for it to settle down, then shut it down. A sanitized copy of the result can be viewed here: http://pastebin.com/raw.php?i=CM8MnKhv
Here’s what the cert details look like in the personal store and in my config.xml:
Reading further it looks like I might need the cert chain in the Local Computer Personal store (as opposed to the Current User Personal store). I’ve imported the chain there as well, and I’m still unable to attach to the SSL port.
Some further testing had me fire up Wireshark from the client side. I ran the “wget” command seen above with a capture filter of “tcp port 9898”. The conversation is pretty short, a SYN>ACK>SYN followed by the first request and an abrupt TCP RST from the Sonarr server. Whatever it’s failing on it’s failing nearly immediately. The connection is made but reset as soon as a request comes down the line.
Yeah, its failing to establish an SSL connection. Sonarr relies on Windows to handle that (httpsys), since the sslcert was added properly via netsh it doesn’t have look to have any invisible characters (which Sonarr attempts to remove before registering).
Just saw in your screenshot that you loaded the cert for the Current User, but it needs to be loaded for the Local System since its a system level process that handles SSL.
This VM is a member server of my internal domain. Domain user “Sonarr” is a member of the local Administrators group, and is set to auto-logon upon VM boot. The cert chain has been installed in both the user’s personal store and the computer’s store. I am running nzbdrone.console.exe in the interactive desktop session, it is not being run as a service.
Based on your suggestion above I’ve re-installed Sonarr this time as a service. The default service utilizes Local System account. In MMC I did an Add/Remove Snap-ins > Certificates > Service account > Local computer > Selected “NzbDrone” service > and then installed the 3 certificates (the contents of the PFX) there. I’ve started and restarted the service with the same results (9898 open, but not allowing SSL connection). Running the nzbdrone.console.exe yields the same results.
I’ve further gone and deployed the IIS role just to test. I bound 443 to https and the cert chain shows up in the drop-down as it should. Restarted IIS and the default web site appears on 80 and 443 with the correct certificate details.
Try adding it to your local computer trusted root certs. My self-signed are all installed there and working. Note however, I use NGINX front-end, no ssl on drone, nginx terminates the ssl.
The certificate is handled by Windows, the only reason Sonarr has the cert hash field is to make it easier to register (instead of having everyone manually register it via netsh).
Does the cert thumbnail output from netsh match the actual cert hash?
Yes, the hashes match all around which you can kinda see as I’ve left the first and last 4 bytes visible in the screenshot of netsh along with the thumbprint as displayed in the Certificates mmc console.
Were you able to load your test IIS site up in a browser? Sonarr relies on the same underlying system to route HTTP and HTTPS to its server, so it should work the same way.
Something just popped into mind: this thing worked with a self-signed cert from my domain CA. I’ve decided to move my publicly accessible services over to trusted CAs simply because Android is being a jerk about imported CA root certs these days. Because I’m cheap and don’t think much of giving people money to generate a damn RSA key, I’ve opted for a cert from StartSSL who offers free 1-year certs. One thing peculiar about StartSSL certs is that when you issue a cert for, say, “sonarr.example.com” they actually issue the cert with a CN of “example.com” along with a SAN of “sonarr.example.com”. Is it possible that Sonarr is tripping up on the cert due to the SAN?
All of this is about to become moot once Citrix finally updates their stupid Netscaler VM to support the latest patches on vSphere. They’ve committed to a fix within a week (it’s been broken for months), at which point I’ll just leave Sonarr and everything else in cleartext and front-end it with a pair of virtual Netscalers which will handle SSL for all the various web management interfaces.
Sonarr is happy to use whatever you throw at it, since in reality it doesn’t do anything with it, it tells OWIN (the web server) to listen on HTTPS, tells Windows (httpsys) that it should listen for HTTPS connections on the assigned port and registers the port + cert with Windows so it can decrypt it properly which forwards it to the webserver and by the time Sonarr sees it its just a request.
Unless the port isn’t listening or the cert wasn’t registered with Windows properly it should just work. Starting from the beginning is my only suggestion.
This thread is a little old, and my original workaround is now in place (drop everything behind an SSL appliance that will also do reverse proxy and rewrite). However, this was still grinding my gears a bit as I’m a Windows guy and I don’t like thinking that a problem has gotten beyond me. As it turns out, this suggestion worked. I issued a “netsh http show sslcert” and the cert showed the correct thumbprint binding to the correct port (0.0.0.0:9898). I then issued a “netsh http delete sslcert ipport=0.0.0.0:9898”, reconfigured Sonarr for SSL, shutdown, re-launched in an admin console, and it was able to correctly assign the cert. Weirdly, the “netsh http show sslcert” afterwards is identical to the result before unbinding the cert, so I still have no idea what changed.
None the less, this problem is solved thanks to your suggestion. Thanks for your attention on this, and for this kickass software!