Bug 8268 - (int-157370) Unable to authenticate on light.webmoney.ru with user's SSL certificate.
(int-157370)
: Unable to authenticate on light.webmoney.ru with user's SSL certificate.
Status: RESOLVED FIXED
Product: Core
general
: 5.0/(3.2010.02-8)
: N900 Maemo
: Unspecified major with 1 vote (vote)
: 5.0/(10.2010.19-1)
Assigned To: Juhani Mäkelä
: core-general-bugs
: https://light.webmoney.ru
:
:
:
  Show dependency tree
 
Reported: 2010-01-19 15:09 UTC by t3st3r
Modified: 2010-03-15 20:53 UTC (History)
3 users (show)

See Also:


Attachments


Note

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


Description t3st3r (reporter) 2010-01-19 15:09:57 UTC
SOFTWARE VERSION:
(Settings > General > About product)
Nokia N900 - Maemo 5.0 - 2.2009.51-1

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Register in webmoney.ru payment system - use "keeper light" option (aka WEB
SSL access). They will generate a client certificate for you so you can prove
you're same user by using this SLL certificate later.
Note: you may want to install their root authority certificate as well. This
part of sequence generally have to be done in desktop browser and is a free of
charge. As the result, you should have a valid SSL certificate which is used to
access secured parts of web site (i.e. managing your account and purses, etc). 
2. Try to login https://light.webmoney.ru using desktop browser and generated
certificate. Ensure this works and you can login from your desktop browser (at
least it works for IE 6, IE 7 and Firefox 2 to 3.5).
3. Send generated certificate to N900 and install it.
4. Try to login from MicroB to https://light.webmoney.ru as well. Ensure this
fails and you're returned to login screen instead of logging in to Keeper
Light.

Note: this sequence works fine with original firmware version (1.2009.42-11)
but stopped working after update. Something similar have already been known as
bug 349 (see https://bugs.maemo.org/show_bug.cgi?id=349) and have been fixed
once, but looks like this or similar bug appeared again (regression?). 

EXPECTED OUTCOME:
 User can login to secured areas of web sites by authorising with a SSL
certificate.

ACTUAL OUTCOME:
 SSL certificate login does not works at least on https://light.webmoney.ru

REPRODUCIBILITY:
 I tried over 10 times, 10 of 10 for me on my device.

EXTRA SOFTWARE INSTALLED:
 AdBlock and several other programs not anyhow related with web browser. Feel
free to try on clean device, but as for me it worked with same set of software
and only major change between working and non-working configurations is that I
updated software to 2.2009.52-1

OTHER COMMENTS:
 Maybe somehow related to bug 349 (i.e. regression, etc).
Comment 1 j.wender 2010-02-17 12:04:20 UTC
I have the same issue, it worked with the original firmware, but the upgrades
reintroduced the problem. It seems like a regression of bug 349.
Comment 2 Juhani Mäkelä nokia 2010-02-18 15:26:23 UTC
Assigned to myself and moved to the proper product
Comment 3 Juhani Mäkelä nokia 2010-02-18 16:27:12 UTC
(In reply to comment #0)
I tested this with builds 10.2009-50-7 and 10.2010-07, and it works for me with
both. So I will need a little bit more information to figure out why it doesn't
work for you.

In my environment (Firefox 3.0.17) the registration at webmoney.ru installed
the client certificate automatically, so it has to be exported from the browser
for installation to N900. There are two ways to do this with Firefox, one of
which works and one of which doesn't.

First open "Preferences" -> "Advanced" -> "Encryption" -> "View Certificates"
-> "Your Certificates". Click the webmoney.ru certificate and select
"Backup...". Select PKCS12 as the file type and enter a filename with the
".p12" extension. When clicking "Save", the browser asks for a password to
encrypt the package. This is the way that works, since it exports both the
client certificate and the accompanied private key.

The way that doesn't work is selecting "View..." and "Export...". That exports
only the client certificate, which is useless without the private key.

Other browsers should have similar functionality to produce a PKCS12 bundle of
the client certificate and its private key.

Once you have the PKCS12 file, copy it to the device and install with File
Manager or directly from the Certificate Manager applet when using build
2009-53 or newer. In installation you have to enter the same password you gave
when exporting the certificate, and that is also the default in login when the
browser asks for the certificate password. You can use the certificate manager
applet to change the password after installation, though.

Installing the webmoney.ru CA certificate is optional but recommended. 

You can check if you have the private key installed by giving the following
command at the shell:

cmcli -p ssl-ca -L -K

It should output something like this:

3f5861239523976c4b20879e94047b5ae1d12ee9 WM id: 1234567891234
3f5861239523976c4b20879e94047b5ae1d12ee9

The first line is the client certificate and the second is the private key. The
key ids must match.

Another way to check the precence of the private key is to open the client
certificate with the certificate manager applet. If there is a "Password"
button at the details-dialog, then you have the private key.

Please check that you have both the client certificate and the private key
installed, and report what kind of an error message you get if it still doesn't
work. Also I would be interested if the "Give certificate password" appears at
any point in the failed login.
Comment 4 j.wender 2010-02-18 18:00:37 UTC
(In reply to comment #3)
I just redid the certificate export (or backup ;)) and reimported it on the
device. The I tried to login on our intranet server
(https://scsa.science-computing.de) and it did not work. After entering
username and password I am returned to the login page, which occurs when the
user certificate is not presented or is not accepted.
I also imported our root ca certificate.
cmcli shows two lines, the first on ending with 'SC ROOTCA', but the numbers
are different.
And I never did get a dialogue windows asking for the key, even when it worked.
On my device runs 3.2010.02-8.
Comment 5 j.wender 2010-02-18 18:18:07 UTC
(In reply to comment #4)
Playing a little with cmcli I found that when I use -p ssl-user then I get two
identical keys, and on the first line additionally my name.
Comment 6 Juhani Mäkelä nokia 2010-02-18 18:59:51 UTC
(In reply to comment #5)
> Playing a little with cmcli I found that when I use -p ssl-user then I get two
> identical keys, and on the first line additionally my name.

Yes, of course. Ssl-user is where the client certificates are supposed to be,
sorry for the mixup. 

Right, so you have both the client certificate and the private key in ssl-user,
and the SC ROOTCA in ssl-ca. I checked the certificate of
scsa.science-computing.de, and it is fine and valid, signed with SC ROOTCA.

This is all correct, so the problem is not with configuration. The fact that
the certificate password is never asked sounds as if the TLS handshake with 
https://scsa.science-computing.de/ is terminated. You do have the private key
protected by a password? If not, then the password is not asked either.

I suppose you can connect to the server with desktop browser without it asking
for the user-id/password?
Comment 7 j.wender 2010-02-19 14:28:41 UTC
(In reply to comment #6)
> https://scsa.science-computing.de/ is terminated. You do have the private key
> protected by a password? If not, then the password is not asked either.

Yep, when I open the certificate manager in settings, I am asked for a password
(which is the same as the password I set for the pkcs#12-file).

> I suppose you can connect to the server with desktop browser without it asking
> for the user-id/password?

Ahm, no, actually it is two-factor: I need to enter username and password and
then on sending the connection must be authenticated by the user certificate
(the browser asks for the certificate after hitting return in the password
field).

Thanks for your help,
Jan
Comment 8 Juhani Mäkelä nokia 2010-02-22 09:53:57 UTC
(In reply to comment #7)
> Yep, when I open the certificate manager in settings, I am asked for a
> password (which is the same as the password I set for the pkcs#12-file).

Very well, then. As far as I can tell, you have everything needed and this
should work.

> Ahm, no, actually it is two-factor: I need to enter username and password and
> then on sending the connection must be authenticated by the user certificate
> (the browser asks for the certificate after hitting return in the password
> field).

Right. The reason I asked is to find out if I have any means of debugging this.
But since the certificate query only comes after having entered a valid
user-id/password combination, the chances seem slim.

Anyway, yet one possible reason why this wouldn't work is that currently only
RSA keys are supported. You can check your key type by command

openssl x509 -text -in ~/.maemosec-certs/wifi-user/<your-certificate>.pem

...and see what is the "Public Key Algorithm". If it is anything else than
"rsaEncryption", then we are out of luck. But at least we know the reason.

If that is the case, could you please be so kind and file a new bug about the
missing support of your keytype. This bug is about "webmoney.ru", and there the
problem must be something else since I have tested it and it works fine.
Comment 9 Juhani Mäkelä nokia 2010-02-22 10:42:04 UTC
(In reply to comment #8)
> openssl x509 -text -in ~/.maemosec-certs/wifi-user/<your-certificate>.pem

Sorry, I meant:
openssl x509 -text -in ~/.maemosec-certs/ssl-user/<your-certificate>.pem
Comment 10 j.wender 2010-02-22 16:47:25 UTC
(In reply to comment #9)
(In reply to comment #9)
Public key encryption is set to rsaEncryption, 2048bit, signature is
sha1WithRSAEncryption.

It seems that you can reproduce a similar problem using
https://bugs.maemo.org/show_bug.cgi?id=349#c29 , I just tried it and it did not
work from the device but worked from the desktop browser.

Actually it did work with the original firmware the devide got delivered with.

Cheerio, Jan
Comment 11 Juhani Mäkelä nokia 2010-02-24 09:55:04 UTC
(In reply to comment #10)
> Public key encryption is set to rsaEncryption, 2048bit, signature is
> sha1WithRSAEncryption.

That should work.

> It seems that you can reproduce a similar problem using
> https://bugs.maemo.org/show_bug.cgi?id=349#c29 , I just tried it and it did 
> not work from the device but worked from the desktop browser.

Yes, that is the same problem. I just flashed 3.2010.02-8 and tested; both
startssl.com and webmoney.ru work fine. Science-computing.de I cannot test
without credentials.

> Actually it did work with the original firmware the devide got delivered with.

This starts to sound like there is something wrong with the upgrade procedure,
since the certificate management has not changed between the original
1.2009.41-1 and 3.2010.02-8, and both work when freshly flashed. One wild guess
yet: please check that library /usr/lib/microb-engine/libnssckbi.so is a
symbolic link to /usr/lib/libmaemosec_certman.so.0.0.0 by:

# ls -l /usr/lib/microb-engine/libnssckbi.so

should output:

lrwxrwxrwx    1 root     root           37 Jan 25 19:34
/usr/lib/microb-engine/libnssckbi.so -> /usr/lib/libmaemosec_certman.so.0.0.0

In these older versions there wasn't a proper diversion for that library, so it
is possible that some update has overwritten the link. That would explain why
user-installed certificates are not visible to the browser.
Comment 12 j.wender 2010-02-24 10:24:36 UTC
(In reply to comment #11)
> yet: please check that library /usr/lib/microb-engine/libnssckbi.so is a
> symbolic link to /usr/lib/libmaemosec_certman.so.0.0.0 by:
> 
> # ls -l /usr/lib/microb-engine/libnssckbi.so

gives:
 -rw-r--r-- 1 root root 336996 Nov 5 16:24 /usr/lib/microb-engine/libnssckbi.so

> lrwxrwxrwx    1 root     root           37 Jan 25 19:34
> /usr/lib/microb-engine/libnssckbi.so -> /usr/lib/libmaemosec_certman.so.0.0.0

After creating this link it works with s-c.de! Entering username/password, then
I am asked for the password of the certificate and the login proceeds.

Thanks a lot!

Cheerio, Jan
Comment 13 Juhani Mäkelä nokia 2010-02-24 11:58:39 UTC
(In reply to comment #12)
> gives:
>  -rw-r--r-- 1 root root 336996 Nov 5 16:24 /usr/lib/microb-engine/libnssckbi.so
> After creating this link it works with s-c.de! Entering 
> username/password, then I am asked for the password of the certificate 
> and the login proceeds.
> Thanks a lot!

And thank you very much for your patience and the time you invested in testing.
I guess we can mark this bug fixed, then. In PR1.2 there will be a new version
of maemo-security-certman that creates a proper diversion for the library so
that updating the browser will no longer overwrite the link.
Comment 14 Andre Klapper maemo.org 2010-03-15 20:53:53 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).