Tag: ssl

PositiveSSL not working with Android?

Namecheap currently offers one of the most affordable ways to get a (not self-signed) SSL cert to use with your web-/mailserver – the only drawback being, that it isn’t signed by a CA Root, but through some subsidiaries, which means you’ll also have to install a supplied CA bundle on the server or else you’ll get a bunch of SSL errors.

With dovecot as POP/IMAP server, that’s actually quite easy – just put all the certs in single file, starting with your servers cert and followed by the three certs supplied by Namecheap/Comodo.

This should work fine with most mail clients, like Thunderbird or Evolution. The cert also worked with Apache for HTTPS. But for some reason, it didn’t work with my Android mail app.

Turns out, Android can be quite picky about the order of the cert chain…

#~$ echo|openssl s_client -connect yourserver.tld:993
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=yourserver.tld
   i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
 1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
   i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
 3 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

If the certs are in any other order, Android threw an error. So your cert file should contain (again: in that order):

  1. Your Cert as supplied by Namecheap/Comodo/…
  2. PositiveSSLCA.crt
  3. UTNAddTrustServerCA.crt
  4. AddTrustExternalCARoot.crt

Firefox blows up VMware Server 2 webinterface

After upgrading Firefox on my main workstation to a more up-to-date release (3.6), it turns out I can’t access the Webinterface of any of my VMware Servers. While some kind of glitch every now and then is to be expected from this “somewhat” buggy piece of sh… uhm, code – this time, logging with Firefox actually manages to crash the management application on the server itself. Yeah, that’s right – at that point you can’t even access it with another browser or the VIC until you kill the hostd and do a /etc/init.d/vmware-mgmt restart. It isn’t even some kind of ancient beta release, but 2.0.2 – the most recent release as of now. WTF?

According to the logs there appears to be some kind of SSL issue:

SSL Handshake on client connection failed.

Turns out Web Access can’t handle SSL3 and Firefox 3.6 has SSL2 disabled per default. Why this manages to crash an application on the server boggles my mind, but at least there’s an easy workaround until VMware manages to fix this:

Go to your about:config page and set security.enable.ssl2 from false to true.

That’s it, done. At least it worked for me – no more issues whatsoever.