This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Actually, I think I'm slightly wrong for 1. Checking the first certificate is enough to detect a self-signed certificate, but won't be enough to detect arbitrary root certificates, as required by the soon-validated new rules.
I implemented the changes, although confirmation that the check on the authentication type would probably be a good thing. See details in: http://lists.w3.org/Archives/Public/public-mobileok-checker/2008Dec/0000.html