New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 16831 link

Starred by 38 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Feb 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Feature
M-5

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Client SSL Certificate Support for Mac

Reported by wtc@chromium.org, Jul 15 2009

Issue description

This bug tracks the remaining work to finish SSL client
authentication for Mac.  It consists of both backend
(implement SSLClientSocketMac::GetSSLCertRequestInfo and
more) and UI (certificate selection dialog) work.

 Issue 318  is the original bug on SSL client authentication
support.

 
Labels: Mstone-MacBeta
Status: Available

Comment 2 by jon@chromium.org, Jul 30 2009

Status: Assigned

Comment 3 by jon@chromium.org, Aug 3 2009

Labels: -Mstone-MacBeta Mstone-4
Wan-Teh recommends that this not block the beta.  I agree.  Moving to milestone 4.

Comment 4 by jon@chromium.org, Sep 2 2009

Labels: -mstone-4 mstone-5
Not a blocker for mstone-4 moving to mstone-5

Comment 5 by wtc@chromium.org, Sep 28 2009

hawk: do you have time in Q4 to work on SSL client authentication
for Mac?

Comment 6 by hawk@chromium.org, Sep 28 2009

It depends on Mac beta timing, but I'll take the bug.
Are you also considering allow loading pkcs11 modules files like firefox does ? That 
would be very useful since there are just a few smart cards/usb tokens supported natively on mac.

Comment 8 by wtc@chromium.org, Dec 9 2009

marcelo: We want to use the "native" interface to smart cards.  How
does one configure Safari to use smart cards/USB tokens?
wtc:  Smartcards are all handled by the Keychain (a tokend for each device type).  Its just using the CDSA 
architecture, so if you have an "Identity" you can use that to perform cryptographic functions.  I think Apple even 
provides some convenience API's for doing HTTPS with client auth, though Ive not used those directly. I have 
used the CDSA stuff to write a PKCS11 driver that uses Keychain as the backend; its a bit complicated at first but 
not too terrible after you get a handle on all the parts.

Comment 10 by Deleted ...@, Dec 14 2009

So glad Chrome's using the native OS keystore. Can't wait for Mac client-auth to work.
wtc: sorry for the late answer ... to use usb tokens/smart cards on mac i use SCA 
(http://www.opensc-project.org/sca/). So, you just have to install SCA and start using 
one of the supported smart cards.
That is the issue here, because there are some cards/tokens that are not supported by 
SCA but they offer some PKCS11 modules to be loaded (e.g. Feitian epass 2000). 
Anyway ... maybe this issue is an mac keychain issues instead of a chrome issue.

Comment 12 by oritm@chromium.org, Dec 17 2009

Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

Labels: Internals-Install
Labels: -Area-Internals -Internals-Install
Fixing a bulk edit. Looks like the search query was not correct.
Labels: ReleaseBlock-Beta

Comment 16 by wtc@chromium.org, Jan 23 2010

Status: Available

Comment 17 by snej@chromium.org, Jan 28 2010

I could take this at some point — I'm fairly experienced with Keychain and CDSA, though 
not the Chrome network stack.
Labels: -Pri-2 -Size-Medium Pri-1 Area-Internals PlatformParity Internals-Network
snej sounds interested, over to him for parity work. P1 for M5.
Status: Assigned

Comment 20 by snej@chromium.org, Feb 6 2010

Status: Started
I have it working, although so far I've only tested it with a toy SSL server running on my 
machine (Apple's SSLSample.) I'm using the system identity-chooser panel as the UI 
(SFChooseIdentityPanel); currently it comes up modally, but I'd like to make it a per-tab 
sheet.

Comment 21 by wtc@chromium.org, Feb 6 2010

snej: good progress!

You can test against https://www.myopenid.com/signin_certificate
It requests SSL client authentication over renegotiation (as
opposed to the initial handshake).  You can get a certificate
from that site.

Comment 22 by snej@chromium.org, Feb 8 2010

The myopenid URL fails to load because SSLClientSocketMac is misinterpreting the 
status code errSSLServerAuthCompletedFlag as an error and aborting the connection. 
Backtrace is:

#0  net::(anonymous namespace)::NetErrorFromOSStatus (status=-9841) at 
/Volumes/Chromium/src/net/socket/ssl_client_socket_mac.cc:194
#1  0x0747f877 in net::SSLClientSocketMac::DoPayloadRead (this=0x2164790) at 
/Volumes/Chromium/src/net/socket/ssl_client_socket_mac.cc:1022
#2  0x074817de in net::SSLClientSocketMac::OnTransportReadComplete 
(this=0x2164790, result=5) at 
/Volumes/Chromium/src/net/socket/ssl_client_socket_mac.cc:839

Comment 23 by snej@chromium.org, Feb 12 2010

I'm still having trouble with servers that renegotiate after the connection opens. I'm 
testing with https://www.startssl.com/ as well as the myopenid URL wtc gave above. 
The problem seems to be a bug/limitation in OS X's SecureTransport implementation. 
I'm discussing it with the experts on Apple's apple-cdsa mailing list.

I'm not sure whether it's worth checking in what I have, even though it doesn't work on 
all sites, or if I should hold back the patch until I can get everything to work.

Comment 24 by wtc@chromium.org, Feb 12 2010

Yes, it's worth checking in what you have so we can perform SSL client
autnentication on initial handshakes.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39389 

------------------------------------------------------------------------
r39389 | snej@chromium.org | 2010-02-18 14:45:05 -0800 (Thu, 18 Feb 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler.cc?r1=39389&r2=39388
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler.h?r1=39389&r2=39388
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler_gtk.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler_mac.mm
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler_win.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=39389&r2=39388
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate.h?r1=39389&r2=39388
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_mac.cc?r1=39389&r2=39388
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_mac.cc?r1=39389&r2=39388
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_mac.h?r1=39389&r2=39388

Client-side SSL cert support for Mac.
This includes sending an existing identity cert, and asking the user which cert to use. Doesn't yet handle SSL renegotiation, or key-gen.
BUG= 16831 
TEST=none

Review URL: http://codereview.chromium.org/604067
------------------------------------------------------------------------

Comment 26 by snej@chromium.org, Feb 18 2010

Status: Fixed
We don't have real tests for this, so this is what you can do so far to verify the fix:
1. Go to startssl.com using Safari or Firefox (_not_ Chrome) and sign up for a free 
certificate. Make sure the resulting cert is installed in the keychain (if it's downloaded 
as a file, double-click it and confirm you want to add it.)
2. In Chrome, go to <https://fips.mtv.corp.google.com/>
3. You should be prompted by a modal dialog, for an identity to use. Choose the one 
you created in step 1.
4. You should see an Apache directory listing page, showing that the server accepted 
the cert.

Comment 27 by wtc@chromium.org, Feb 18 2010

snej: Thanks a lot for implementing this feature quickly!
I opened  issue 36207  for SSL client authentication over renegotiation.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39467 

------------------------------------------------------------------------
r39467 | mark@chromium.org | 2010-02-19 10:59:32 -0800 (Fri, 19 Feb 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_mac.cc?r1=39467&r2=39466

Fix SSLSessionOption's name.  It's not SSLSetSessionOptionType.

Getting the name right is important if this code is to compile with both the
10.5 SDK (where we define the type) and the 10.6 SDK (where the system defines
it).  The error was introduced in r39389.

BUG= 16831 
TEST=10.6 SDK build
Review URL: http://codereview.chromium.org/651044
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39485 

------------------------------------------------------------------------
r39485 | mark@chromium.org | 2010-02-19 12:05:36 -0800 (Fri, 19 Feb 2010) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_mac.cc?r1=39485&r2=39484

Make dynamic access to SSLSetSessionOption static.

It's not often that you can make something both dynamic and static.

BUG= 16831 
TEST=none
Review URL: http://codereview.chromium.org/651055
------------------------------------------------------------------------

Status: Verified
5.0.335.0 (Official Build 39561)

Comment 31 by snej@chromium.org, Feb 23 2010

Known issues/limitations: 
* Does not yet support server renegotiation attempts so it doesn't work with all sites 
( Issue 36207 ). 
* Client cert generation (the <keygen> tag) is not implemented yet ( Issue 34607 ).
* Some valid Netscape-style client certs aren't considered valid ( issue 36316 ).

Comment 32 by Deleted ...@, Feb 25 2010

Here is a site where it doesn't seem to work:

http://www.e-boks.dk/redirect.aspx?logontype=ocesnocd&source=main

I have my client certificate in Keychain, and I get the following error from the site:

"Error 117 (net::ERR_BAD_SSL_CLIENT_AUTH_CERT): Unknown error."

Comment 33 by wtc@chromium.org, Feb 25 2010

christianrishoj: that sites requests SSL client certificate over renegotiation.
Mac Chrome doesn't support that yet.  Please follow  issue 36207 .

Comment 34 by dhw@chromium.org, Mar 3 2010

 Issue 37296  has been merged into this issue.
Now that the keygen element works, it is easy to test the certificate request.
  
 - Choose one of the growing number of  foaf+SSL Identity Providers
           http://esw.w3.org/topic/foaf%2Bssl/IDP
  - Then login to one of the Relying Parties
           http://esw.w3.org/topic/foaf%2Bssl/RelyingParties

  Currently creating a new certificate works in the latest build as the keygen element works, but I am unable to 
log into any of the relying parties. The browser does not seem to ask me for any of my keys - I have a number 
of them that can be used for any site.
I am not sure if this bug is closed, there is a strike through it, but I don't think it can be unless the bug in 
comment 35 is fixed, and the one reported in more detail in  issue 29784 

Comment 37 by snej@chromium.org, Mar 4 2010

Henry: This bug is closed because the client cert code is implemented and works with a test server we have. 
Unfortunately the renegotiation  issue 36207  has blocked me from testing it with real-world sites, as I haven't yet 
found any that don't renegotiate. Of course there may be other bugs in the implementation as well; definitely file 
new reports if you can first rule out 36207 as the cause.
I'll try out some of the sites from the list you gave above. Thanks for the info!
It seems that Chrome dosnt handle dynamic keychains well.  For example, when I plug in my smartcard, a new 
keychain is created with the cert and key in it.  When I remove the card the keychain goes away.  If I start chrome 
with my smartcard plugged in, sites work fine. Removing the card and re-inserting renders chrome unable to find 
my certs.  Also starting chrome up without my card plugged in seems to have the same affect. Is chrome caching 
the list of keychains somewhere?

Comment 39 by snej@chromium.org, Mar 9 2010

Jay: As mentioned several times above, this bug is closed.  Also, you are reporting a different issue. Please file a 
new bug and we'll investigate it. Thanks.
Apologies for re-opening this issue, but I've tried with yesterday's nightly build
and it didn't work. It works on a server that mandates a client certificate, but
doesn't give the opportunity for the browser to send one if it's optional, like
Firefox, IE and Opera do, for example.

(Unfortunately, I commented about this in another issue, sorry)

http://code.google.com/p/chromium/issues/detail?id=36207#c14

Comment 41 by snej@chromium.org, Mar 9 2010

PLEASE DO NOT POST MORE COMMENTS TO THIS ISSUE. IT IS CLOSED. FILE A NEW BUG REPORT INSTEAD.

Sorry to shout, but people keep doing it.
This issue covered the initial implementation of client cert support for Mac. It is understood that the first iteration 
will not be perfect, and bugs will need to be fixed. Those should be filed as new reports. If every issue dealing 
with Mac client-cert support gets glommed into this one bug report, it becomes a terrible mess to track. Thanks.
I opened  issue 37765  for Bruno's point 40.

Comment 43 by snej@chromium.org, Mar 9 2010

Labels: Restrict-AddIssueComment-Commit
Project Member

Comment 44 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -mstone-5 -Internals-Network M-5 Cr-Internals Cr-Internals-Network
Project Member

Comment 45 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment