PSM:CertPrompt

From MozillaWiki
Jump to navigation Jump to search

Trying to handle automatic certificate selection is difficult. Currently both IE and PSM products have fairly noticeable corner cases. This page is meant to document how PSM currently and what kinds of problems it generates in deployments.

Current Interactions

IE Current Usage

After restarting IE, it will always prompt for a certificate, even if no certificate is valid. ?IE lists all the user certificates without reguard to the certificate list presented to it?. Once IE has a cert selected for the site (or the user as selected no certificate for the site), IE will always use that certificate (or lack of certificate) for that site. The only way to change that is to use the button to clear IE's SSL cert cache. IE will prompt the user even if there is no valid certificate available.

PSM Current Usage

PSM has 2 modes in certificate selection: 1) ask every time. 2) select automatically.

SSL sends a list of CA certificates that are acceptable for Client Authentication. Most HTTP servers build this list automatically whenever that server has CA Certificates which are configured to validate user certificates.

If select automatically is set, PSM will find all the unexpired user certificates, and filter out those certificates which do not chain to one of the certs in the CA list. The first cert in the list for which the user has a valid private key is selected. If no certs survive the sort, no certificate is sent.

If 'ask every time' is set, PSM will find all the user certs (expired and unexpired), and filter that list for certs in the CA list. If no certs are found, then no certificate is sent and the user is not prompted. If any certificates are found (even just one), the user is prompted to select a certificate. The user has to option of selecting no certificate, in which case no certificate is sent.

Note that PSM goes through this everytime a full SSL handshake with request or require client auth is sent.

Server Action on When NoCertificate

If the requested certificate is not present, and the server did an SSL require certificate, the connection will fail. If the requested certificate is not present and the server did a 'request but not require certificate', the SSL connection will complete and the server CGI's will be presented with and empty certificate.

Client Authentication Scenarios

Basic Client Authentication: The client has exactly one certificate installed and it matches with the CA list sent to the user.

This is the base scenario that all the software has been designed for initially. Currently in PSM, 'select automatically' will present the one valid certificate to the server automatically. 'Ask every time' will present a dialog with the single certificate when you first connect. The user may refuse to use the cert (in which case no cert is sent). Future connections will only prompt if the ssl session id is cleared (either in the server or in the client). In IE the user will be prompted to supply the single valid certificate. The user may refuse the cert, in which case no cert is sent. IE will always use that certificate to authenticate, even if the ssl session id is cleared, until the user closes IE or hits the 'Clear SSL Cache' button.

Client Authentication with no Certificate: The client has not client auth certificates.

This is the 'common' case of a user trying to go to a site that uses client authentication. In the current PSM case, both 'select automatically' and 'Ask every time' will present no certificate and no prompt will be displayed to the user. If the server required client authentication, a connection error will be presented. If the server only requested client auth, the SSL connection completes and the server can present either an appropriate error, or request some sort of alternate authentication. PSM will not check for the existance of a new certificate unless the ssl session id is cleared. EI will always present an empty dialog. Once the user clicks 'cancel', EI will always present no certificate to the server, even if a new certificate appears and the server clears the ssl session id.

SmartCard Client Authenticate: The same as basic authentication except the one certificate lives in a smartCard that can be removed.

If the smartCard is present, any initial connection will operate just like "Basic Client Authentication" above. If the smartCard is removed, then PSM will clear the ssl session id, so future ssl connections will operate as if the smartCard is not present. In addition PSM can send a smartcard removal event to the webpage, which can be handled in javascript to reload the page. This allows automatic logout symantics. For IE, smartCard removal will not trigger any clearing of ssl session id, or change IE's cached notion of what certificate to use. The former has the effect of keeping the user logged in even if the card has been removed. Only clicking on the 'Clear SSL cache' button clear IE's session id and it's idea of what cert to use to authenticate. If the server clears the session id, and the smartCard has been removed IE will prompt for the smartCard to be reinserted.

If the smartCard is not present, the initial connection will operate just like "Client Authentication with no Certificate" above. If the smartCard is later inserted, PSM can send a smartCard insertion event to the web page. In this case the server will have to clear the ssl session id as PSM does not yet provide a way to do it. If the ssl session id is cleared and the page redrawn, PSM will operate again like "Basic Client Authentication". In the IE case, a later smartCard insertion will not trigger any new redraw, nor will IE reprompt the user if the ssl session id is cleared. The user will have to manually click the 'Clear SSL cache' button and manual reload the page.

More than one certificate, only one is valid: The client has more than one certificate, but only one matches the CA list.

PSM treats this exactly the same as one certificate. Only the matching certificate is placed in any prompts. In IE all certificates are placed in the initial prompt and the user has to figure out which certificate is valid.

SmartCard Authentication with multiple certs, only one valid: The client has more than one certificate, the one valid certificate lives on the smartCard.

In PSM, this is exactly like the "SmartCard Client Authentication" case.*

In IE, if the smartCard is not inserted, the user is presented with the list of certificates which do not mach the CA list sent by the server. The user can select from the list, or select none of the certs. IE remembers this choice even after the smartCard is inserted. The user will have to click the 'Clear SSL Cache' button to be able to authenticate with the smartCard.

  • This needs to be verified. A code review of PSM seems to indicate this is the case, but there has been some reports that if 'ask every is set', very different things happen.

More than one certificate is valid: The client has multiple certificates that are valid (matches the CA list).

This can happen either because the user has overlapping valid certificates (the user has renewed a certificate before it has actually expired), or the user has multiple certificates associated with different roles on the server.

In this case if 'Select automatically' is sent in PSM, PSM will select the 'most appropriate certificate'. In the case where different roles may be associated with the different certificates, PSM may or may not pick the correct certificate (as it has no information about what role the user wishes to use). If 'Ask Every' is set, PSM will present a dialog with all the certs which match the CA list, including expired certs.

IE treats this case the same as "More than one certificate, only one is valid".

Client has expired certificate: The client has certificates which are expired, but match the CA.

This scenario typically happens if either 1) the user lets his certificate laps, or 2) in the renewal case. In PSM only unexpired certificates that match the CA are used in the 'Select automatically' case. If there are no unexpired certificates, PSM sends no certificates. In the 'Ask every' case expired certificates are listed at the end and marked expired. IE lists all certificates, expired or not.

Multiple certificates, none match: The client has multiple certificates, but none match the server list. This can be because 1) the client has never been registered with the server and cannot authenticate to the it, or 2) the server does not include a complete list of CA in it's CA list, or the CA list is incorrectly configured. This case can happen in a bridged environment.

PSM treates the same as "Client Authentication with no Certificates".

Since IE does not filter the CA list, IE treats this case the same as "More than one certificate, only one is valid".

Additional complications

The interaction between clients and servers with failed SSL connections is currently poor in both IE and pre-Firefox 1.5 (Firefox 1.5 needs additional testing here). In addition is very difficult to set up any SSL server such that it does not create failes SSL connections when doing client auth.

When the SSL connection fails, there is no communication channel between the client and the server. Sometimes clients will get and error code, or an SSL alert, but most often they just quick loading the page, giving the user no information about the failure. Because there is no connection, the normal server methods of redirecting the user to an error page does not work.

The SSL connection can fail in the client authentication case for the following reasons:

  • The client sent to certificate in the case where SSL issued a 'Require client auth' connection.
  • The client sent a certificate that the server things is expired (either because the certificate is expired, or the servers clock is set incorrectly).
  • The client sent a certificate that does not chain to any of the CA's trusted for client authentication.
  • The client certificate can not validate for other reasons (missing extensions, key usages, policy, signature is bad, etc).

Fortuntely, if the server is talking to existing Firefox clients, and the server is configured correctly (with the correct time), and the server is configured to 'Request not require' client auth, then SSL connection failures become fairly rare, and only exist if 1) the client cert has been corrupted, or 2) the client cert is expired and the user's clock is set incorrectly. While these cases are rare, they should still fail in a graceful way that gives the user a hint at what the problem might be.

Apache has an option to override client certificate verification to help debug setting up client auth connections, but it does not have an option to validiate the certificate and redirect if the certificate validation fails.

It's clear there needs to be some server UI work to make configuring client authentication for the server side much easier.

Issues with these scenarios

IE's client authentication has the advantage of being a simple programming model (Find all the certificates, present them to the user, remember the user's selection forever). This model, however breaks down in the following cases:

1) If there are no certificates available, users are confused by 
   and empty   dialog box asking them to select a certificate.
2) If multiple certificates are available on the system, IE does 
   nothing to help the user understand which certificate should be
   used to authenticate.
3) Because of the current poor client/server interaction, the 
   choice of the wrong certificate often gives the user no input 
   as to why the connection failed.
4) The model does not work well when the certificate can appear or 
   disappear from the system (such as the smart card case).

The model does work well in the following cases:

1) The user has a single, fixed certificate.
2) The user has multiple certificates which represent different roles,
   and the user is sophisticated enough to identify the proper certificate.
3) The case where the server does not send a list of CA Certificates, or 
   the list of CA certificates is not complete, and the user is sophisticated
   enough to select the proper certificate.

PSM's 'always select' is targetted to the less sophisticated user. It breaks down in the following cases:

1) Switching from no certificate to having a certificate 
   (smartCard insertion) if the server does not invalidate the 
   session id (server performance issue).
2) The user has multiple certificates which represent different roles.
3) The server does not send a list of CA Certificates, or the list 
   of CA certificates is not complete.
4) The user needs to do online renewal of an expired certificate.

It works extremely well when:

1) There is only one certificate.
2) SmartCards are used, particularly when card insertion and removal 
   detection is turned on, and the server invalidates the session id 
   when no certificate is available.
3) There are lots of certificates to choose from, but no role differentiated
   certificates.

PSM's 'ask always' is targetted to the more sophisticated user. It breaks in the following cases:

1) The user has a valid certificate, but the server always does full 
   hand shakes (always invalidates the session id).
2) Switching from no certificate to having a certificate
   (smartCard insertion) if the server does not invalidate the 
   session id (server performance issue).
3) The server does not send a list of CA Certificates, or the list 
   of CA certificates is not complete.

PSM Recommendations:

1) Add a javascript function to clear the current ssl session id which 
   can be called on smartCard insertion. This will elliminate the need 
   for servers to invalidate the session id for firefox clients.
2) Include on all the user's certificates in the 'ask always' list, with
   those that match the CA list at the top and clearly marked as matching,
   and those that do not match at the bottom. (currently we already do 
   this for expired versus unexpired).
3) Work on the server UI for fortitude to allow easy configuration of 
   client authentication, so that client authentication errors are 
   reported back to the client in a friendly manner.

TODO: still need to figure out how best to handle the 'select always' user who needs to do certificate renewal. TODO: do we need to handle the 'select always' user in the case where the list of CA certificates do not match (this inherently requires a sophisticated user?).