maemo.org Bugzilla – Bug 8268
Unable to authenticate on light.webmoney.ru with user's SSL certificate.
Last modified: 2010-03-15 20:53:53 UTC
You need to
before you can comment on or make changes to this bug.
(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
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?).
User can login to secured areas of web sites by authorising with a SSL
SSL certificate login does not works at least on https://light.webmoney.ru
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
Maybe somehow related to bug 349 (i.e. regression, etc).
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.
Assigned to myself and moved to the proper product
(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
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.
(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
And I never did get a dialogue windows asking for the key, even when it worked.
On my device runs 3.2010.02-8.
(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.
(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?
(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
Thanks for your help,
(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
> 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
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.
(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
(In reply to comment #9)
(In reply to comment #9)
Public key encryption is set to rsaEncryption, 2048bit, signature is
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.
(In reply to comment #10)
> Public key encryption is set to rsaEncryption, 2048bit, signature is
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
> 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
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.
(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
-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!
(In reply to comment #12)
> -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.
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).