Invalid characters in Common Name

[mOrbo]

Hi,

we user OpenVPN with User-Certs including the User-Name in the "Common Name" of the Cert.
We also use LDAP_Auth and the option "Strict User-CN Matching", so the "Common Name" has to Match the AD-Username for security reasons.

Until we upgraded to pfSense Plus 22.01, it was possible to use the german "Umlaute" (äöü) in the Common Name. This worked almost without problems, only the Client-Config Files from the "Client Export" Tool had to be renamed because of some invalid characters in the name.

Since 22.01 this is not possible anymore. Using an "Umlaut" in the Common Name results in the following message:
"The following input errors were detected:
The field 'Common Name' contains invalid characters."

So we are not able to create new Certs for typical German Users with the Name "Müller" etc.

Is it possible to switch to Unicode for Certs (and OVPN) in a future release?

Thanks!

[rcoleman-netgate]

@morbo Related Redmine: https://redmine.pfsense.org/issues/13387

[mOrbo]

Thanks, but it seems that this ticket is private:
"You are not authorized to access this page."

[rcoleman-netgate]

@morbo Hmm, so it is.

There's a patch in 2.7-RELEASE, targeting the next release of pfSense Plus as well.

[mOrbo]

@rcoleman-netgate Thanks for that info.

This should be 22.11 I suppose? Then we have to rename new users until then. Old certs still work, so this bug does not affect too much users.

[rcoleman-netgate]

@morbo Yes, and yes. That workaround should be fine in the time being.

[jimp]

The linked fix isn't related to the common name field or UTF-8 so it wouldn't help this case. It was only for the description, not for the common name or other certificate fields.

It looks like the validation was changed in https://redmine.pfsense.org/issues/12035 because OpenSSL threw errors when using UTF-8 in subject components.

It's possible they are OK in the common name and not in the other fields, though.

You can install the System Patches package and then create an entry for fe31d06f8c652f008147dc13829e14f78c34d4df to revert that change. I'm not sure if it still reverts cleanly, but it's worth a try.

[mOrbo]

@jimp

Reverting such a change isn't a good idea in a live-system I think. Also it's not persistent over updates. A real solution would be fine.

If I follow the stackoverflow link in the redmine ticket, there should be a -utf8 parameter to fix this issue. Why don't implement this instead of disabling utf8 completely?

[jimp]

pfSense does not call the OpenSSL binary directly in that way, it uses PHP libraries to handle OpenSSL functions so it does not have to rely on repeated shell exec calls and parsing data manually. Unless it changed in a recent version of PHP, it was a limitation of that library.

[mOrbo]

Following again the stackoverflow link, it should also work with php in that way:

<? shell_exec('openssl req -new -md5 -utf8 -key C:/Temp/1.key -out C:/Temp/1.csr -subj "/C=MD/ST=ff/O=Religie/OU=Cen/CN=中国/emailAddress=test@religiasatanista.ro" -config C:/Temp/openssl.cnf'); ?>

[jimp]

pfSense does not use shell exec for OpenSSL, that is irrelevant. It uses a native PHP library and its functions.

The change I mentioned is safe to revert, even in production, it only affects the input validation. Should we put in a fix, it would be included in the next upgrade, so it doesn't matter that it doesn't carry over between upgrades. Even if it was a factor, you need only click the revert button again to take it out after an upgrade.

[mOrbo]

Thanks for that info, I understand that.

I would appreciate it if you put in a fix in the next release. I think it's important for a lot not english speaking countries with special characters in the language.

[mOrbo]

Hi,

we're now on 23.05.1 and the problem still exists. It's not possible to create a common name with German special characters.

Any chance to fix this in a future release?

[mOrbo]

Hi,

we're now on 24.03 and the problem still exists. It's not possible to create a common name with German special characters.

Again, any chance to fix this in a future release?

It's just the common name field :-)