6096 2008-09-19 13:38:40 +0000 HTTPS certificate: an expired and invalid certificate only triggers a WARN 2008-12-04 14:59:20 +0000 1 1 1 Unclassified mobileOK Basic checker Java Library unspecified PC Linux RESOLVED FIXED P2 normal --- 1 fd abel.rionda oldest_to_newest 21955 0 fd 2008-09-19 13:38:40 +0000 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. 21956 1 fd 2008-09-19 14:00:06 +0000 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. 22676 2 fd 2008-12-04 14:59:20 +0000 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