| Hi Ian,
 On 4/12/2013 2:31 PM, Ian Bull wrote:
 
 
      Hi everyone (p2 & ECF)
         
 Internally, some (many?) organizations have self-signed
          certs (for things like their internal build server). If you
          try to connect to a p2 repository using SSL with a self-signed
          cert it will fail [1]. 
 You should also  be made aware of these (and maybe you will want to
    mark some as dupicates...or at least relate them):
 
 Support for Unknown SSL
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=215929
 See particularly comments 10-19.  As you can see, it was left undone
    because of it's dependency on this bug:
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=231204
 
 For additional context:   I/Scott didn't do the original work on the
    SSL/truststore integration with transport.   Here is the bug
    associated with the original work on integrating the trust store in
    Equinox with ECF: 
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=224196.  As you can
    see, most of the work on the .ssl fragment implementations (i.e. the
    trust store impl for SSLsocketfactory) was done by Matt, Eric, and
    Tom Watson.
 
 With that context...
 
 
 
      
        
 Obviously the default behaviour here is fine, but what
          would be required if someone wanted to accept a self-signed
          cert? On HTTPClient 4, you can set the trust store, but I
          don't think the HTTP Client is accessible from outside ECF. So
          here are a few questions 
 
          
            Does anybody know of an option (system
              property) that HttpClient4 will accept to disable trust
              checking
 Not that I'm aware of.
 
 
 
      
        
          
            Is the creation of the HttpClient
              object extendable such that p2 could create a different
              HttpClient with different TrustManager (or could this be
              exposed) It is possible to create/substitute a higher priority implementer of
    IRetrieveFileTransferFactory (this class is the httpclient 4 impl of
    IRetrieveFileTransferFactory:
 
 org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransferFactory
 
 ...and it creates the instance of apache DefaultHttpClient.
 
 However...I don't know if this would actually address this issue of
    being able to use self-signed certificates...especially without
    disabling the use of a trust store at all.
 
 
 
      
        
          
            If the first two options are non-starters,
              would it be possible to add a system property to ECF to
              disable trust checking (and is this a lot of work)? What do others think? Is this a really bad idea?
            Are others hitting this problem too or is it just me? My impression was that IBM/Equinox didn't want to do something like
    this...based upon the discussion on bugs 215929 and 231204.   I do
    believe that there are people hitting this...both before and after
    the work on the ECFTrustManager ...which is in org.eclipse.ecf.ssl
    fragment, BTW.
 
 Ian I think you should speak with Thomas W, and John Arthorne about
    the bugs above before heading down the road of
    replacing/overriding/disabling the existing trust manager...at least
    in the default impl of ECF's httpclient4 transport.   And for code
    changes to the org.eclipse.ecf.*.ssl fragments...I don't know this
    code terribly well...so if significant additions/changes will be
    needed, it would probably have to involve someone that knows that
    code better than I do (I think Matt and Eric are no longer at
    IBM...although I'm not sure...Thomas would know best, I imagine).
 
 Sorry...unfortunately that doesn't provide a simple answer.
 
 Scott
 
 
 
 
 |