Output unescaped utf8 x509 issuer/subject DNs

[unRob]

What I'm trying to fix: I have certificates where the issuer DN has accented characters (encoded as utf8 strings) and I'd like curl -v to render these characters properly, instead of showing �.

How I went about it: tweaked the flags ¹ passed to X509_NAME_print_ex ², keeping the current format (delimit key and value with equal sign, delimit entries with semicolon and a space).

Example:

# issue cert with accents:
openssl req -nodes -new -x509 -utf8  \
  -keyout temp.key \
  -out cert.crt \
  -subj "/C=CC/ST=Ciudad de México/L=Cuauhtémoc/O=Mi Organización/CN=example.com.mx" \
  -addext "subjectAltName=DNS:example.com.mx,DNS:host.docker.internal,IP:127.0.0.1"
# verify they print fine
openssl x509 -in cert.crt -subject -nameopt oneline,-esc_msb -noout
#> subject=C = CC, ST = Ciudad de México, L = Cuauhtémoc, O = Mi Organización, CN = example.com.mx
# start a test server
openssl s_server -key temp.key -cert cert.crt -accept 4430 -www

# test latest macos curl on homebrew on a different session:
/opt/homebrew/Cellar/curl/8.12.1/bin/curl -v https://127.0.0.1:4430 -k 2>&1 | grep issuer
#> *  issuer: C=CC; ST=Ciudad de M�xico; L=Cuauht�moc; O=Mi Organizaci�n; CN=example.com.mx

# with fix, i.e. a pre-built docker container with `libssl-dev` and `openssl`:
docker run --rm -it -u $(id -u):$(id -g) -v $(pwd):/usr/src -w /usr/src curl/curl bash
# once in container
./configure --with-openssl --without-libpsl --prefix=$HOME --disable-shared
make && make install
LD_LIBRARY_PATH=$HOME/lib/ $HOME/bin/curl -vv https://host.docker.internal:4430 -k 2>&1 | grep issuer
#> 02:57:58.169365 [0-0] *  issuer: C=CC; ST=Ciudad de México; L=Cuauhtémoc; O=Mi Organización; CN=example.com.mx

This is my first contribution, and while I've read the style guide and contributing guidelines, i'd be happy to keep working on this if i missed something and it needs more work.

Footnotes

1. https://docs.openssl.org/3.1/man3/ASN1_STRING_print_ex/#notes ↩

2. https://docs.openssl.org/3.1/man3/X509_NAME_print_ex ↩

[testclutch]

Analysis of PR #18171 at 37e33872:

Test 3207 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Note that this test has failed in 12 different CI jobs (the link just goes to one of them).

Generated by Testclutch

[bagder]

It could perhaps just be noted that this requires that you also use UTF-8 in the terminal which is not universally true. Presumably people can also encode other things in there that will not render correctly, but I'm still willing to try this route.

[bagder]

@icing any thoughts on this before I merge?

[icing]

Without any general strategy on how to output non-ascii characters in a non-utf8 terminal (or to a file), going with utf-8 by default looks like the best strategy to me.

The current state of producing weird question marks is definitely worse, imo.

[bagder]

Thanks!