1.32.0.6865 Breaks custom SSL certificate

Plex Media Server
1

Server Version#: 1.32.0.6865 (Synology)
Player Version#: N/A

Hello,
Plex server updated and I receive the error browser error:

Your connection isn’t private

Attackers might be trying to steal your information from -----.-------.---- (for example, passwords, messages, or credit cards).

NET::ERR_CERT_COMMON_NAME_INVALID

Roll the server instance back to 1.31.3.6868 and all is good.

Have tried multiple browsers Chrome, Firefox, Edge and Edge Dev.

All produce the same error until the server is rolled back.

Thank you

2

same here - but i didnt rolled back ( dont know how :P)

3

I found a script online that checks at X o’clock in the morning and downloads the latest beta, fortunately it also stores the previous packages as well for a certain amount of time so was able to roll back.

There is also a nice list of download links here:

2 Likes
4

Also reported here: SSL Certificate Errors - #1381 by noyse

5

Certificates in general have a problem; even with its own.

I’m on it.

1 Like
6

Folks,

I need your log files ZIP which captures the restart.

I ALSO NEED to know details of your certs.

7

Not a problem, will DM you the details v. soon.

8

Update:

Folks, we have the data we need and are working through it now.

Please give us a bit to resolve.

9

TO ALL FOLLOWING HERE:

  1. PMS 1.32.0 updates our openSSL library to openSSL v3 and finally dumps the long-deprecated openSSL v2.

  2. As such, openSSL v3 dropped support for some encryption methods

  3. Unless you specified one of the more secure methods when you created your cert, you were likely to get one which is no longer supported by openSSL v3.

  4. Working with Engineering, and confirming PMS behavior, I have information for you on how to regenerate your certificates to be PMS-compatible moving forward

Here is my (redacted) certificate generation script

# Generate new p12 (Acme LE is valid until 2025)
openssl pkcs12 -export -out mydomain.p12 \
	-certpbe AES-256-CBC -keypbe AES-256-CBC -macalg SHA256 \
	-inkey mydomain.key -in mydomain.crt \
	-certfile Acme-LE.crt \
	-password pass:MyPasswordHere

I will add this to Linux Tips

3 Likes
10

Thank you, will this go in to the change logs as a breaking change?

11

i can confirm that after adding this line into my p12 generation script and regenerate the cert everything works again as expected. thx for the fast solution

1 Like
12

That’s a toss up and debatable whether a breaking change or not.

If you’re running Ubuntu 22 or Debian 11, you get openSSL v3 by default.

The only oversight here (unfortunately) was that nobody thought to test on older distros when in fact a “head’s up” would have been appropriate.

This is a lot like switching from http → https .

Is it ‘breaking change’ ? no, I don’t think so.

Do folks need to understand how to manage older distros & devices ? yes.

That’s why I worked through the steps and verified with Engineering.

Now that I understand, I am more confident in my streaming remaining private.

( Look at that’s available to you in SSL v3… You might like it… and FYI, If you break it – you fix it LOL )

13

It’s also not even mentioned in the release notes for 1.32.0.6865 !

14

It’s not a toss up on whether it’s a breaking change. Things broke. Full stop. And it’s not a matter of “which openSSL is on the server.” I have a wildcard certificate, which isn’t generated on that server.
That being said, the computer that I rebuilt the cert chain on is on macOS 13, running

openssl version         
LibreSSL 3.3.6

My wildcard PFX, which had worked perfectly well until yesterday no longer works. I had to rebuild as a .p12. If I have to do work to maintain functionality and security, it’s a breaking change.

1 Like
15

I think that’s a breaking change. I will write that up.

Please don’t shoot me, I’m going on what I’m told.

16

@WooSai

If I send you a PM,

Can you provide me with a PFX which should work as well as what you ended up with?

17

@ChuckPa As it’s a the wildcard certificate for my domain, I can’t give it out. I would be happy to help in pretty much any other way, though.

18

@WooSai

Please look at your PM.

Also, Any mechanism (pseudo-domain/cert) which demonstrates the problem is all I need. If it mirrors your case, but is otherwise fictitious, then perfect.

19

I don’t really have the ability to ad-hoc generate a 3rd party trusted certificate. If you’re ok with self-signed, check your PM.

The command that I would have used would have been

openssl pkcs12 -export -in STAR_domain_net.crt -inkey server.key -certfile STAR_domain_net.ca-bundle.crt -out mycert.pfx

This would have been on presumably a LibreSSL 3.x version. I know I was on Ventura at that point, but I’m not sure exactly when Apple shipped 3.x. macOS wasn’t updated to 3.x in Monterey 12.6.3. At least that’s what my test box is telling me.

I had to add -certpbe AES-256-CBC -keypbe AES-256-CBC -macalg SHA256 with LibreSSL 3.3.6 yesterday to make it work.
Really where I’m going with this is that I built my wildcard in November on the openssl binary that was current on my daily driver, while running the latest version of macOS at the time. And, I’m on macOS Ventura 13.3 currently, and yesterday I had to add the flags above to the command to make it work.
This is why I say that it’s a breaking change.

20

My daily driver is Ubuntu 20.04.5 LTS

I also have a wildcard certificate for my LAN domain (pfSense box)

I also had to add the AES 256 selector because the default created by Ubuntu 20.04.5 LTS is not a supported encryption in the new libraries.

As FYI.

  1. PFX is the Microsoft extension
  2. P12 is the standard extension

Engineering asserts this isn’t a breaking change.

  1. Custom certs in PMS are an Advanced feature.
  2. PMS will run using its own certificates.

Engineering did correct me in that:

  • We did not upgrade from v2 openSSL
  • We upgraded from version 1.1.1 to version 3.0 of the OpenSSL libraries
    (using their numbering scheme)

Please notice how the version numbering changed

1 Like