It seems like even OpenSSL can't handle that CSR properly (I didn't think that was actually possible 
) . Trying to parse it (with openssl asn1parse -inform pem -in your.csr) results in this output:
0:d=0 hl=4 l= 716 cons: SEQUENCE
4:d=1 hl=4 l= 436 cons: SEQUENCE
8:d=2 hl=2 l= 1 prim: INTEGER :00
11:d=2 hl=3 l= 136 cons: SEQUENCE
14:d=3 hl=2 l= 11 cons: SET
16:d=4 hl=2 l= 9 cons: SEQUENCE
18:d=5 hl=2 l= 3 prim: OBJECT :countryName
23:d=5 hl=2 l= 2 prim: PRINTABLESTRING :DE
27:d=3 hl=2 l= 27 cons: SET
29:d=4 hl=2 l= 25 cons: SEQUENCE
31:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
36:d=5 hl=2 l= 18 prim: PRINTABLESTRING :Baten-Wuerttemberg
56:d=3 hl=2 l= 12 cons: SET
58:d=4 hl=2 l= 10 cons: SEQUENCE
60:d=5 hl=2 l= 3 prim: OBJECT :localityName
65:d=5 hl=2 l= 3 prim: PRINTABLESTRING :Ulm
70:d=3 hl=2 l= 22 cons: SET
72:d=4 hl=2 l= 20 cons: SEQUENCE
74:d=5 hl=2 l= 3 prim: OBJECT :organizationName
79:d=5 hl=2 l= 13 prim: PRINTABLESTRING :EDV-WHM-GUTEN
94:d=3 hl=2 l= 26 cons: SET
96:d=4 hl=2 l= 24 cons: SEQUENCE
98:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
103:d=5 hl=2 l= 17 prim: PRINTABLESTRING :wh-gbs.uni-ulm.de
122:d=3 hl=2 l= 26 cons: SET
124:d=4 hl=2 l= 24 cons: SEQUENCE
126:d=5 hl=2 l= 3 prim: OBJECT :commonName
131:d=5 hl=2 l= 17 prim: PRINTABLESTRING :wh-gbs.uni-ulm.de
150:d=2 hl=4 l= 290 cons: SEQUENCE
154:d=3 hl=2 l= 13 cons: SEQUENCE
156:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
167:d=4 hl=2 l= 0 prim: NULL
169:d=3 hl=4 l= 271 prim: BIT STRING
444:d=1 hl=2 l= 13 cons: SEQUENCE
446:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
457:d=2 hl=2 l= 0 prim: NULL
459:d=1 hl=4 l= 257 prim: BIT STRING
Error in encoding
140735108980816:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
My search for this particular message turned up this old post from the OpenSSL mailing list. It appears that the CSR is corrupted in some way. The post contains some ideas on what could be causing this:
This is exactly the symptom of a file being treated as text
when it isn't, in particular by transfer protocols like (S)FTP
and maybe HTTP, or other tools like ZIP. A Unix-style "newline"
(0A) gets converted to a DOS/Win/Inet style CR LF (0D 0A).
Similarly C internally uses one byte '\n' newline, but ON
DOS/Win textfiles use CRLF, so fopen/fwrite/etc. in text mode
converts 0A to 0D0A on output, and 0D0A to 0A on input.
If you are running your C program on DOS/Win, you need
to open the file in binary mode i.e. fopen (foo, "wb").
(But if you're running on cygwin on Win, it's more
complicated; cygwin tries to bridge the gap between Unix-format
and Win-format, AFAIK mostly by 'mount' options.)
Even on other platforms it is good to specify this for
clarity/documentation/robustness even if not strictly needed.
As a check it should be 916=0x394 bytes.
Alternatively, if you want a text file, which is usually
more portable and human recognizable: get the cert data,
base64 it and add the -----BEGIN/END lines to make it
PEM format, and write (and read) that as text.
If you could share more details about how this CSR is generated, transmitted, etc., we might be able to figure this out.