The spec currently says under 2.4.3 HTTP Response:
 If the certificate is invalid, FAIL
 If the certificate has expired, warn


In MobileOKTrustManager.checkServerTrusted, the check for expiration is performed before the check for validity (the name of the method that checks for expiration is slightly confusing since it's called checkValidity, but that's another matter ;-)), and the check for validity is not performed if the check for expiration fails.


I suggest:
1. to check whether the certificate is self-signed (I don't think we need to parse the chain of certificates, do we? The first one should be enough)
2. to check the validity of the certificate if the chain is not self-signed using:
 tm.checkServerTrusted(chain, authType);
3. to check the certificate is valid at the time of the check afterward, using:
 tm.checkValidity();

This would return a FAIL when a certificate is both expired and invalid, and not only the WARN. It would not return both the FAIL and the WARN, but I don't think we need to go that far.

PS: the changes to come on the way SSL certificates are managed should not affect this behavior.