El Capitan: changes in HTTPS/Certificate handling?

Okay guys… my development system took a nose dive a couple of days ago.

After upgrading to El Capitan PlexConnect is kind of non-functional. I again went through the signing procedure for python, double checked the firewall settings… everything seems to be fine.

What I know for sure:

  • DNS server is working fine (logs are available, other aTV apps are working fine)
  • WebServer (HTTP) works, too: I had no issues re-applying the certs to aTV (after removing them before)
  • locally WebServer (HTTPS) works as well - triggering PlexConnect from Safari, and trusting the self-signed certificate, the oputput is as expected.

But then it gets lost…

  • basically instantenious after selecting, aTV shows the unfortunate “trailers not available”.
  • logs state DNS msgs “intercepting …” followed by - nothing.

It really looks like bad certificates. But then I reloaded them, tried freshly created ones, … only to end in the same, bad spot again. Does anybody know about neccessary changes for cert generation?

As other messages don’t indicate major issues with El Capitan, what am I doing wrong? :smiley:

Read the read before posting topic @baa geez… jk :wink:

I got some test ones here if you want to rule out certs as the issue:

Also try to restart the aTV just for good measure. Maybe turn off the firewall temporarily also? Ive been testing El capitan since this first public beta to the current GM candidate (15B22c) and all beta’s worked for me. Did you also do the code sign for python as described in this topics answer (seems so from your OP):

Uh, yes you are right. Didn’t follow the rules - my bad. :smiley:
Yes, I did the codesigning, enabled by that csr-thing. That seems to have worked out, as the ifrewall rule sticks - ie. it now doesn’t check “allow coming calls” as soon as python starts.
I will check with those certs, thanks… though I really can’t see the reasoning behind all of that. :frowning:

Not sure why… but today everything seems fine again?!