W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > December 2008

Changes on HTTPS certificates

From: Francois Daoust <fd@w3.org>
Date: Thu, 04 Dec 2008 15:56:25 +0100
Message-ID: <4937EF99.1080401@w3.org>
To: public-mobileok-checker <public-mobileok-checker@w3.org>


I eventually implemented and committed the changes on HTTPS 
certificates, but confirmation that I did things correctly would not be 
a bad thing.
Changes are explained at the end of the email.

One question: is there a reason to keep 
The code is unused (or rather has been re-used in 

I tested things locally but I am not sure how to implement tests in the 
test suite. LinkTargetFormat/7 now returns HTTPS_1, which is, I think, 
correct (in that the domain name is "localhost", and does not match the 

Added HTTPS-1, HTTPS-2 and HTTPS-3.

Added HTTPS-1, HTTPS-2 and HTTPS-3.

Since arbitrary root certificates are to be trusted, the validation work 
cannot be delegated to the default TrustManager, because it will check 
that the certificate is trusted based on the list of trusted root 
authorities available on the system.

I do not know what other kinds of validation the "checkServerTrusted" 
method is supposed to do. Given that one the call parameters is an 
authentication string, I suppose it needs to be checked against the 
certificate (this would typically falls under the HTTPS_3 failure). I am 
unclear what this check consists of in practice. After a bit of reading, 
I decided to check that the authentication type matches the algorithm of 
the certificate's public key. I would appreciate if someone else can 
take a look and validate/invalidate this.

The check on the dates is left untouched.

Validation against the hostname cannot be done at this level, since the 
class is unaware of the requested URI.

Overall, the checkServerTrusted method should not trigger any exception, 
because it would be caught by the main program under a global network 
failure (i.e. HTTP_RESPONSE-1).

This is where the validation against the hostname may be done.

I based the code on the StrictSSLProtocolSocketFactory class in 
Jakarta's HttpClient 3.1's "contrib" code:

The factory now defines an "httperror" private variable. This is OK 
since we do not reuse the factory, although not that great (since that's 
supposed to be a factory). The "normal" behavior should be to raise an 
exception, but that would close the connection and de facto prevent 
further tests from being conducted.

Checks the HTTPS outcome in both the SSL socket factory and the trust 

Received on Thursday, 4 December 2008 14:56:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:20 UTC