在排除了证书、消息不一致的可能之后，我开始对比使用 Node.js 签名的结果与网络传输过来的签名，发现长度不一致，大约差了5~7个字节。于是去网上搜索了一下，才知道原来 Node.js （基于 OpenSSL）签名得到的是 DER 格式的内容，而网络上常用的 ECDSA 签名结果是 IEEE P1363 格式的。（也可以写作 R|S）
知道问题了就好解决了。但是，DER 和 IEEE P1363 两个格式互转也不是那么容易的。
如果长度不同，在各自前面补字节 0x00 直到等长。把 R 和 S 以大头字节序表示，然后依次前后拼接，就是所谓 IEEE P1363 格式。
先来了解一下 ECDSA 的 DER 输出格式，大概如下：
SEQUENCE
是整数的字节长度，用一个字节表示。
是整数的内容，以大头字节序表示。
另一个坑我也已经写出来了，不知道有人发现没有？没想到的话，继续往下。
IEEE P1363 格式下，R 和 S 都是等长的。所以只要把 IEEE P1363 格式的签名从中间切分就可以得到 R 和 S 的内容了。而且 IEEE P1363 格式下，R 和 S 也是以大头字节序表示的，因此没有字节序转换问题了。现在，只需要按上面的格式构造一个 DER 即可。
坑 0x01.0：缺少整数前置字节 0x00
我第一次尝试将 IEEE P1363 格式的签名转换成 DER 格式，并没有失败，但是当我换一个签名结果，却失败了……我对比了 DER 和 IEEE P1363 的区别，发现了一个特点，在 DER 格式下，R 和 S 偶尔会有前置字节 0x00，但不是一定的。
而 DER 下虽然要求补字节 0x00，却是有且只能有一个字节 0x00。
前面说了， 只能用一个字节表示，这是一个整数，前文我提到的整数正负问题，这里也存在！
即是说，ECDSA 签名使用 DER 输出格式时，如果使用 521-bit （是的，你没看错，不是 512） 长度的密钥时，DER的长度将超出 0x7F，使得 变成了负数！
而解决方案不是补字节 0x00，而是用字节 0x81 填充 ，再在下一个字节用一个无符号整数的表示长度（0 ~ 255）。