Offline Message Error - rsi.hotmail.com

[aliam13_2]

I have compiles Pidgin version 2.5.0 on SUSE 11.0 (64 bit). Every time I receive an offline message as I connect, I get the following error:

Invalid certificate authority signature

The certificate chain presented by rsi.hotmail.com does not have a valid digital signature from the Certificate Authority from which it claims to have a signature.

I do not get this error if there are no offline messages to be delivered.

I can reproduce this error every time. By getting someone to send me an offline message (using the official windows MSN live client), then I sign in with pidgin (on SUSE 11.0). There error then occurs.

After the error has occurred, pidgin behaves as normal, but I do not receive the offline message. this error keeps occurring every time I sign in until i clear the queue of offline messages (by using MSN live).

[bredde]

Same here with Gentoo...

Attached a short part of the log (short because of privacy reasons)

[bredde]

Got it :)

In Pidgin, add the attached certificate (Tools menu). I got the certificate by opening https://rsi.hotmail.com/ in Firefox and exporting the certificate. Surely there are better ways to solve this problem but hey.. Offline messages are working for MSN! :)

[aliam13_2]

Hi,

this indeed fixed the problem. I think this certificate should come as part of the source. This certificate will expire in November 2008.

[khc]

debug message please

[khc]

actually the debug log is here, somehow I missed it. Does this happen if you use --with-system-ssl-certs during configure and point it to the system certificate directory?

[aliam13_2]

If I run configure with the ssl option ./configure --prefix=/usr/local/pidgin --with-system-ssl-certs=/etc/ssl/certs/

followed by a make, and make install. Then sign in (knowing there are offline messages ready to be delivered) then I get the following different dialog box:

---

Accept certificate for rsi.hotmail.com?

The root certificate this one claims to be issued by is unknown to Pidgin. <View Certificate> <Reject> <Accept>

---

If I reject it, and sign out and back in, then I get the dialog again. Viewing the certificate gives me the following information:

---

Common name: rsi.hotmail.com

Fingerprint (SHA1): 87:e7:54:cd:fc:e1:ab:f3:d7:4c:2d:40:a3:e1:c0:3d:92:32:28:d7

Activation date: Wed Nov 28 22:08:54 2007

Expiration date: Thu Nov 27 22:08:54 2008

---

If I accept it, then I get the offline messages and the certificate appears to have been added just as If I had downloaded it manually (from the link above) and added through pidgin's interface - Although I think these two certificates are different.

[khc]

can you get a new debug log after --with-system-ssl-certs?

[QuLogic]

Please try with --enable-nss --disable-gnutls instead.

On Gentoo, try USE="-gnutls".

[latinsud]

I was getting the same error so i've just recompiled with "--enable-nss --disable-gnutls", and this is what happens now: The first time it runs it ask me whether i want to accept the certificate (which expires in november 2008), and i accept it. The next times it works without asking.

It has created this file ~/.purple/certificates/x509/tls_peers/rsi.hotmail.com

Debian etch (stable).

[khc]

I think pidgin as of 2.5.1 ships with a default set of certificates that covers this, but to use our set of certs you will need to configure without --with-system-ssl-certs. I am not sure what it would take each distro to update their certs though.

If you still have a problem after configuring _without_ --with-system-ssl-certs, please let me know.

[aliam13_2]

I have tried version 2.5.1 doing a normal ./configure --prefix=... without any other options including the --with-system-ssl-certs option

I get the same original error message when offline message are delivered:

The certificate chain presented by rsi.hotmail.com does not have a valid digital signature from the Certificate Authority from which it claims to have a signature

[khc]

are the CAs properly installed to <prefix>/share/purple/ca-certs ?

[aliam13_2]

I think the certs are installed correctly. I directory listing of <prefix>/share/purple/ca-cert yeilds:

-rw-r--r-- 1 root root 2151 2008-09-03 10:35 CAcert_Class3.pem -rw-r--r-- 1 root root 2569 2008-09-03 10:35 CAcert_Root.pem -rw-r--r-- 1 root root 1144 2008-09-03 10:35 Equifax_Secure_CA.pem -rw-r--r-- 1 root root 876 2008-09-03 10:35 GTE_CyberTrust_Global_Root.pem -rw-r--r-- 1 root root 1764 2008-09-03 10:35 Microsoft_Secure_Server_Authority.pem -rw-r--r-- 1 root root 1826 2008-09-03 10:35 StartCom?_Free_SSL_CA.pem -rw-r--r-- 1 root root 834 2008-09-03 10:35 Verisign_Class3_Primary_CA.pem -rw-r--r-- 1 root root 1822 2008-09-03 10:35 VeriSign?_Class_3_Public_Primary_Certification_Authority_-_G5.pem -rw-r--r-- 1 root root 827 2008-09-03 10:35 Verisign_RSA_Secure_Server_CA.pem

[khc]

weird, it worked for me when I tested this, although I was using nss at the time. Is that also what you are using?

[gagern]

The Microsoft Secure Server Authority has changed it's certificate. I just added the new certificate, which makes things work for me again. If you check out the Authority Key Identifier of the rsi.hotmail.com certificate attached above and the Subject Key Identifier of the different certificates for Microsoft Secure Server Authority, you will find that they agree for the certificate I just uploaded:

99:8F:A5:F7:1E:81:6F:FA:79:C2:F0:16:3F:B2:54:B1:08:68:47:55

The certificate shipped with pidgin, on the other hand, had this Subject Key Id:

A7:4F:05:FB:D1:8E:41:53:37:95:CA:4B:E1:43:1F:5A:EB:4D:CD:50

For those interested in reproducing my investigation: I did all my work using the openssl command line tools, also available for cygwin:

1. openssl verify -issuer_checks -verbose -CAfile /usr/share/purple/ca-certs/Microsoft_Secure_Server_Authority.pem rsi.hotmail.com

to see that the cert attached by bredde wouldn't match the CA shipped with pidgin, and to get a hint at "authority and subject key identifier mismatch" indicating a change of certificate.

2. openssl s_client -showcerts -connect www.microsoft.com:443

to get the whole chain of certificates, beginning with the new MSSA cert

3. openssl x509 -noout -text -in CERTFILE

to get detailed infos about certificates, e.g. the Subject and Issuer Key Identifiers.

If switching from gnutls to nss does in fact "resolve" the issue as well, as suggested by comments above, I wonder why nss won't complain about a missing certificate, especially as rsi.hotmail.com doesn't send any certificates but its own, and I wouldn't expect any generic SSL library to include the intermediate MSSA certificate. Strange. Probably should be investigated as well.

[gagern]

Of course you shouldn't just take my word that the MSSA certificate attached above is valid. Instead, you can use the intermediate Microsoft Internet Authority certificate I just attached to verify the chain from its root, GTE CyberTrust Global Root:

openssl verify -CAfile    /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem \
               -untrusted Microsoft_Internet_Authority.pem \
               Microsoft_Secure_Server_Authority.pem

The GTE cert seems to be one of the root certificates shipped with mozilla by default. It is probably available in that location on your system. Otherwise you might export it from Mozilla, install the ca-certificates package or get it from some other source you trust.

[khc]

I don't know enough about nss to know if it fetches the intermediate certs, but here's the relevant part in the debug log when I receive a offline message:

(20:18:28) proxy: Connected to rsi.hotmail.com:443.
(20:18:28) nss: subject=CN=rsi.hotmail.com,OU=MSN Hotmail,O=Microsoft,L=Mountain View,ST=California,C=US issuer=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com
(20:18:28) nss: subject=CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com issuer=CN=Microsoft Internet Authority
(20:18:28) nss: subject=CN=Microsoft Internet Authority issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
(20:18:28) nss: subject=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US issuer=CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
(20:18:28) certificate/x509/tls_cached: Starting verify for rsi.hotmail.com
(20:18:28) certificate: CertificatePool x509, tls_peers requested but not found.
(20:18:28) certificate/x509/tls_cached: Couldn't find local peers cache tls_peers
(20:18:28) certificate: Checking signature chain for uid=CN=rsi.hotmail.com,OU=MSN Hotmail,O=Microsoft,L=Mountain View,ST=California,C=US
(20:18:28) certificate: ...Good signature by CN=Microsoft Secure Server Authority,DC=redmond,DC=corp,DC=microsoft,DC=com
(20:18:28) certificate: ...Good signature by CN=Microsoft Internet Authority
(20:18:28) certificate: ...Good signature by CN=GTE CyberTrust Global Root,OU="GTE CyberTrust Solutions, Inc.",O=GTE Corporation,C=US
(20:18:28) certificate: Chain is VALID

So at least it somehow knows what the immediate certs are. CC'ing people who know more about ssl than I do.

[datallah]

Ticket #7028 has been marked as a duplicate of this ticket.

[gagern]

I was sad to notice this bug hadn't been fixed in 2.5.2.

New information as to how the chain building is probably supposed to work: According to "openssl x509 -text" output, the certs contain in the "Authority Information Access" section CA Issuers descriptions specified in RFC2459 section 4.2.2.1 and obsoleted first by RFC3280 and recently RFC5280.

This leads from the certificate sent by rsi.hotmail.com to http://www.microsoft.com/pki/mscorp/Microsoft%20Secure%20Server%20Authority(4).crt and from there to http://www.microsoft.com/pki/mscorp/mswww(3).crt which is signed by the GTE root.

So that's probably the way things are meant to work, and maybe nss does it this way, although Mozilla bug 245609 seems to indicate differently. Might need some more investigation. According to Google CodeSearch, both nss and gnutls mention caIssuers at some point in their sources, although that doesn't necessarily imply they really implement their use correctly.

Maybe a long term goal might be to get both nss and gnutls support this chain building, and to either only ship the root certificate or completely rely on root certificates installed on the system. This might involve modifications to ssl libraries, and they might even outright reject supporting this part of the RFCs. In that case, bugging microsoft to have their server send the whole certificate chain would be the only clean solution I can see.

As both these solutions might take quite some time, I suggest fixing the issue at hand by simply replacing the intermediate certificate shipped with Pidgin, preferrably right now, but at least in time for 2.5.3. The problem of how to get rid of the need for intermediate certificates could be dalt with afterwards, maybe in a new ticket.

[gagern]

https://www.cynops.de/techzone/http_over_x509.html indicates a security issue with caIssuers, although it's most pronounced in a reverse scenario with clients sending forged certs to trick servers into fetching arbitrary URLs. Assuming rsi.hotmail.com has no undue interest in having its clients open any URLs, exploiting this in a theoretical Pidgin setup would involve DNS spoofing as well.

Nevertheless, the existence of this security might be a valid point for Library developers not to implement this feature, and perhaps also a good reason when trying to get Microsoft to have their server send the whole chain itself.

[khc]

Actually I fixed it once, and for some reason I don't really remember, disapproved the change. I just disapproved my disapproval, so things should work in the next release. Thanks for reminding me and bringing it up again.

[rasmuslp]

I am now getting an error regarding receiving offline messages, because the certificate has changed from November 24th, and Pidgin thus doesn't recognice this.

[gagern]

Yes, most parts of the chain changed again. These are the new intermediate certs:

• http://www.microsoft.com/pki/mscorp/Microsoft%20Secure%20Server%20Authority(5).crt
• http://www.microsoft.com/pki/mscorp/mswww(4).crt

I'll attach a bunch of certificate files.

[gagern]

Microsoft Secure Server Authority(5)

[gagern]

mswww(4)

[gagern]

rsi.hotmail.com from 2008-11-24

[khc]

Ticket #7664 has been marked as a duplicate of this ticket.

[khc]

I just found some time to look at this today, it's interesting that this time it fails with nss + --with-system-ssl-certs too, which is the default that (I believe) many distros use. I am not sure what I can do about that...

[khc@…]

(In [04afb3575719a357165d894133156d8c49f3c7a0]):
uncondtionally install some certificates and use them, References #6680. Thanks gagern for supplying the certs