Apologies in advance for a) long post &/or b) if this is the wrong list for this. We have enabled PKI authentication on a system we developed and our Safari users (especially CAC) are experiencing odd behavior. We are not sure if it is a server, client or card side issue. A) If we set SSLClientVerify to optional in http.conf (creates problems for Safari) In this mode, browsers should prompt a user to present a certificate, if one exists in the browser's realm of places to look for certificates. On the Mac, Safari and Chrome use the Keychain. If the user a) doesn't have a certificate, or b) cancels the browser's request to choose a certificate, and no certificate is provided, the server will continue to serve resources as it normally would. Browsers will generally not ask the user about a cert again for the entire browser session. However, in all browsers other than Safari on the Mac, whenever the server-side SSL session expires, the browser re-presents the certificate that the user provided to the server initially. On Mac Safari, the client will prompt the user to select a certificate each time the SSL session expires even though it should theoretically pass through the already-presented cert. This behavior is seen only under 2 conditions: 1) SSLClientVerify is optional, and, 2) Safari knows about multiple client certificates (for example a CAC, which always contains an identity and email cert). In addittion, even if there is Mac Keychain "Identity Preference," Safari seems to ignore any identity preference that is set, or any knowledge of a cert it already sent in this situation. If the CAC isn't present, Safari will pass the com.apple.idms.appleid.prd.[UUID} cert which will fail as an invalid user id. As a note: Mozilla appears to have struggled with this issue (which seems to have been a conscious design decision) for a long time: https://bugzilla.mozilla.org/show_bug.cgi?id=149673 B) SSLClientVerify require (creates problems for IE 8/9) In this mode, browsers will prompt a user to present a certificate. If there is no cert available to the browser, or the user cancels the request for a certificate, the server will return a 403 (Forbidden) error. Typically, this is configured not for an entire "VirtualHost", but rather only for a given "Location" stanza in Apache's config. However, whenever Apache encounters a change in the SSLClientVerify (i.e., it goes from "none" to "require"), it attempts to do an SSL renegotiation, since it has previously negotiated the SSL connection with one set of parameters and now needs to re-negotiate with a different set of parameters. When we attempt to use this functionality on our "Location" (a URL we access with POST requests) that deals with certificate processing, all browsers prompt for client certificate immediately. Most browsers successfully do the re-negotation (albeit with varying levels of server-side attempts before finally succeeding) within a second. IE 8 and IE 9, however, attempt to do the re-negotation and is never successful, eventually timing out when it reaches the global timeout value set in Apache. If the user immediately re-attempts the connection, it goes thru. In this configuration, Safari users behave like others. Thanks. Peter Walsh Jackpine Technologies, Inc. peter.walsh@jackpinetech.com c. 617/816-6001