OpenSSL拒绝CA的问题可能是12位序列号造成的

Question

我在一家VoIP软件公司做测试员。我们在使用TLS与某些手机通信时遇到了问题。这些手机来自不同的制造商，但都表现出相同的问题。总之，电话拒绝使用“未知CA”在SSL握手时提供的证书。

手机在固件中使用OpenSSL版本，但我不知道哪个版本。

我已经以每一种可能的方式验证了在配置期间提供给电话的可信CA证书和在握手期间提供给电话的证书是相同的和匹配的。一切都应该是金色的，但事实并非如此。

我发现，在一个系统中，所有东西都正常运行，CA证书有一个10位序列号，而在系统上，所有东西都不是，CA证书有一个12位序列号。

这似乎是一件武断的事情，导致了证书的拒绝，但这是我在比较工作系统和非工作系统及其证书时所能找到的唯一区别。

这听起来像别人以前听说过的吗？我要疯了吗？所有的帮助都很感激。

-编辑--我们的PBX默认使用自签名CA证书.然后，它使用该证书签署线路证书(服务器证书)，并签署证书使用的电话(客户证书)。似乎正在发生的事情是，当生成新的Server时，它们会这样做-- w/一个10位数的串行。

我有能力使用以前生成的证书(使用相同的方法生成)，这些证书有12位数的序列化。当使用12位服务器证书完成TLS握手时，电话接受12位CA证书.当使用10位服务器证书时，电话拒绝12位CA作为“未知CA”。这看起来..。完全的武断和错误，但这就是我所拥有的。

新的10位数字证书正在使用OpenSSL 1.0.1i生成.12位数的证书是使用一个旧版本(我认为是0.9.7e)生成的。我怀疑这有多重要。一个手机制造商使用OpenSSL 0.9.7e，另一个使用OpenSSL 1.0.1c-fips。

Answer 1

增加了一个至少部分的答案，这样我就可以格式化：

这些文件(在@Steffen注释中)确实有编码差异。

ServerGroupCertificate.cer的主题包含Org和OrgUnit作为PrintableString，CommonName作为T61String aka TeletexString，12-Digit-Working.cer的发布也是相同的，但10-Digit-Broken.cer (也是client_cert.pem)拥有更多的all UTF8String。如果您的CA (PBX)只是将字符值从父级复制到子级，则依赖openssl来计算类型，这种情况在1.0.1h内就发生了变化(更改中没有注意到，这引起了对邮件列表的一些讨论)。openssl命令行复制整个AVA堆栈，从而保留类型。我还注意到您的子证书是version 3，尽管它们不包含任何扩展；这是合法的，但openssl命令行通常不这样做，这再次提出了自定义代码。

一部使用0.9.7e的手机可能也是相关的。我手头没有要测试的旧版本，但是更改文件是累积的，包含2005年3月22日的0.9.7f条目：

*)在X509_NAME_cmp中执行不同类型的字符比较:对于某些证书，这些证书需要将DNs重新编码为UTF8Strings (这违反了RFC3280)，并且不能或不愿发出名称翻转证书。史蒂夫·亨森

这有力地表明，10年前就有CAs行为不当的已知案例，使用0.9.7e或更早的救世主无法处理它们。虽然3280允许救济者使用X.500's更宽松的匹配规则，这显然确实允许编码更改，但它只是不允许CA依赖于救济者这样做。

此外，使用openssl的"CAdir“方法的救济程序可能会遇到更长的麻烦，因为2010年3月29日对1.0.0的更改包括：

*)增强用于证书目录链接的哈希格式。新表单使用规范编码(这意味着等效名称将工作，即使它们不相同)，并使用SHA1而不是MD5。此表单与旧格式不兼容，因此应该使用c_rehash重建符号链接。史蒂夫·亨森

因此，我建议您要么让CA(s)停止更改子证书中的字符串编码；要么将CA cert(s)替换为一个名称已经为UTF8的字段(CAdir)，在这种情况下，CA可能会保留它；或者让释放器(电话)达到0.9.7f，用于"CAfile“或任何类似的预填充证书到-内存存储中的内容，或者可能是1.0.0用于"CAdir”或任何类似动态获取父证书的内容。

HTH。

Answer 2

在使用SSL时，人们做了很多奇怪的事情。虽然我还没有看到这一次，但他们试图将序列号作为32位使用，这意味着最大值为4294967296 (或者2147483648是使用有符号int)。这将符合您的描述，其中10位数是可以(至少如果低于4294967296)，但12位数不是。

但是，没有更多关于所涉及的证书的细节，这只是对可能做错什么的猜测。