error: ASN1_mbstring_ncopy:illegal characters

raf openssl at
Wed Apr 12 23:45:55 UTC 2023

On Wed, Apr 12, 2023 at 02:31:30AM -0400, Viktor Dukhovni <openssl-users at> wrote:

> On Wed, Apr 12, 2023 at 03:20:51PM +1000, raf via openssl-users wrote:
> > Thanks. I thought that might be the case, but I didn't
> > know what kind of encoding was appropriate for openssl
> > usage. There are different encodings for different
> > purposes. My interest in Unicode domain names relates
> > to DNS usage where IDNA2008/UTC#46 is useful. But this
> > makes sense since it's an email address.
> > 
> > It would be great if openssl performed the necessary
> > encoding, especially when it has been instructed (with
> > the -utf8 option) to interperet input as UTF-8 (but the
> > locale should probably be enough of an indication), and
> > to also perform the corresponding decoding on output. I
> > think that requiring users to perform the correct
> > encoding is asking too much. But maybe expecting
> > openssl to include code for encoding and decoding email
> > addresses is asking too much.
> > 
> > I have a shell script that will need to decode
> > international email addresses in S/MIME certificates,
> > and then encode the domain as IDNA2008/UTC#46.
> [ Doing X.509 validation in shell scripts sounds particularly unwise,
>   Python, or a programming language less prone to code injection
>   attacks or other serialisation/deserialisation issues would be
>   a better choice, or even some robust C++ code on top of the OpenSSL
>   API. ]

I don't think I'm (consciously) validating anything. I just need to extract
the email address for the purpose of creating SMIMEA DNS records. My script
just checks that "openssl x509 -inform pem -in smimecert.pem -noout -purpose"
outputs "S/MIME encryption : Yes", and then it scans the output of
"openssl x509 -inform pem -in smimecert.pem -noout -text" looking for
"emailAddress = ", and then it uses the subsequent email address.
And the important stuff above is done in perl, not shell. :-)

> This isn't a question of *encoding*, rather addresses with UTF-8
> localparts, or a U-label domain, are stored in a different subtype of
> the SAN discriminated union.

That's good.

> You need to specify a SAN "otherName" of type smtpUtf8Name, rather than
> an rfc822Name.  With OpenSSL 3.0, you can use "id-on-SmtpUTF8Mailbox"
> instead of the numeric OID:
>     [extensions]
>     subjectAltName = @sans
>     [sans]
>     otherName.1 =;FORMAT:UTF8,UTF8String:потребитель@домен.example
> Full support for this in certificate verification requires OpenSSL 3.0.

Thanks. Sadly, I don't understand the config file
format enough to know how to incorporate this into my
existing config file (copied from a howto for S/MIME).
which includes "subjectAltName = email:copy". If I just
add the above, I get a new error when decrypting the
private key.

I think I need to finally read my old OpenSSL book, and
get/read the new one for 3.0. Then, I might be able to
benefit from your suggestion. :-)

In the meantime, I might just wait until a user reports
that my script isn't working for S/MIME with non-ASCII
email addresses (if that ever happens). If they can show
me the output of the openssl x509 ... -noout -text command
for their certificate, that should be enough for me to fix
my script.

> -- 
>     Viktor.


More information about the openssl-users mailing list