Regenerating a self-signed certificate for a FreeRDP-based remote desktop service, I used the command everyone uses:

openssl req -x509 -newkey rsa:4096 -nodes \
  -keyout rdp-key.pem -out rdp-cert.pem -days 3650 \
  -subj "/CN=workstation.example"

The service refused to start with the new pair, and said nothing specific about why.

OpenSSL 3 defaults to writing private keys in PKCS#8. The file begins -----BEGIN PRIVATE KEY-----. FreeRDP expects the older PKCS#1 container, -----BEGIN RSA PRIVATE KEY-----. Same key, same maths, different wrapper, and the parser simply declines.

Checking the header is the whole diagnosis:

head -1 rdp-key.pem

Converting takes one command; no regeneration needed:

openssl rsa -in rdp-key.pem -traditional -out rdp-key-pkcs1.pem

-traditional asks for the legacy container. On OpenSSL 1.x it did not exist, because that format was already the default, which is why so many working examples online omit it and then stop working after a distribution upgrade.

Two related traps in the same job. File ownership matters as much as format: a service running as its own system user cannot read a key left owned by root with restrictive permissions, and that failure also surfaces as a generic startup error. And when a certificate is replaced, clients that pinned the old one keep refusing the new one until their stored copy is cleared, a client-side fault that looks exactly like a server-side one.

-----BEGIN PRIVATE KEY----- versus -----BEGIN RSA PRIVATE KEY----- is the first thing to check whenever a key is rejected by something that ought to accept it.