Ca parte a implementării noastre de pornire securizată linux, folosind dm-verity și verificarea semnăturii hash root, trebuie să semnez un fișier cu următoarea comandă openssl (exemplu):
openssl smime -sign -nocerts -noattr -binary -in unsigned.txt -inkey private.key -signer cert.pem -outform der -out signed.txt
Aceasta generează un fișier PKCS#7 care apoi poate fi procesat cu succes de kernel-ul Linux.
Dar pentru producție nu folosim openssl dar PrimeKey Signserver (care se bazează pe bouncycastle) cu semnatar CMS. Aici nu am reușit să configurez semnatarul CMS pentru a genera un PKCS#7 funcțional până acum. Problema este o diferență în digest_enc_algorithm, așa cum se vede în imaginea de mai jos (Stânga: server de semnătură, dreapta: openssl).

Problema este că kernel-ul nu va suporta acel OID. Pur și simplu adăugarea sha256WithRsaEncryption la comutator rezolvă problema, dar nu sunt sigur dacă aceasta este o soluție validă.

O altă „remediere” pe care am găsit-o a fost pur și simplu înlocuirea OID-ului fișierului PKCS#7 semnat, ceea ce îmi ridică și câteva întrebări?!
Acum intrebarile mele:
- Există o diferență reală între rsaEncryption și sha256WithRsaEncryption în acest context?
- De ce este posibil să modificați fișierul PKCS#7 și totul funcționează bine?
- Ar fi o soluție validă să adăugați OID-ul în cazul comutatorului din nucleu? (cel putin din perspectiva cripto)
Multumesc pentru sprijin!
ACTUALIZAȚI: Am găsit această problemă pe restanța serverului de semne PrimeKey.