Feature Request: Certificates with an error in the friendlyName will not be corrected by Import from PKCS#12

[leonardo0014]

German umlauts are not imported correctly or are not corrected.
My example
Certificates with umlauts that have an error in the friendlyName will not be corrected.
Instead of "BJÖRN" comes "BJ�RN"

Currently only tested with Debian Stable XCA Package
Any idea what could be causing this?

XCA

Version: 2.4.0
ECC With RFC 5639 Brainpool curves
Compile time:
OpenSSL 3.0.3 3 May 2022
QT version: 5.15.2
Run time:
OpenSSL 3.0.13 30 Jan 2024
QT version: 5.15.8

PKCS#12 Container

MAC: sha1, Iteration 2000
MAC length: 20, salt length: 20
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2000
Bag Attributes
localKeyID: 01 00 00 00
friendlyName: {5240D771-10C4-4514-B71A-4404B0031288}
Microsoft CSP Name: Microsoft Enhanced RSA and AES Cryptographic Provider
Key Attributes
X509v3 Key Usage: 10
...
Certificate bag
Bag Attributes
localKeyID: 03 00 00 00
friendlyName: BJ�RN NACHNAME
subject=C = DE, CN = BJ\C3\96RN NACHNAME, SN = NACHNAME, GN = BJ\C3\96RN, serialNumber = ...
issuer=C = DE, O = Fraunhofer SIT, CN = Volksverschluesselung Private CA G02
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Certificate bag
Bag Attributes
friendlyName: Volksverschluesselung Root CA G02
subject=C = DE, O = Fraunhofer SIT, CN = Volksverschluesselung Root CA G02
issuer=C = DE, O = Fraunhofer SIT, CN = Volksverschluesselung Root CA G02
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Certificate bag
Bag Attributes
friendlyName: Volksverschluesselung Private CA G02
subject=C = DE, O = Fraunhofer SIT, CN = Volksverschluesselung Private CA G02
issuer=C = DE, O = Fraunhofer SIT, CN = Volksverschluesselung Root CA G02
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Please ignore the fact that the old encryptions for the pkcs#12 Container are still used.
The example is a bit older ;-)

[chris2511]

I assume the error is a Windows CP-1252 encoding of the friendly name during creation, instead of the required BMPSTRING (2byte unicode).
Just a wild guess. There is not much XCA can do to correct this automatically.

[leonardo0014]

Thanks for the quick reply.
So it's a problem with the source of the PKCS12 container.
Then I have to tell the certificate issuer that they're using more "non-Windows" encoding. Let's see what they'll answer, which I can already guess based on the CPS.