1

I work as a tester at a VoIP software company. We've been running into a problem with using TLS to communicate with certain phones. The phones are from different manufacturers but both exhibit the same problem. To summarize as succinctly as I can, the phone is rejecting the certificate provided during SSL Handshake with "Unknown CA".

The phones use versions of OpenSSL in their firmware, but I do not know which version.

I have verified in every possible way that the Trusted CA certificate provided to the phone during provisioning and the certificate provided to the phone during the handshake are the same and match. Everything SHOULD be golden, however it isn't.

What I've found is that on one system where everything is functioning properly, the CA cert provided has a 10 digit serial number and on the system where everything is not, the CA cert has a 12 digit serial number.

It seems like such an arbitrary thing to be causing the rejection of the cert, but that is literally the ONLY difference I could find when comparing the working and not working systems and their certificates.

Does this sound like something anyone has heard of before? Am I going crazy? Any and all help appreciated.

--Edit-- Our PBX uses a self-signed CA Cert by default. It then uses that Cert to Sign a Line Cert (Server Cert) and also signs Certs used by the Phones (Client Cert). What appears to be happening is that when new Server Certs are generated, they're doing so w/ a 10-digit serial.

I have the ability to use previously generated certificates (generated using the same methodology) that have 12-digit serials. When using the 12-digit Server Cert to complete the TLS Handshake, the phones accept the 12-digit CA cert. When using the 10-Digit Server Cert, the phones reject the 12-digit CA as "Unknown CA". This seems... completely arbitrary and wrong but it's what I've got.

The new 10-digit certs are being generated using OpenSSL 1.0.1i. The 12-digit certs were being generated using an older version (0.9.7e I think). I doubt that matters much. One phone manufacturer uses OpenSSL 0.9.7e and the other uses OpenSSL 1.0.1c-fips

  • First as an aside, major CAs today don't use cert serial "numbers" as actual numbers (1,2,3 or 20140101, 20140102 etc) but instead as random bytes which happen to represent some number; this is done partly because numeric sequence exposes some info unnecessarily, but I think mostly because truly serial numbers contributed to at least one successful cert forgery and so are taboo even though the real problem was use of MD5 after known pseudocollisions. cabforum requires "at least 20 bits of entropy". Is this a private or limited CA you are using? ... – dave_thompson_085 Aug 30 '14 at 6:44
  • Second, is the CA cert a root cert? OpenSSL (before 1.0.2 still in beta) will only validate against a root. An SSL server should never send just a CA cert, it should send a server cert and if needed one or more CA "chain" certs, and it doesn't actually need to send the root cert at all; if the server does send the root the client is required to ignore it and OpenSSL client does. What matters is whether the server cert, and any chain cert(s), chain to a root already present (in your case provisioned) in the client. ... – dave_thompson_085 Aug 30 '14 at 6:48
  • ... For valid chain make sure child Issuer matches parent Subject exactly, full encoding not just visible characters; AuthorityKeyIdentifier if present which for most CAs it is matches parent data; and the parent cert (CA cert) KeyUsage has certSign bit on, as well as BasicConstraints.CA = true. Can you (try to) connect to and validate same server from other client(s), especially commandline openssl s_client which can display (lots! of) debugging info? – dave_thompson_085 Aug 30 '14 at 6:53
  • Some phones will only accept certificates signed by the device manufacturer. – Michael Hampton Aug 31 '14 at 19:21
  • Thanks for all the information. I'll see what I can find out. I do have an update that, I think, results in a root cause diagnosis. Our PBX uses a self-signed CA Cert by default. It then uses that Cert to Sign a Line Cert (Server Cert) and also signs Certs used by the Phones (Client Cert). What appears to be happening is that when new Server Certs are generated, they're doing so w/ a 10-digit serial. ... – Dan Gentry Sep 4 '14 at 19:44
2

Added as an at-least-partial answer so I can format:

Those files (in comment to @Steffen) do have an encoding difference.

ServerGroupCertificate.cer has Subject containing Org and OrgUnit as PrintableString and CommonName as T61String aka TeletexString, and 12-Digit-Working.cer has Issuer the same, but 10-Digit-Broken.cer (which is also client_cert.pem) has Issuer all UTF8String. If your CA (PBX) is just copying the character values from parent to child, relying on openssl to (re)compute the type, that did change in 1.0.1h (not noted in CHANGES, prompting some discussion on the maillist). openssl commandline copies the whole stack-of-AVA, which preserves the types. I also notice your child certs are version 3 even though they contain no extensions; this is legal but not what openssl commandline normally does, again suggesting custom code.

One phone using 0.9.7e is probably also relevant. I don't have versions that old at hand to test, but the CHANGES file is cumulative and contains an entry for 0.9.7f dated 22 Mar 2005:

*) Perform some character comparisons of different types in X509_NAME_cmp: this is needed for some certificates that reencode DNs into UTF8Strings (in violation of RFC3280) and can't or wont issue name rollover certificates. [Steve Henson]

This strongly suggests that there were known cases 10 years ago of CAs misbehaving and a relier using 0.9.7e or earlier could not handle them. Although 3280 allowed a relier to use X.500's looser matching rules, which apparently do allow encoding changes, it just didn't allow a CA to depend on reliers doing so.

Further, a relier using openssl's "CAdir" method may have had trouble even longer, because the changes for 1.0.0 dated 29 Mar 2010 includes:

*) Enhance the hash format used for certificate directory links. The new form uses the canonical encoding (meaning equivalent names will work even if they aren't identical) and uses SHA1 instead of MD5. This form is incompatible with the older format and as a result c_rehash should be used to rebuild symbolic links. [Steve Henson]

Thus I suggest you need to either get your CA(s) to stop changing the string encodings in child certs; or replace your CA cert(s) with one(s) whose name fields are already UTF8 to start with, in which case presumably the CA will keep it; or get the reliers (phones) up to 0.9.7f for "CAfile" or anything that similarly pre-fills certs to in-memory store, and probably 1.0.0 for "CAdir" or anything that similarly fetches parent certs dynamically.

HTH.

  • Dave, Thank you for your help. I'm fairly certain you've hit the nail on the head with the UTF8 issue. I'll update when I find out more. – Dan Gentry Sep 8 '14 at 15:53
  • The developer incharge of this managed to get things sorted out with your advice. The encodings now are as expected in all child certs and the phones accept the CA certificate. Thanks for you help! – Dan Gentry Sep 15 '14 at 13:50
0

There are lot of strange things people doing wrong when using SSL. And while I've not seen this one it might be, that they are trying to use the serial number as 32 bit, which means a maximum value of 4294967296 (or 2147483648 is they use signed int). This would fit into your description where 10 digit is ok (at least if below 4294967296), but 12 digit is not.

But, without having more details about the certificates involved this is just a wild guess on what might be done wrong.

  • I've placed the certificates involved online URL below. I've tried to label them as clearly as possible. The one called "ServerGroup" is it self-signed CA cert. s000.tinyupload.com/?file_id=46862697373582446609 – Dan Gentry Sep 5 '14 at 15:06
  • It would be good to make clear that your refer with your number of digits to the hexadecimal presentation. This makes the argument with 32bit moot, because you refer to 5 byte and 6 byte, but 32 bit is 4 byte. I don't see much difference between the certificates, but the accepted 12 digit certificate is valid since 2014/05/26, while the not accepted 10 digit certificate is valid since 2014/08/27, i.e. it is only valid since few days. Did you check the time on the phones to make sure that they reflect the current time and can thus successfully verify the times in the certificates? – Steffen Ullrich Sep 5 '14 at 15:21
  • At least with OpenSSL validation logic, too-big clock difference would a different error like "not valid" or "expired", not "unknown CA". – dave_thompson_085 Sep 6 '14 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.