not sure which OS and which wallet you talk about... I have two observations.
printf "304602210090c4fc2369cf225559c1141a1e9be3d7598f0fb7affe8a29f86e737972c7587a022100cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f9801" | wc -c
146
which is 73 Bytes only, and if you remove 01, which ends script sig, it gets 72 bytes (hex 0x48). That's probably what you want to use.
Also:
######################################################### ### procedure to strictly check DER-encoded signature ### ######################################################### Minimum and maximum size constraints - ok scriptsig always starts with 0x30 - ok length 140 chars is less than actual sig length (144 chars) - ok (hex 0x46, decimal 70, 140 chars) length of R coordinate (66) >= 0 - ok length of S coordinate (66) >= 0 - ok S-Value is within scriptsig boundaries - ok Make sure the R & S length covers the entire signature - ok --> S is not smaller than N/2, need new S-Value (new_s = N - s)
Is this maybe an older version? Newer version correct S-values smaller than N/2.
correction on the S-Value (November 2017):
the S-Value here is: 00cbd8619ecae3baa40fdb565014fdac28a95deb90c0fcd4adcbd97d58d0e96f98
Pieter explains zero Padding and S-Value in this thread: http://bitcoin-development.narkive.com/OOU2XVSG/bitcoin-development-who-is-creating-non-der-signatures
For S-Values he says:
... 2. Signatures are strictly DER-encoded (+ hashtype byte). The format is:
0x30 <lenT> 0x02 <lenR> <R> 0x02 <lenS> <S> <hashtype>
R and S are signed integers, encoded as a big-endian byte sequence. They are stored in as few bytes as possible (i.e., no 0x00 padding in front), except that a single 0x00 byte is needed and even required when the byte following it has its highest bit set, to prevent it from being interpreted as a negative number.
Based on this the S-Value is zero padded, and as such correct.