Sanjiva Weerawarana wrote:
I don't think validation is what's needed .. if you validate it'll fail anyway. What we need to do is inform the user that the cert is "not good" (not signed by a trusted CA, expired, whatever) and let the user decide whether they want to go ahead anyway.
Browser does this anyway ... if the users trust the external site they can add the cert into trusted site lists in Firefox and IE7(using cert stores in Windows), why do we need to duplicate that process?
Thanks, Ruchith
Sanjiva. Tyrell Perera wrote: Good point Ruchith. We don't 'validate' the certificates at present. We just inform the user when there isn't a trusted certificate in his/her keystore for the site in question. The user can then go on to either download the public cert from the site and upload or type the URL of the site, in which case we obtain the certificate chain from the site and add it to the user keystore. Is there a way to validate a certificate using the Java Security APIs as well? If so I can add a verification/validation routine prior to cert addition to keystore. Tyrell Ruchith Fernando wrote: | Hi Tyrell, | | Tyrell Perera wrote: |> |> Update: |> |> Now a user can just type the URL of a trusted site and the certificate |> chain will be retrieved and added to the user keystore by the Mashup |> Server. |> | | IMHO the failure at this point is very important. Do we first show the | user that the site the user is trying access does not come with a valid| cert? Basically we should not automatically bypass any security provided| by the browser to reject invalid certificates. We can do so only if the | user really wants to access the site. IMHO in practice as long as the | users interact with legitimate sites this issue will not arise. | | Thoughts? | | Thanks, | Ruchith | |> |> Tyrell |> |> Tyrell Perera wrote: |> | FYI |> | |> | We now have a keystore per user along with keystore management |> | functionality exposed in the UI. It works as follows at present. |> | |> | ~ - A keystore is 'cloned' using the server keystore at user |> registration |> | and stored in the registry. |> | |> | ~ - A user can manage the certificates in his/her keystore using the |> | 'Certificate Manager' page, accessible through the 'Tasks' panel |> | |> | ~ - The management UI allows a user to add trusted certificates to |> sites |> | ans delete them if required |> | |> | ~ - A custom protocol handler is in place, which retrieves a user|> | keystore from the registry and uses the certificates stored within to|> | make https connections on demand (Currently the Sharing service uses |> this). |> | |> | |> | Example scenario |> | ---------------- |> ||> | - User tries to share a mashup to another server in a separate domain. |> | HTTPS is required and a certificate for that domain is not available in|> | the user keystore. |> ||> | - Sharing fails. The dialog informs the user the reason for the failure|> | along with a link to the 'Certificate Manager' page. | |> ||> | ~ - The User obtains the public certificate for this domain and adds it |> | to his/her keystore and retries. The sharing service picks up the new|> | certificate and successfully shares the mashup. |> | |> ||> | We can potentially extend this feature to obtain certificates just by|> | giving the URL of a site. The WSRequest host object, will have to be |> | changed to use the custom protocol handler as well. |> | |> | |> | Tyrell |> | |> | |> |> _______________________________________________ |> Mashup-dev mailing list |> [email protected] |> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev |> |> |
_______________________________________________ Mashup-dev mailing list [email protected] http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mashup-dev mailing list [email protected] http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
