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-----