Bug 9355 – OpenSSL certificate store not integrated with maemosec's

Bug 9355 - (int-158993) OpenSSL certificate store not integrated with maemosec's

(int-158993)
Summary:	OpenSSL certificate store not integrated with maemosec's

Status:	NEW

Product:	System software
Component:	general
Version:	5.0:(10.2010.19-1)
Platform:	All Maemo

Importance:	Unspecified normal with 1 vote (vote)
Target Milestone:	5.0+
Assigned To:	unassigned
QA Contact:	system-software-general-bugs

URL:
Keywords:	easyfix, security

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-03-02 10:27 UTC by Lucas Maneos
Modified:	2014-03-08 10:28 UTC (History)
CC List:	4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description Lucas Maneos (reporter) 2010-03-02 10:27:48 UTC

(Forking from bug 9262).

SOFTWARE VERSION:
3.2010.02-8

EXACT STEPS LEADING TO PROBLEM: 
Example 1:
1. Configure a Jabber IM account to a server that requires SSL or TLS and has a
certificate signed by one of the pre-installed authorities, or a user-installed
one.
2. Make sure the Advanced -> Ignore SSL certificate errors option it disabled.
3. Try to connect.

Example 2:
1. Install wget.
2. Start terminal or ssh session.
3. Run "wget https://mail.google.com".

EXPECTED OUTCOME:
Successful certificate verification and connection.

ACTUAL OUTCOME:
Connection fails with a certificate verification error.

REPRODUCIBILITY:
Always.

OTHER COMMENTS:
Fixed (thanks to Juhani) by setting
SSL_CERT_DIR=/etc/certs/common-ca:/home/user/.maemosec-certs/ssl-ca in the
environment somewhere early in the startup process.

I put it in a new file (/etc/osso-af-init/ssl.defs) and "source_if_is" it in
/etc/osso-af-init/af-defines.sh so it's also set for stuff that runs outside
the X session like ssh logins.

Comment 1 Lucas Maneos (reporter) 2010-03-06 12:42:51 UTC

There is one complication: /home/user/.maemosec-certs/ssl-ca and its parent
directory are owned by user:users and mode 0700, so non-user processes
(including root) can't read user-installed certificates.

Since only public server/authority certificates will ever go there (I don't
have any personal certificates, but I assume these would go in ssl-user,
right?), could the permissions be relaxed to 0755?

Comment 2 Juhani Mäkelä nokia

2010-03-08 12:58:17 UTC

(In reply to comment #1)
> There is one complication: /home/user/.maemosec-certs/ssl-ca and its parent
> directory are owned by user:users and mode 0700, so non-user processes
> (including root) can't read user-installed certificates.
> Since only public server/authority certificates will ever go there (I don't
> have any personal certificates, but I assume these would go in ssl-user,
> right?), could the permissions be relaxed to 0755?

Sounds reasonable, although surely root can read these directories regardless
of their permission.

Comment 3 Lucas Maneos (reporter) 2010-03-08 15:39:01 UTC

You are right about root of course, my confusion (I was experimenting with a
daemon that tries to verify certificates after dropping privileges).

Comment 4 Daniel Benoy 2010-05-25 23:11:36 UTC

I have the same symptoms.  You can see that the certificate for my jabber
server is valid by using a web client such as Firefox:

https://benoy.name:5223/

However, I get a 'Certificate error' when I try to establish an SSL connection
to that jabber server with my N900.

I'm using an x509v3 certificate though, so the common name doesn't match
'benoy.name', and matches an entry in 'x509v3 Subject Alternative Name'
instead.  So I was thinking it might be that.

How can I determine whether I have the same bug described here, or if I should
file a separate bug report?

Comment 5 Juhani Mäkelä nokia

2010-05-26 15:13:45 UTC

(In reply to comment #4)
> How can I determine whether I have the same bug described here, or if I should
> file a separate bug report?

Have you tried doing what Lucas did:
export SSL_CERT_DIR=/etc/certs/common-ca:/home/user/.maemosec-certs/ssl-ca
in a new file (/etc/osso-af-init/ssl.defs) and "source_if_is" it in
/etc/osso-af-init/af-defines.sh, then reboot.

If you still get the same error it's probable that the IM client doesn't search
from alternative names. Then I would suggest filing a new bug.

Comment 6 Daniel Benoy 2010-05-27 20:55:03 UTC

(In reply to comment #5)
> (In reply to comment #4)
> > How can I determine whether I have the same bug described here, or if I should
> > file a separate bug report?

Thanks Juhani.  I used Lucas's workaround, and I was able to verify that it was
working by using the 'wget' command example he gave.

However, it's still not recognizing my XMPP certificate.

Bug #10362 opened.

Comment 7 Lucas Maneos (reporter) 2010-08-15 11:53:16 UTC

*** Bug 11035 has been marked as a duplicate of this bug. ***