Thanks for reporting this.

I'm also having the same problem when trying to use an XMPP server whose
certificate is signed by the same authority.  The StartCom signing certificate
is pre-installed in certificate manager[1], but verification fails anyway.

Installing the same certificate manually and selecting all the options
(server/email/wlan) makes no difference.

Connecting with the browser do the server's ejabberd http interface (which uses
the same certificate) works fine though.

[1] /etc/certs/common-ca/4e0bef1aa4405ba517698730ca346843d041aef2.pem

(In reply to comment #1)

I concur that server certificate verification works correctly over https, and
that manually importing the server certificate (for any combination of server,
email or wlan) does not help (this is to be expected as the root CA is
pre-installed).

However, the issue isn't strictly related to Startcom-issued certificates. For
example, I get the same warning from modest when trying to connect to
imap.gmail.com over SSL on port 993.

It seems that applications other than microb do not check server certificates
against the root CAs installed in /etc/certs/common-ca. I've udpated the
summary accordingly. Are you sure "Settings and Maintenance" & "Control Panel"
are the right product and component for this?

(In reply to comment #2)
> However, the issue isn't strictly related to Startcom-issued certificates. For
> example, I get the same warning from modest when trying to connect to
> imap.gmail.com over SSL on port 993.

Thanks for testing.  My other self-installed root certificates (namely CAcert)
seem to work fine, but they were installed on 1.2009.42-11 so bug 8276 may be
related.

> Are you sure "Settings and Maintenance" & "Control Panel"
> are the right product and component for this?

Frankly, no.  Relevant products/components were this (where the certificate
manager lives) and Browser/MicroB engine (libnss3) (both are very non-obvious,
I know).  As modest uses libnss3 and telepathy-gabble uses openssl I opted for
the library-independent component.   It's also possible that we have two
separate application bugs.

Let's see what, if anything, changes with PR1.2...

(Adding security keyword as this would make most users disable certificate
validation and expose themselves to spoofing).

(In reply to comment #3)

> As modest uses libnss3 and telepathy-gabble uses openssl I opted for
> the library-independent component.   It's also possible that we have two
> separate application bugs.

You mention telepathy-gabble uses openssl. On the n900, "openssl version -d"
returns /usr/lib/ssl. Have you tried symlinking /usr/lib/ssl/certs to
/etc/certs/common-ca (just a thought) ?

> (Adding security keyword as this would make most users disable certificate
> validation and expose themselves to spoofing).
> 

Yes, this seems quite important to me too. In fact I'm surprised that no one
else has mentioned the issue, especially in relation to modest - there must be
quite a few people using imaps or pops out there...

I don't understand why microb can validate certs whereas modest can not,
especially if they're both using libnss3.

I'm assuming I'm not alone in getting a certificate error trying to connect to
imap.gmail.com on port 993?

(In reply to comment #4)
> Have you tried symlinking /usr/lib/ssl/certs to
> /etc/certs/common-ca (just a thought) ?

Thanks for the suggestion :-)

That won't quite do it as it omits user-installed certs, but "ln -s
/etc/certs/common-ca/*.0 /home/user/.maemosec-certs/ssl-ca/*.0
/usr/lib/ssl/certs/" fixed that part for now.  Of course it needs manual
intervention whenever new certificates are installed so it's not ideal.

> I'm assuming I'm not alone in getting a certificate error trying to connect to
> imap.gmail.com on port 993?

No, I don't have an actual gmail account but I could reproduce this by getting
rid of /home/user/,modest/cache/*.db (they were created on much earlier
firmware when certificates were working a bit better) and configuring a "Google
Mail" account in modest with with a dummy username & password (the config ends
up as imaps://imap.gmail.com:993)

Thank goodness it's not just me going mad with this. I've been struggling with
this issue since PR 1.1.1 and thought it was something I had installed. Was
about to reflash when I came across this bug report.

I too suffer from prompts about IMAP SSL certificates being bad, with Gmail and
also my own personal mail server, MDaemon. I use a Startcom certificate which
works fine with Thunderbird etc etc, but with Modest it will work once maybe
twice after accepting the prompt, but after that my Windows server starts
alerting me with Schannel errors and the IMAP service on MDaemon to fail the
connections. The only way I know Modest isn't working is because new mails stop
appearing and new outgoing mails sit in the Outbox as "Failed" - it doesn't
even report the connection error.

Is there an ETA on PR 1.2 with this fixed as this is killing my ability to work
properly away from my PC?

Comment 7 Juhani Mäkelä 2010-03-01 10:37:49 UTC

Hi all! The certificate verification is supposed to work also with modest and
in this release, but it seems that in the upgrade procedure of PR1.1.1 there is
something odd that causes these troubles (Re: Bug#8268). Here is some
background:

> I don't understand why microb can validate certs whereas modest can not,
> especially if they're both using libnss3.

Microb and modest access the common certificate store in different ways. Modest
has /usr/lib/libmaemosec_certman.so.0 configured as a security module in
secmod.db (the clean way). Microb does not allow one to override its default
certificate store by means of configuration, which is why the library
/usr/lib/microb-engine/libnssckbi.so is made a symbolic link to
libmaemosec_certman.so.0.0.0 (the rude way).

The reason of the problems is most likely that the security module
configuration in /home/user/.modest/cache/secmod.db has disappeared. You can
check this on terminal by command

nsscfg -c /home/user/.modest/cache -i

which should display something like this:

Module: Maemosec certificates
Library: /usr/lib/libmaemosec_certman.so.0.0.0
isCritical=no
isModuleDB=no
moduleDBOnly=no
trustOrder=70

...among other things (i.e. NSS Internal PKCS #11 Module). If
libmaemosec_certman is not mentioned, the configuration has been lost.
Unfortunately the directory name "~/.modest/cache" does not convey that it
actually contains important configuration data that should not be deleted:

(In reply to comment #5)
> ...
> No, I don't have an actual gmail account but I could reproduce this by getting
> rid of /home/user/,modest/cache/*.db (they were created on much earlier
> firmware when certificates were working a bit better)

The configuration can be restored by copying the *.db files to ~/.modest/cache
from /etc/skel/.modest/cache or by command

nsscfg -c /home/user/.modest/cache -m "Maemosec certificates"

Could you please verify if this is the reason of the problems you are
experiencing?

(In reply to comment #7)
> nsscfg -c /home/user/.modest/cache -i
> 
> which should display something like this:
> 
> Module: Maemosec certificates
> Library: /usr/lib/libmaemosec_certman.so.0.0.0
> isCritical=no
> isModuleDB=no
> moduleDBOnly=no
> trustOrder=70
> 
> ...among other things (i.e. NSS Internal PKCS #11 Module). If
> libmaemosec_certman is not mentioned, the configuration has been lost.
> Unfortunately the directory name "~/.modest/cache" does not convey that it
> actually contains important configuration data that should not be deleted:

Yes, the "Maemo certificates" was missing

> 
> The configuration can be restored by copying the *.db files to ~/.modest/cache
> from /etc/skel/.modest/cache or by command
> 
> nsscfg -c /home/user/.modest/cache -m "Maemosec certificates"
> 
> Could you please verify if this is the reason of the problems you are
> experiencing?
> 

Running this and the previous command and it appears, but then rebooting the
handset fixed Gmail - I can't test my own server just yet, but this is
definitely progress. Many thanks.

(In reply to comment #7)
> The reason of the problems is most likely that the security module
> configuration in /home/user/.modest/cache/secmod.db has disappeared. You can
> check this on terminal by command
> 
> nsscfg -c /home/user/.modest/cache -i

Full output looks fine here:

Module: NSS Internal PKCS #11 Module
Library: (null)
isCritical=yes
isModuleDB=no
moduleDBOnly=no
trustOrder=75

Module: Maemosec certificates
Library: /usr/lib/libmaemosec_certman.so.0
isCritical=no
isModuleDB=no
moduleDBOnly=no
trustOrder=70

> The configuration can be restored by copying the *.db files to ~/.modest/cache
> from /etc/skel/.modest/cache

After copying the files over so that:

$ md5sum /home/user/.modest/cache/*.db /etc/skel/.modest/cache/*.db|sort
a5ae49867124ac75f029a9a33af31bad  /etc/skel/.modest/cache/cert8.db
a5ae49867124ac75f029a9a33af31bad  /home/user/.modest/cache/cert8.db
dda6f3f2341531f22cc9f8b3ec251677  /etc/skel/.modest/cache/key3.db
dda6f3f2341531f22cc9f8b3ec251677  /home/user/.modest/cache/key3.db
f5ad0e29f7f56636638b84eb5fe5bb82  /etc/skel/.modest/cache/secmod.db
f5ad0e29f7f56636638b84eb5fe5bb82  /home/user/.modest/cache/secmod.db

and removing /home/user/.modest/cache/mail/.camel_certs/*, I can confirm that
both gmail and my personal accounts (server certificate signed by CAcert, root
certificate user-installed) work without certificate validation warnings. The
output of nsscfg -i hasn't changed though.

Is the openssl case a separate bug then?

Comment 10 Juhani Mäkelä 2010-03-01 14:09:14 UTC

(In reply to comment #9)
> and removing /home/user/.modest/cache/mail/.camel_certs/*, I can confirm that
> both gmail and my personal accounts (server certificate signed by CAcert, root
> certificate user-installed) work without certificate validation warnings. The
> output of nsscfg -i hasn't changed though.

Right, thank you very much. So the configuration was there, but for some reason
modest couldn't use it until the configuration was reset. I have to look into
this more closely, could be some kind of a version mismatch.

> Is the openssl case a separate bug then?

I suppose it is. Instant messaging uses OpenSSL directly via libloudmouth, and
it seems that its integration with maemosec_certman is somehow defective. You
can try to fix this by setting the following environment variable for the XMLPP
client process:

export SSL_CERT_DIR=/etc/certs/common-ca:/home/user/.maemosec-certs/ssl-ca

Comment 11 Juhani Mäkelä 2010-03-01 14:12:38 UTC

(In reply to comment #10)
> can try to fix this by setting the following environment variable for the 
> XMLPP client process:
> export SSL_CERT_DIR=/etc/certs/common-ca:/home/user/.maemosec-certs/ssl-ca

For the instant messaging client, that is. The protocol is XMPP of course, not
XMLPP. Sorry that this sounds so flaky, it's quite possible that instant
messaging with TLS connections has never worked properly.

Comment 12 Juhani Mäkelä 2010-03-01 14:30:25 UTC

(In reply to comment #10)
> export SSL_CERT_DIR=/etc/certs/common-ca:/home/user/.maemosec-certs/ssl-ca

The place to add this setting is /etc/X11/Xsession.d/00settings

Although the "fix" has worked for Gmail, it's still causing my MDaemon IMAP
server or bomb out with errors - the application simply tells me that it's
unable to connect. Something is still not right and I'm not sure what to do to
get more info to you to help diagnose this.

(In reply to comment #10)
> > Is the openssl case a separate bug then?
> 
> I suppose it is.

Ok, updating summary and reassigning back to email.

> export SSL_CERT_DIR=/etc/certs/common-ca:/home/user/.maemosec-certs/ssl-ca

Wow, you learn something new every day (openssl doesn't seem to document that
variable anywhere), thanks!

I confirm that setting this does the trick, filed bug 9355.

(In reply to comment #13)
> Although the "fix" has worked for Gmail, it's still causing my MDaemon IMAP
> server or bomb out with errors - the application simply tells me that it's
> unable to connect. Something is still not right and I'm not sure what to do to
> get more info to you to help diagnose this.

That sounds unrelated, if it's the server side that's dropping the connection.

Could you file a new report and attach a modest debug log (see
<https://wiki.maemo.org/Bugs:Stock_answers#Debugging_the_connection_to_the_mail_server>)
there?  If you can get any server-side logs please include them as well.  
Thanks!

(In reply to comment #15)
> 
> That sounds unrelated, if it's the server side that's dropping the connection.
> 
> Could you file a new report and attach a modest debug log (see
> <https://wiki.maemo.org/Bugs:Stock_answers#Debugging_the_connection_to_the_mail_server>)
> there?  If you can get any server-side logs please include them as well.  
> Thanks!
> 

I'll do so, but I really don't think it's "unrelated" - both accounts were just
fine until PR 1.1.1, the server certainly hasn't changed and none of my other
mail clients, Thunderbird/Outlook/Profimail have any IMAP issues. Then they
both started misbehaving on the N900 at the same time.

(In reply to comment #16)
> I'll do so, but I really don't think it's "unrelated" - both accounts were just
> fine until PR 1.1.1, the server certainly hasn't changed and none of my other
> mail clients, Thunderbird/Outlook/Profimail have any IMAP issues.

It is possible for a single release to contain more than 1 unrelated bugs ;-)

To clarify: a certificate validation error would cause the client to terminate
the connection.  Since in your case the connection is terminated by the server,
the problem must have a different cause.

(In reply to comment #7)

> nsscfg -c /home/user/.modest/cache -i
> 
> which should display something like this:
> 
> Module: Maemosec certificates
> Library: /usr/lib/libmaemosec_certman.so.0.0.0
> isCritical=no
> isModuleDB=no
> moduleDBOnly=no
> trustOrder=70
> 
> ...among other things (i.e. NSS Internal PKCS #11 Module). If
> libmaemosec_certman is not mentioned, the configuration has been lost.
> Unfortunately the directory name "~/.modest/cache" does not convey that it
> actually contains important configuration data that should not be deleted:

Yes, the configuration had been lost (although "~/.modest/cache" did contain
the .db files).

> The configuration can be restored by copying the *.db files to ~/.modest/cache
> from /etc/skel/.modest/cache or by command
> 
> nsscfg -c /home/user/.modest/cache -m "Maemosec certificates"
> 
> Could you please verify if this is the reason of the problems you are
> experiencing?

That fixed it for me. Thanks a lot!

I think the bug should stay open though, until it is known why modest "lost"
the configuration...

(In reply to comment #17)

Ok, I have filed a new bug https://bugs.maemo.org/show_bug.cgi?id=9363


> (In reply to comment #16)
> > I'll do so, but I really don't think it's "unrelated" - both accounts were just
> > fine until PR 1.1.1, the server certainly hasn't changed and none of my other
> > mail clients, Thunderbird/Outlook/Profimail have any IMAP issues.
> 
> It is possible for a single release to contain more than 1 unrelated bugs ;-)
> 
> To clarify: a certificate validation error would cause the client to terminate
> the connection.  Since in your case the connection is terminated by the server,
> the problem must have a different cause.
>