Forum Discussion
James_Yang_9981
Altostratus
Altostratusneed help on irules encoding
customer using BIGIP to do SSL acc, but they need insert the DN of client cert to request http header. we encounter the encoding issue there...
the original DN of client is:
CN=041@0110200608081555@开发部@00000001,OU=Employees,OU=DEP,O=CFCA TEST CA,C=CN
what the BIGIP 9.4.1 output is:
CN=041@0110200608081555@\E5\BC\80\E5\8F\91\E9\83\A8@00000001,OU=Employees,OU=DEP,O=CFCA TEST CA,C=CN
and BIGIP 9.1.2 output is:
CN=\x000\x004\x001\x00@\x000\x001\x001\x000\x002\x000\x000\x006\x000\x008\x000\x008\x001\x005\x005\x005\x00@_\x00S\xD1\x90\xE8\x00@\x000\x000\x000\x000\x000\x000\x000\x001
the diffrence of the 9.1.2 and 9.4.1 is because of CR65543. but it seems that it's only partial completed CR.
the point here is that rules output is using ASCII to represent the UTF-8 code. but acturally, the server expected is the byte-stream of UTF-8 format but not "ASCII like" UTF-8. So there must something need to be done on this.
has open a case and do some basic research on the convertion. Till now, the best aproach I got is a small convertion code on bigip 9.4.1:
echo -n "\E5\BC\80\E5\8F\91\E9\83\A8" | sed -e 's/\\//g' | perl -e 'print pack("H*", )' | iconv -f utf8 -t gb2312
this will output the actual gb2312 character that I can seen it on terminal in my Chinese Windows version.
does this can be done by rules?
I found TCL has
encoding convertto (not sure if it is working in BIGIP environment)
binary format
regsub all
that may used for convertion. but really need help on how to make a working rule that can do it.
Thanks
- I've dug up a number of other posts on the same topic as well, and I'm building a consolidated case to escalate to Support.
I need to provide some version-specific info, though, and your output for 9.1.2 above is blank -- can you please re-post that data?
I think the issue is that LTM re-formats into UTF-8 as you mention, so I'm not sure binary or regsub operations run prior will help.
encoding commands are disabled (I recently added to the disabled commands wiki page)
/deb 
James_Yang_9981I have edit the oringinal post with the 9.1.2 output. PLS refer case C370539 for more detail about this issue.- OK, great.
Looks like the case is progressing well, so I'll wait for resolution as well before escalating anything further.
/deb - I download a program called ascii2uni from this website AND change its c code so that it will parse rfc2253 format strings, i.e. the output format of Bigip.
Find the tar file near the end of this webpage. http://billposer.org/Software/uni2ascii.html
Expand the tar file and use a text editor to change one line in ascii2uni.c from
int UTF8ValueP = 0;
to
int UTF8ValueP = 1;
Then ./configure and make.
The resulting executable is ascii2uni. I store the rfc2253 formatted string in a file called rfc2253.txt and invoke the executable with this command:
./ascii2uni -q -Z"\%02X" < rfc2253.txt > utf8.txt
The program will complain about "lacking the requisite final semicolon" but I check the string in utf8.txt and it is indeed in plain UTF-8. - RFC2822 section 2.2 states that headers must use printable US-ASCII. Putting raw UTF8 in any header violates RFC. The server mentioned in the first posting will never get a plain UTF8 string from an HTTP header.
There are two ways to be RFC2822 compliant by encoding the unicode string inside X509 subject/issuer field into something consists of only US-ASCII bytes:
1) The solution adopted by bigip is RFC2253 encoding.
2) An alternative, but currently unavailable, solution is to encode the unicode string to UTF8 and then to MIME (per RFC2183).
Please try the program I mentioned in my previous post. See if it helps your server to understand RFC2253. - James_Yang_9981yes, that is exactly the result of the case process. I have tested it and confirm that will works in most of cases.
we have thinking about using base64 encoding the original binary string. but at the end, using above code is much simple compare with modify the irules syntex.
