WiscChat - About Certificate Warnings
Many people will see a certificate warning when they try to connect to WiscChat using an XMPP client (Psi, Pidgin, Adium, Messages/iChat, etc.) In summary, on 2/20/2010 the certificate that WiscChat was using expired, and the WiscChat team installed a different certificate that is generating these warnings because it does not match the domain.
How do I get this warning to stop happening?
- Psi: click Trust this domain when you receive the warning, then close/quit and restart Psi.
- Pidgin: click Accept when you receive the warning.
- Adium and Messages/iChat: WiscChat - Certificate error during connection for iChat / Apple Messages
Why is my client showing me this warning?
When your client connects to WiscChat, it is actually connecting to a server named wiscmail.wisc.edu. The certificate that is presented to the XMPP client matches wiscmail.wisc.edu and is signed by a trusted authority (GeoTrust.) The reason your client is giving you a warning that it thinks the certificate should match the domain of your WiscChat address (wisc.edu or yourdomain.wisc.edu or yourdomain.org.)
Strictly speaking, the clients are behaving properly because there is a possibility that a malicious person could trick your computer into getting the incorrect server name from DNS. The client is warning you that you might be connecting to a malicious server. You should definitely verify that the certificate matches wiscmail.wisc.edu and is properly signed by a trusted authority.
To verify the certificate in Psi, do the following:
- Click Details button within the certificate warning screen.
- You should be presented with the following screen:
Why didn't this warning appear in the past?
When WiscChat was first introduced, this warning actually did appear to all users. However, in 2009, we decided to install a wildcard certificate - *.wisc.edu - that matches wisc.edu and anything.wisc.edu. This certificate prevented XMPP clients from issuing warnings to users because it matched the majority of the domains that are hosted by WiscChat.
Why wasn't the wildcard certificate renewed?
We didn't renew the wildcard certificate because the certificate authority that issued the original certificate ceased to exist. This certificate authority was managed by the XMPP Standards Foundation. The XSF was issued an intermediate root certificate for the purposes of signing certificates for use with XMPP services such as WiscChat. Wildcard certificates issued by the XSF certificate authority couldn't practically be used on a web server for validating https connections, which complies with our tolerance for the use of wildcard certificates (see below.)
Another factor that mitigated the necessity for the renewal of the wildcard certificate is that most XMPP clients now provide better mechanisms to allow users to permanently trust the wiscmail.wisc.edu certificate as valid for the domain they are connecting to.
Why wasn't a new certificate provider used?
At this time, there are no known certificate authorities that offer wildcard certificates specifically for XMPP use.
Why isn't a generic wildcard certificate used instead?
There are two basic reasons:
- The WiscChat team does not think that it is appropriate to obtain a generic wildcard certificate for the wisc.edu domain. It would introduce a security risk to campus if it were ever compromised. Ideally, we feel that no one should be able to obtain a wildcard certificate for wisc.edu since a malicious person could use the certificate to host https pages for wisc.edu, login.wisc.edu or any other subdomain. We must abide by our own principles.
- Even if the security risks were ignored, wildcard certificates do not completely solve the "certificate warning" problem with clients. Not all of the domains hosted by WiscChat match *.wisc.edu, and the certificate does not match the components of these domains, such as "conference.somedomain.wisc.edu".
Because of these two factors, and in addition to the increased usability with XMPP clients, the WiscChat team decided that it is best to not use a wildcard certificate and instead lobby the XMPP Standard Foundation to implement a suitable alternative for domain name authentication, assertion and delegation.
What will happen in the future?
We don't know how this will play out. If it is any consolation, we aren't the only ones in this situation, so we won't be the only ones pushing for a reasonable solution. For example, any domain that outsources to Google Apps experiences the exact same certificate warnings when their users connect with an XMPP client.
The XMPP Standards Foundation is hashing out various standards for domain name authentication, assertion and delegation. The WiscChat team is monitoring these discussions and is contributing when necessary. We hope that a suitable solution results from these standards.
If the standards do not evolve in a positive way, the WiscChat team could look into alternative solutions, such as allowing domain owners to upload signed certificates and keys for their domains into WiscChat (assuming that they are comfortable doing so.)