Bug 10362 - (int-171877) XMPP client doesn't recognize SSL 'X509v3 Subject Alternative Name'
: XMPP client doesn't recognize SSL 'X509v3 Subject Alternative Name'
Status: NEW
Product: Chat & Call & SMS
: 5.0:(10.2010.19-1)
: All Maemo
: Unspecified normal with 1 vote (vote)
: ---
Assigned To: rtcomm@maemo.org
: xmpp-bugs
  Show dependency tree
Reported: 2010-05-27 20:51 UTC by Daniel Benoy
Modified: 2010-06-01 17:02 UTC (History)
3 users (show)

See Also:

Debug command output (983 bytes, text/plain)
2010-05-27 21:01 UTC, Daniel Benoy
jabber.belnet.be certificate (5.45 KB, text/plain)
2010-05-28 11:25 UTC, Laurent Bigonville


You need to log in before you can comment on or make changes to this bug.

Description Daniel Benoy (reporter) 2010-05-27 20:51:59 UTC
Maemo 5 10.2010.19-1.002

1. Configure a Jabber IM account on my SSL enabled jabber server @benoy.name
2. Make sure the Advanced -> Ignore SSL certificate errors option is disabled.
3. Try to connect.

1. The N900 recognizes that the SSL certificate for that server is legitimately
signed by StartCOM
2. The N900 recognizes that the name 'benoy.name' is in the x509v3 'Certificate
subject alt name' field in the certificate
3. The connection to the jabber server is successful.

1. The connection fails, and 'Certificate error' is displayed in the 'My
availability' interface, despite the valid certificate.


If you'd like to see the certificate, you can point a browser at
https://benoy.name:5223/  Even though that's a jabber port the SSL negociation
will go through and you'll be able to see that firefox recognizes the validity
of the certificate.

My theory is that something doesn't support the x509v3 alt name field.

I've seen bug #9355, and ruled it out as a potential cause of this problem.

I used the workaround described in that bug, and I can confirm that my
SSL_CERT_DIR variable is set, and 'wget https://mail.google.com' also works
without any problems.

Also, I've confirmed that my certificate authority (StartCom Ltd.) root
certificate is present in /etc/certs/common-ca

Certs from StartCom are free, if anyone wants to closely reproduce the
circumstances of this bug with their own XMPP server.
Comment 1 Daniel Benoy (reporter) 2010-05-27 21:01:50 UTC
Created an attachment (id=2761) [details]
Debug command output

Command output of:
$ wget 'https://daniel.benoy.name'

$ wget 'https://www.muck.ca'
Comment 2 Daniel Benoy (reporter) 2010-05-27 21:06:33 UTC
I was actually able to reproduce this problem with wget.  I've attached command
output showing it failing to pick up the subject alt name.

I'm not sure if this is something which is handled by openssl, or by the
application itself.  If it's handled by the application itself, it looks like I
have to submit a bug report for wget as well.

The sites I tested were:
https://www.muck.ca (subject CN)
https://daniel.benoy.name (alt name)

As you can see they both pass certificate checks with a browser.

Also I tried my jabber server with the 'Psi' jabber client.  It did not produce
any certificate errors or warnings (and I know it checks.  I unchecked the
'ignore' option)
Comment 3 Laurent Bigonville 2010-05-28 11:25:36 UTC
Created an attachment (id=2764) [details]
jabber.belnet.be certificate


I have the same issue when connecting to XMPP, after adding the CA certificate
to /etc/ssl/certs and running c_rehash.

With the Advanced -> Ignore SSL certificate errors option disabled and the
Advanced -> Connection server empty (the xmpp addresses are @jabber.belnet.be)
it fails to connect with the "certificate error".

If I set westvleteren.belnet.be in Advanced -> Connection server the connection
works flawlessly.
Comment 4 Daniel Benoy (reporter) 2010-05-28 15:57:36 UTC
That workaround works for me too.  If I set the connection server to
'xmpp.benoy.name' (Which is the main subject CN of my certificate) then
everything works, even with the ignore errors checkbox is unchecked.

The 'X509v3 Subject Alternative Name', because the @domain of Laurent's jabber
server is also an alt name rather than the primary and he's having the same
problem.  This, combined with the fact that you can fix the problem by messing
with the server name in the config seems to verify my theory about the alt