Nicolas Rinaudo wrote: >> Could you clarify what you mean by accept/ignore? I'm not sure what this >> means in the context of Firefox/Safari. > > Right, sorry, that wasn't very clear. > > "Accept": the browser will load the page without complaint. > > "Refuse": the browser will fail to load the page with an error message such > as "Safari can’t establish a secure connection to the server 'localhost'." > > "Ignore": instructing the browser to ignore the fact that the certificate is > self-signed - adding an exception in Firefox, for example. > > All the tests I've described before are on OS X.
OK, from what you're saying, Firefox and Curl work as expected, Safari doesn't and your Restlet 2.0-RC3 based client doesn't either. (I'll leave Safari aside for the moment, as I don't have an OSX machine with me right now.) The main changes that were made regarding SSL between RC1 and RC3 are: 1. Clients no longer use $HOME/.keystore as their keystore by default (it has to be specified if the client wants to use a client-certificate). 2. By default, the SSLContext (on the server connectors) is created by the DefaultSslContextFactory, which follows the defaults of the JSSE Ref guide by default. It will use javax.net.ssl.keyStore, javax.net.ssl.trustStore and related properties if specified, otherwise, the keystore is unspecified (you'd always have to configure it anyway) and the truststore is based on the CA certificates bundled with the JRE. This second change shouldn't break the existing connectors, since it's how they were initialised anyway (except that now, the code is in one place instead of copied across into each connector). It does change the way the Simple connector works, because the simple connector was using the keystore settings for the truststore too. In addition, the Simple connector is set up to ask for an optional client certificate (that's hard-coded in Simple). If the client sends one it doesn't like, this would cause the connection to break. >> are you using client-certificates? >> Could you explain what configuration you use for the client? (In >> particular w.r.t the trust store?) > > I'm not using client-certificates, no. > To be honest, I've no idea what a trust store is. The only thing I can think > of that might be related to that is the code we use in our tests to disable > SSL certificate validation: > - set the default host name verifier to an instance that will accept anything. > - set the trust manager to a pass-through implementation. The trust store is the store used by most trust managers (in particular the default one) to load its trusted certificates from. If your client sets its own trust manager as a pass-through implementation, it's likely not to be used. > I'd be happy to post the code if you need me to. That could help indeed. It might have to do with how this trust manager is written and passed to the connectors. >> for example, you would have to >> put your server's self-signed cert into the client's truststore for it >> to be trusted by the client). > > This confuses me a bit - I thought that's exactly what I did when I told > Safari to add the certificate to the list of trusted certificates. Once I've > done that, however, Safari still refuses to load pages. > >> I'm not sure where the change in cipher suites comes from, >> but it shouldn't affect how the certificates are trusted. > > What confuses me is that even using the "enabledCipherSuites" and > "disabledCipherSuites", I can't change these. Are these instructions ignored > in the new version ? They're not, but not all connectors support them in the same way unfortunately (in some you can enable, in some you can disable). There's little we can do about it, since it depends on the underlying library support (I got a patch in for Jetty a few weeks ago, but I'm not sure it's made it into the release yet). Best wishes, Bruno. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2595999
