Hi Fedora community,
I’ve encountered a very unexpected behavior on a Raspberry Pi 400 running Fedora 42 Server (aarch64). When using a standard OpenSSL command:
openssl req -x509 -newkey rsa:2048 -keyout admin.key -out admin.crt -days 365 -nodes -subj “/CN=admin.example.ts.net”
…it does not generate a PEM-formatted RSA private key, but instead produces a file with this header:
-----BEGIN OPENSSH PRIVATE KEY-----
The file is confirmed with file:
$ file admin.key
admin.key: OpenSSH private key (no password)
According to documentation and expected behavior, OpenSSL should not produce a key in OpenSSH format. This happens consistently, even when using:
/usr/bin/openssl …
This
System details:
- Hardware: Raspberry Pi 400
- OS: Fedora 42 Server (aarch64)
- Initially installed with Fedora 40 and upgraded via dnf system-upgrade (option B, as described here: dnf upgrade issue)
- OpenSSL version: openssl-3.2.4-3.fc42.aarch64
- Binary source: rpm -qf /usr/bin/openssl → openssl-3.2.4-3.fc42.aarch64
What I’ve already checked:
- Verified that /usr/bin/openssl is not aliased or overridden
- Reproduced the issue in a clean directory using unique filenames
- Restarted the system
- Ran dnf update --refresh (no updates available)
- Confirmed /usr/bin/openssl is a valid aarch64 ELF binary
- Issue persists even outside /etc/caddy or privileged directories
- This behavior is not listed under Common Issues
Question:
Has anyone else seen this behavior on Fedora 42 ARM/aarch64? Could this be caused by a hidden configuration, post-upgrade inconsistency, or a known conflict?
If reproducible on clean installs, I’m happy to file a bug report — but I’d first like to confirm whether this is isolated or something systemic.
Thanks in advance for any ideas or feedback!
FYI what ever you use to copy-n-paste this put “smart-quotes” in.
When I run the command I get a admin.crt that starts
$ more admin.crt
-----BEGIN CERTIFICATE-----
MIIDHzCCAgegAwIBAgIUPA3Gu/g1fhqn848c7DFd1S4maYUwDQYJKoZIhvcNAQEL
BQAwHzEdMBsGA1UEAwwUYWRtaW4uZXhhbXBsZS50cy5uZXQwHhcNMjUwNDE5MDEz
MTM5WhcNMjYwNDE5MDEzMTM5WjAfMR0wGwYDVQQDDBRhZG1pbi5leGFtcGxlLnRz
The version on openssl is
$ rpm -qf /usr/bin/openssl
openssl-3.2.4-3.fc42.aarch64
I suggest that you crate a new empty directory, cd into it and run the command again. Does it create an ssh cert?
Oh you are asking about the admin.key…
Here is what I got:
$ cat admin.key
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCsq7XDIHMHcNne
u+yH0sirzhq5mssB8Ti5PP2HvEcIvLnos9P92ROSQPJ2ftNOp7w0pW0HsXle4bIT
p+ScZIQ4DSX8WrvRb4Sy/hhus1D+xggiHrAw7LkJ32CEFu8Oel0use14kq2Rs0IA
Thanks for the replies and for testing it on your own system — that’s helpful!
To clarify: yes, my issue is with the admin.key file, not the admin.crt, and you’re absolutely right — your output confirms it is a proper PEM-formatted private key (-----BEGIN PRIVATE KEY-----), as expected from OpenSSL.
I’ve since run the same command in a clean directory (no smart quotes this time), explicitly calling /usr/bin/openssl, and I consistently get an OpenSSH private key (-----BEGIN OPENSSH PRIVATE KEY-----). This happens even outside /etc, with no sudo, in ~/openssl-test.
Here’s what I’ve done to investigate:
- Verified
/usr/bin/openssl → correct binary and RPM match (openssl-3.2.4-3.fc42.aarch64)
- Verified
/lib64/libcrypto.so.3 → correct hash and from openssl-libs
rpm -V on both packages → no changes- No
LD_PRELOAD or suspicious environment variables
- No tampering detected by
aide or clamscan
- Reinstalled
openssl, openssl-libs, crypto-policies, and ca-certificates
- Still reproducible
This system was originally installed with Fedora 40 and upgraded to 42 via the dnf system-upgrade method (Option B from this Fedora Pi upgrade post).
So at this point, I’m strongly leaning toward a deeper corruption or side-effect from that upgrade path — perhaps some library or config that RPM isn’t tracking, or that was carried over silently.
I’ll likely reinstall Fedora 42 cleanly to confirm the problem disappears — and to restore full confidence in TLS tools like Caddy?
Let’s make sure we are running identical commands in an identical setup.
Save this to a file and run it please
#/usr/bin/bash
set -x
rm -rf qqq
mkdir qqq
cd qqq
ls -l
/usr/bin/openssl req -x509 -newkey rsa:2048 -keyout admin.key -out admin.crt -days 365 -nodes -subj "/CN=admin.example.ts.net"
ls -l
cat admin.key
cat admin.crt
THis is the output I get on my ARM processor.
$ ./a.sh
++ rm -rf qqq
++ mkdir qqq
++ cd qqq
++ ls -l
total 0
++ /usr/bin/openssl req -x509 -newkey rsa:2048 -keyout admin.key -out admin.crt -days 365 -nodes -subj /CN=admin.example.ts.net
....+.........+.+++++++++++++++++++++++++++++++++++++++*.........+.+...+.....+.......+.........+........+...+....+++++++++++++++++++++++++++++++++++++++*.+.........+......+.....+.....................+.........+.+...+........+.........+.+..+...+............+..................+...+.+...+...++++++
...+...+..........+++++++++++++++++++++++++++++++++++++++*........+...+++++++++++++++++++++++++++++++++++++++*.+.....+......+.+.........+......+..+............+......+...+....+..++++++
-----
++ ls -l
total 8
-rw-r--r--. 1 barry barry 1143 Apr 19 03:28 admin.crt
-rw-------. 1 barry barry 1704 Apr 19 03:28 admin.key
++ cat admin.key
-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDERZwCbEiiPbFH
oB/U8KnStgW6tSgW3q+JmVdRjwWcOVLjxghizL2CRbrEw7MJe5TfHOi8lm88wVYH
COvkjxKgsvl2vLUz4ShRGBJybUuLWsm/OKoeyRub4QaPnjE24yG7xXvEcmv3I2bm
vEwaXZGQM31M4/cMA9GcHj0+OVWwohIic7urIEfxG7y6uWjmIM0g7gsjbd1tIb/E
LnBQ1GNMBB+P8DNTX6nP0Ka2LfolCgdW9Mi0ON/zKDUEg1lPsw8X+xL/jFNDquJp
v0j+BvkfSuLjGop6WJVlCQTg6W059L02TxFwc2qIjkQ2NUvFYDEyw1iPYAHS1Ih5
2XCCz4WFAgMBAAECggEABP+U0ob5bpBNpHpSdTTPzlruWGvmonZ3V/S8wYn35Zuc
HcrcSc/W/6tQ71PgilxIVUpCLxNRr+VokHNMtpxiKA+GxNxXbQPN6ArJ5XodE2Zz
ftgtlO0gM98OMLghnrk4EbUcysrzLu8K3tNqyL0bSOXWyg+AKiEqxGQMwTnqkb3z
d3YM3QMIXcyuMWAG5iqIKHwekna9nJO5jK3lmXVvj5Ph1VITHkkgAIwXD2nZsu9p
J17Ivo4sVYl4RtWOLM6KKdXo36Qm15l2qKunb7RrXBMS+Yg1MaM3wDjgdJJgVPBZ
J8nSgb0VPdrnVpIbVjnSQ46gchelAGtd1BXPogpFYQKBgQDhWlhim+iK3MppNkUP
7R7DjJ852g0DtH8bcw0sRiYkoaarkc1Yal77HcizVyBVZlbpCr+Ph+NI19+6zoC/
jr/+HI04demcciVmkjhJfJt3hPsw+Qyo9kHO3HtZBOV0tgoarDch4SvP5gjw+0hA
qO6cTYJIMP68Re7scweF5wagXQKBgQDe9s9fVrYR7VnDeukvYCuOGgRqvF6Jwj86
ko6WM6EM93Mrt5fSHKf7SPKwuZB2wyGKxk/lEOQaJFzn/PoCddWe9ZbaJXicx/bz
AG7mct7Xk37uGgkrAuAcXJbFQKl8/egqkjnxKTAjngzjVu1dRkspAfQ3raqTTpDn
HbrMahpHSQKBgF+3O+tGRVMVzHM7tcG5+WMdi1PLJdP5CjPifinb8b+FWYFuAEYZ
iBYo5GIoE3eybB+3jP2tvf/mkQSLSWwTecC459KfYoYshW43lOjBoFb3iKmYXqQ1
VGZEh6+bwMn9t/T0SMZ/GVjIX+vbDylHl3GUCk4XYVseaQjNItjg85ORAoGAevng
aPJXm82w69u4D9RYUZlSBFj/P7Yuz6yUDo5NbuxwzpUFnPMHR9b1XLoMzyRTNMqq
uGo3lZ+myqHCd2bsuy8z1ABE5Rx5vY/omxySgo6svMEJe3qrh5kd45AFq5YT3p8m
bDhOf+alryJ76y1hOS4FuEwGQBdeXssMA8El21kCgYB1chklHVn1IERVzl7Py1lk
5vqi6FgMajIMzqwXMLY3qn4RGOfRok6HZLxyb20BKOM2LN+tTMCJicSR/c895VlD
7aVl/sHJxmwoHTUVp8K7F4k8+GQAuVteoxSQCTMUWIdjhAPCGro5mjmTQt2yqx0Y
v5ALWr0z2W0PPsXSUGaP3w==
-----END PRIVATE KEY-----
++ cat admin.crt
-----BEGIN CERTIFICATE-----
MIIDHzCCAgegAwIBAgIUf0IlhD1VRDUHCEp3Ibak6+IB2sswDQYJKoZIhvcNAQEL
BQAwHzEdMBsGA1UEAwwUYWRtaW4uZXhhbXBsZS50cy5uZXQwHhcNMjUwNDE5MDIy
ODI5WhcNMjYwNDE5MDIyODI5WjAfMR0wGwYDVQQDDBRhZG1pbi5leGFtcGxlLnRz
Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMRFnAJsSKI9sUeg
H9TwqdK2Bbq1KBber4mZV1GPBZw5UuPGCGLMvYJFusTDswl7lN8c6LyWbzzBVgcI
6+SPEqCy+Xa8tTPhKFEYEnJtS4tayb84qh7JG5vhBo+eMTbjIbvFe8Rya/cjZua8
TBpdkZAzfUzj9wwD0ZwePT45VbCiEiJzu6sgR/EbvLq5aOYgzSDuCyNt3W0hv8Qu
cFDUY0wEH4/wM1Nfqc/QprYt+iUKB1b0yLQ43/MoNQSDWU+zDxf7Ev+MU0Oq4mm/
SP4G+R9K4uMainpYlWUJBODpbTn0vTZPEXBzaoiORDY1S8VgMTLDWI9gAdLUiHnZ
cILPhYUCAwEAAaNTMFEwHQYDVR0OBBYEFNAE8CxLR7A/b/Vt6PpPN1Ge26BAMB8G
A1UdIwQYMBaAFNAE8CxLR7A/b/Vt6PpPN1Ge26BAMA8GA1UdEwEB/wQFMAMBAf8w
DQYJKoZIhvcNAQELBQADggEBAHA3mIP7kK+VjHHhg3esmB5qVe+Y0niSZnK5t/FC
FXHo8uPDtR8RpU0AE7Wm2/zxelbqAVEbbzEmn76Q+EIihrd7NB/TjixTiKKiswfW
ce7xECSXnwRlpabIPlo7b2vBnNcdHMguuVw1VE5A/Sml1+hpy+ndtEQ7QWNajrGx
Z4aT/6cUEUQQy0qu2E2z2m8yd/KMzdnUvuES6cHs+/DbB1vRGF7Tc1oWEVBk8ot+
E0NtIe/MEDa6wXVDeH26KOAC36LesCHu2FwoiV9elM5cxES2EPNDWndj3JBqZT52
HahwNIVOaV2DRgcOXycIq1Z+EHhriIAthyVZzgwTDT0VA38=
-----END CERTIFICATE-----
1 Like
Thanks for the earlier responses — they were helpful in narrowing down the problem. I now have a minimal reproducible test that might help clarify the issue.
After encountering the unexpected generation of an OpenSSH private key when using:
"openssl req -x509 -newkey rsa:2048 -keyout admin.key -out admin.crt -days 365 -nodes -subj “/CN=admin.example.ts.net”
"
…I created a simple test script (a.sh) per your recommendation containing exactly the same command:
"#!/bin/bash
rm -rf qqq
mkdir qqq
cd qqq
/usr/bin/openssl req -x509 -newkey rsa:2048 -keyout admin.key -out admin.crt -days 365 -nodes -subj /CN=admin.example.ts.net
"
When run with bash ./a.sh, the result is correct and fully as expected:
admin.key is a proper PEM-encoded RSA private keyadmin.crt is a valid X.509 certificate- Both pass verification checks and modulus matches
This is in contrast to earlier attempts, where I copy-pasted the same command from a browser (into the terminal or shell history), and admin.key ended up as an OpenSSH private key.
Could the use of “smart quotes” or invisible Unicode control characters in the shell explain this behavior?
- Is there any known way
openssl might fall back to ssh-keygen or another binary, even when invoked directly?
- Are there known bugs or edge cases in the Fedora 42
openssl (or bash, or coreutils) that could cause silent command misinterpretation?
- Have you seen a
req -x509 invocation produce non-PEM key material under valid-looking input?
Cool we can get the same results as each other with the bash script!
openssl has no connection to openssh as far as I know.
openssh maybe using openssl; I’m being lazy and not checking 
The smart quotes lead to a error message from openssl for me.
What is the shell that you pasted the commands into?
Good question! I used the terminal app of my Macbook Pro with the default Zsh shell to ‘ssh’ into my raspberry pi 400
Not so smart choice after all? I would not have guessed this combo would convince OpenSSL to scramble up OpenSSH… or…? 
I ssh from macos all the time.
It will not be the reason you see odd results.