The following (older) reports may be related to this one:
http://code.google.com/p/chromium/issues/detail?id=148
http://code.google.com/p/chromium/issues/detail?id=166

http://code.google.com/p/chromium/issues/detail?id=148 does not in full relate to the
issue reported. This issue 148 refers to the sending of a CSR

http://code.google.com/p/chromium/issues/detail?id=166 does not in full relate to the
issue reported. In this  issue 166  case a web application requests a certificate and
not the server itsself, which demands it (so not even optional)

I issued ticket #148, so I can definitely say there is some overlap.  If Chrome 
doesn't support certificates at all, it certainly can't send a valid CSR.  (Though 
being able to send a CSR properly doesn't guarantee support of client certificates.)

I am also seeing this error.  We have an internal usage website that authenticates 
using client certificates that are generated from our own internal CA. I can visit 
this site in IE, Opera, and Firefox using the client certificate.  I also looked in 
chrome's options and see the certificate there (it appears to be using the standard 
windows store that IE uses as it was already listed).  When I go to visit the site, I  
immediately get the error.  The apache server log contains this message:

[Wed Sep  3 10:06:34 2008] [error] mod_ssl: SSL handshake failed (server 
xxx.yyy.zzz.edu:443, client 10.7.16.151) (OpenSSL library error follows)
[Wed Sep  3 10:06:34 2008] [error] OpenSSL: error:140890C7:SSL routines:SSL3_GET
_CLIENT_CERTIFICATE:peer did not return a certificate [Hint: No CAs known to ser
ver for verification?]

Oh, I left off the specific error in Chrome:

Error 2 (net::ERR_FAILED): Unknown error.

CACert might be a good publicly accessible site to check this.  It's currently not 
working, giving the "Unknown error" described by rickerm.  It seems there's no 
difference in the error message whether I have my client cert installed or not.  
Inspecting the imported client cert curiously shows "Client Authentication" among the 
"intended purposes", but in the advanced tab, "Client Authentication" is unticked.  
Ticking it seems to have no effect, however.

The client-cert login:

https://secure.cacert.org/index.php?id=4

I have same issue as comments #4 and #6.  This is the *ONLY* reason Chrome is not my 
default browser. I use a self-signed CA and issue client certificates to certain 
users , and have certain web sites that SSLRequire a particular SSL_CLIENT_S_DN_O. 
Chrome behaves as if I don't have the client certificate installed. As per comment 6, 
ticking the "Client Authentication" flag on the client cert makes no difference.

If I code "SSLVerifyClient optional" in my apache config Chrome falls back to basic 
authentication but if I code "SSLVerifyClient require" Chrome presents me with Error 
104 (net::ERR_CONNECTION_FAILED): The attempt to connect to the server failed.

Chromium doesn't support SSL client authentication right now.  When we
support it, we will use the OS-specific client certificate store.

Before we support SSL client authentication, this is the best we can
do (subject to the limitations of the WinHTTP library):
- Windows XP: fail with error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED).
- Windows Vista: support sites that request but don't require client
  certificates; for sites that require client certificates, fail with
  error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED).

Two of you reported seeing Error 2 (net::ERR_FAILED) or Error 104
(net::ERR_CONNECTION_FAILED).  That's bad.  I tried the URL
https://secure.cacert.org/index.php?id=4 mentioned in comment 6,
and I got the expected Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED).

Thanks for the update.  What is a bit confusing right now is if you have personal 
certificates installed in the Windows cert store, they show up (you must be using 
some common dialog box widgets or something?)  The presence of such things is a bit 
misleading for some of us.  Keep up the good work, and I look forward to client auth 
getting implemented in the future! 

I am also getting Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED): 

I am trying to access http://service.sap.com and I get the error as below:

This webpage is not available.

The webpage at https://websmp208.sap-ag.de/~SAPIDP/002006825000000234912001E might be 
temporarily down or it may have moved permanently to a new web address.

This was extremely confusing. Especially given there is the whole "certificates" 
option in the Chrome options.

Why not simply show a message "Chrome does not support SSL"?

The login page of my Bank (for online account infos) also doesn't load at all, Chrome 
shows only the following:
This webpage is not available.
The webpage at https://ebank.<bankname>.<TLD>/<ebank_path> might be temporarily down 
or it may have moved permanently to a new web address.
  More information on this error
Below is the original error message
Error 2 (net::ERR_FAILED): Unknown error.

The page loads with no problem in Firefox, IE.
(Contact me for exact URL (for testing).)

Same Error 2 here on the page mentioned by #6, i.e., https://secure.cacert.org/index.php?id=4

I think it's important to implement a solution to this error (in the sense of 
Chrome's spread/usage).

I do also see this error, and it's pretty annoying since there's the certificate 
stuff available (which is the same as IE), but it doesn't work.

Safari also doesn't have the option to install/use a client SSL certificate (as of 
version 3.0.3).

Please check the screen shot and find the solution immediately.

	Error.docx
	56.6 KB Download

I don't know what the plans are for full client cert support are. I presume that will 
follow releasing the new http stack, but won't be in the initial release.

For those attempting to duplicate this issue, you have to create or already have a
specific client certificate. Any Web site that requires client certificates on a
user's machine will not connect because Chrome is either not recognizing personal
certificates installed on a user's machine personal store or is not sending the
certificate to the Web server when the connection is made.

The error returned is a connection refused, SSL Client Certificate Required. The
error happens even if a user has a client certificate already on the machine.

Chrome also does not have an option to import a client certificate into the browser
to be used for client certificate connections.

 Issue 5274  has been merged into this issue.

(No comment was entered for this change.)

 Issue 5050  has been merged into this issue.

Can we know when we can expect the fix for SSL Certificate?

Thanks,
Miral.

Just to give my feedback, having this support for me is the most important thing that 
is keeping me from uninstalling firefox. My school's website does gives this ERR_SSL_CLIENT_AUTH_CERT_NEEDED error, and my school website is the most important 
website for me (to get homework and grades etc). Hopefully this can get fixed soon. 
Like Miral, I would love to know if there's an expected date for fixing this.

Thanks

I am getting the following error while accessing the following website:
https://service.sap.com/notes

This website redirects the url to reverse proxy servers of sap that have addresses 
like these : 

https://websmp105.sap-ag.de/notes

I am using certificates to login to the website, ideally it browser should prompt me 
and let me choose between the certificates installed in browser for the 
aforementioned website.

Instead I am getting this error:
Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED): Unknown error.

I checked the certificates with manage certificates button under the Security option 
("Under the Hood" tab). I can view all the certificates.

Would like to know how long will it take to fix it. 

Thanks

I had the similar issue when I try to enter https://service.sap.com .
It gives Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED): Unknown error.

I'm unable to access any of my company's internal web sites with Chrome browser.  The 
error "The webpage at https://w3-bugs/show_bug.cgi?id=178347 might be temporarily down 
or it may have moved permanently to a new web address." is completely bogus.  

Please fix the error message if you can't fix the root cause.

The worst thing is I am not getting any estimated time for resolution. I was atleast 
expecting some date/month when this issue will be resolved.

I am getting the same issues. Please help asap.

 Issue 7892  has been merged into this issue.

 Issue 5144  has been merged into this issue.

 Issue 8114  has been merged into this issue.

It's been 6 months but no solution for this issue. I would appreciate if you can 
provide estimate time.

I stopped using chrome to open SAP sites bos of this issue.

Yes. Our shop of 20 odd users cannot use Chrome because of this also. On Windows 
7 beta, I float between FF 3 (Great spell checker with Aussie dictionary) and IE 
8 (Great for everything except spell checker).  I cannot use Chrome because it 
does not support Client side SSL certificate authentication.

Well that's disappointing.... 

(No comment was entered for this change.)

 Issue 9407  has been merged into this issue.

 Issue 9556  has been merged into this issue.

 Issue 600  has been merged into this issue.

 Issue 4041  has been merged into this issue.

Moving from milestone 2 to milestone 2.1

I've been a fanatic Chrome user ever since it was launched, and would love to use it 
as my default browser. However, since I'm an SAP consultant, this is impossible as 
long as the certificate issue isn't solved, because I can't use the common SAP sites 
(mainly http://service.sap.com). As so many other users I have one question: *WHEN* 
will this issue be solved?!?

Have been using Chrome for almost a year now, but still has to revert to IE or Firefox 
to login into all of MIT sites which require a special client certificate.

(No comment was entered for this change.)

(No comment was entered for this change.)

Hi,

Wondering if there is an expected resolution  date for this? Just found the same
error on Chrome browsing to a website which requires Client Certificate
Authentication... 

i.e. Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED)

Wasn't expecting this, as it looks to use MS CAPI Certificate stores under the covers... 

Thanks & keep up the good work!
Diarmuid

I will be working on this issue in May and June.  I
plan to start next week or the week after.

Same issue; IE/FF works fine. Is there a resolution to this yet? 

The webpage at https://www.sdn.sap.com/ might be temporarily down or it may have 
moved permanently to a new web address.

  More information on this error
Below is the original error message

Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED): Unknown error.

both SDN & SMP sites work fine on Chrome Beta 2.0.172.8

I jumped on the Beta-train and Roshan is right: the sites *are* working in the version 
mentioned.
However, I'm still not able to install a Single Sign-On certificate for the SMP. It 
seems Chrome isn't recognizing the certificate that's already installed (via IE), but 
also doesn't handle the installation of a new SSO install request properly. It keeps 
stating that the wrong password is entered when you apply for an SSO certificate on SMP 
:-(

I'm on 2.0.172.8 and sites that require client ssl certs are not working. What do you 
mean by SDN & SMP sites?

Hi Robert,

we're talking about the sites http://service.sap.com (referred to as SMP (the "SAP 
Service Marketplace")) and https://www.sdn.sap.com/irj/sdn (referred to as SDN ("SAP 
Developer Network")). Both sites use the same Single Sign-On certificate and 
experience(d) the same issue.


Henk.

Seems like I have to use other browser for SAP Portal.

Error 110 (net::ERR_SSL_CLIENT_AUTH_CERT_NEEDED): Unknown error.

I tried Option > Manage Certificate > Advance > and then tick both Server & Client 
boxes .. still not working.

HTTPS is working ( tested with https://mail.google.com )

And another HTTPS authentication ( dunno how ) for MSDN ( Microsoft dotnet Passport ) 
Login was working ( via https )

(No comment was entered for this change.)

(No comment was entered for this change.)

Why moved for mstone3? You are losing many corporate clients!

This is major issue in our country. We use client certificates for government (taxes,
registrations, ...), online banking, colleges, stock market investments, ... And that
use ordinal people not just corporate users. In Slovenia we have government official
CAs, that are issuing certificates for free to each person, so there is basically a
requirement when doing anything officially online.

I suggest promoting this issue to a bug (not feature) due to not completely
supporting SSL standard.

There are users that are contacting us regarding Chrome support, and we would like to
at least give them some kind of more official date regarding this bug in Chrome.

The mstone-2.1 to mstone-3 change is just a renaming of the
same milestone.  Sorry about the confusion.

My work on this issue was delayed by other work.  I just started
working on this issue on Thursday.

Note: certificate enrollment will not be supported at first.
I will open a separate issue for certificate enrollment.  Until
we implement certificate enrollment, you will need to use IE to
get a certificate from a CA.

I would love to make Chrome my default browser but just can't because my company is 
using client certificates quite extensively.

@ matej.spiller : don't think your country is the only one. I belive it's the same 
for any country if it comes up to online banking, stock market, taxes etc. etc.

On the other hand you are totally right, this should not have a "feature" tag but it 
should be clearly a BUG. Especially, as you can already access the certs via the 
Options settings. Client SSL certificates have become extremely important. It's part 
of the WWW day to day business. Also for the very same reason, I cannot use Chrome 
internally (we are one of the major IT companies in the world) because a lot of the 
intranet is secured via client certs.

Many thanks to get this working as soon as possible. Beside that: Chrome rocks !

Because of my other work, I only got to work on
this for one day this week.  I wrote the absolute
minimum code to get SSL client auth working in
the basic case, without SSL renegotiation.

http://codereview.chromium.org/118039

This is just a quick-and-dirty prototype.  It's
still a long way from production code done properly.

Jay, the interface between the network stack and
UI is the two new methods in url_request.h.  The
SSLCertRequestInfo object will contain a list of
CAs (the issuer list).  You need to write code to
present the client certs issued by those CAs for
the user to select one, and call ContinueWithCertificate
with the selected client cert.  The UI code you
need is in ssl_client_socket_win.cc, the method
SSLClientSocketWin::HandleClientAuthRequest()
in Patch Set 1.

Please keep in mind that not all servers present a list of acceptable CA's and yet still require a client certificate. I 
consider these servers buggy myself, but in these instances all available certs with private keys and the right key 
usage extensions should be presented to the user.

(No comment was entered for this change.)

Labels: Mstone-1.2 NewHTTP
Labels: Mstone-2.0
Labels: JonMoved Mstone-2.1
Labels: -mstone-2.1 mstone-3
Labels: -mstone-3 Mstone-4

& so on & so on?

Since Chrome currently appears to be making use of the Windows certificate store,
will it keep making use of it after this issue is fixed, or will Google Chrome have
its own proprietary certificate store?

slushpupie: thanks for the reminder on handling an empty list of acceptable
CAs properly.  I checked the TLS 1.0 RFC, and it doesn't say what an empty
certificate_authorities list means.  I then checked the Firefox source code,
and it indeed does what you suggested -- an empty list of acceptable CAs
means all suitable certs, issued by any CA, should be presented to the user:

http://bonsai.mozilla.org/cvsblame.cgi?
file=mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp&rev=1.165&mark=2603,2610-
2614,2619,2623-2625#2602

mich...@specialisterren.nl: Chromium will continue to use the Windows
certificate store.

wtc:  It looks like on the Mac side since you are using the Security.framework stuff, it would be about as much 
work getting client certs working there as on Windows (thats not to say its horribly easy, but at least not too 
hard).  Are you able to work on the Mac piece too? 

slushpupie: I or a Mac Chromium developer will work on the Mac piece,
after getting client certs working on Windows.  Some of the code I'm
writing for Windows will be used by all platforms.

I should open three bugs (one each for Linux, Mac, and Windows) to make
this obvious.

Please, please hurry up with this issue! It is top priority for many users!

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

------------------------------------------------------------------------
r18322 | wtc@chromium.org | 2009-06-12 14:45:11 -0700 (Fri, 12 Jun 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/socket_test_util.cc?r1=18322&r2=18321
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_cert_request_info.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_mac.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_mac.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_nss.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_nss.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_config_service.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_response_info.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_response_info.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_transaction.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_transaction_unittest.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request_http_job.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request_http_job.h?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request_job.cc?r1=18322&r2=18321
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request_job.h?r1=18322&r2=18321

Specify new methods for supporting SSL client authentication.
See the changes to url_request.h and ssl_cert_request_info.h.

They are similar to the methods for handling SSL certificate
errors and HTTP authentication.

The handling of servers that request but don't require SSL
client authentication is reimplemented using the new methods.

R=rvargas,eroman
BUG=http://crbug.com/318
TEST=none
Review URL: http://codereview.chromium.org/118039
------------------------------------------------------------------------

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

------------------------------------------------------------------------
r18735 | wtc@chromium.org | 2009-06-18 12:38:58 -0700 (Thu, 18 Jun 2009) | 9 lines
Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_auth_cache.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_auth_cache.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_auth_cache_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/ftp/ftp_auth_cache.h?r1=18735&r2=18734
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_session.h?r1=18735&r2=18734
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=18735&r2=18734

Add a simple cache of certificates for SSL client authentication.
It is based on FtpAuthCache and will be used in similar ways.  The
the only difference is that the authentication data is a certificate
rather than username and password.

R=eroman
BUG=http://crbug.com/318
TEST=new unit tests.
Review URL: http://codereview.chromium.org/132004
------------------------------------------------------------------------

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

------------------------------------------------------------------------
r18819 | wtc@chromium.org | 2009-06-19 10:00:02 -0700 (Fri, 19 Jun 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc?r1=18819&r2=18818
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.h?r1=18819&r2=18818
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=18819&r2=18818
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=18819&r2=18818

Add a temporary command-line switch --auto-ssl-client-auth for
automatically selecting a client certificate when an SSL server
requests client authentication.

This switch will be removed when we implement client certificate
selection UI.

Also fix some cpplint.py nits.

R=jcampan
BUG=http://crbug.com/318
TEST=none
Review URL: http://codereview.chromium.org/131090
------------------------------------------------------------------------

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

------------------------------------------------------------------------
r18841 | wtc@chromium.org | 2009-06-19 12:57:01 -0700 (Fri, 19 Jun 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_cert_request_info.h?r1=18841&r2=18840
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.cc?r1=18841&r2=18840
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=18841&r2=18840
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.h?r1=18841&r2=18840

Implement the backend of SSL client authentication for
Windows.

Create Schannel SSPI CredHandles with certificates for
SSL client authentication.

Remember the client certificates that the user selected
so that we don't ask the user again and again.

R=rvargas,eroman
BUG=http://crbug.com/318
TEST=none
Review URL: http://codereview.chromium.org/131086
------------------------------------------------------------------------

wtc@chroium.org wrote:
"Remember the client certificates that the user selected so that we don't ask the
user again and again."

Please make this feature optional. Some people have multiple certificates in their
certificate store and may need 1 certificate for 1 website, and another certificate
for yet another website.

It does exactly what you want.  Here is a precise description: when
the user selects a client certificate for a website, Chromium remembers
that decision and will select that certificate automatically when the
user returns to that particular website in the same browsing session.

wtc, 
 
Is/will there be a way to select a different cert within the same session? As an example, my smartcard has 3 certs 
on it.  If I accidentally select the wrong one the first time, and am not given proper access, it would be nice to 
switch to the correct one.  Also when doing development I like to test my site as a different "pretend" user with a 
softcert. 

You can now download a build and test the new SSL client authentication code.
There is no UI yet, and you need to specify a command-line option to enable
this feature.  The instructions are in the "Status" section in:
http://dev.chromium.org/developers/design-documents/ssl-client-authentication

slushpupie: If the server rejects the client cert you selected, Chromium will
forget that cert and ask you to select a cert again next time.  So you can
switch from an incorrect cert to the correct one.

However, you won't be able to switch between two correct certs without restarting
Chromium.  An easy workaround is to run a seperate instance of Chromium using
the --user-data-dir command-line option.

@wtc@chromium.
So say I have 1 certificate for authentication purposes, and 1 certificate for
signing purposes (which is a common practice in governmental PKI's). 
I need to authenticate with 1 certificate to get into a protected site, and then need
to verify something by signing online using my second certificate, the website would
state that my currently used certificate cannot be used, so will Chrome then offer
the option to select another certificate for this purpose within the same browser
session?
Otherwise in this case opening another sessions of Chrome would not work.

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

------------------------------------------------------------------------
r18879 | wtc@chromium.org | 2009-06-19 17:03:29 -0700 (Fri, 19 Jun 2009) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.cc?r1=18879&r2=18878

Don't put CredHandleClass in std::map directly because
std::map may copy an entry to a new address while resizing,
which invokes the destructor on the old entry and invalidates
its address.

R=eroman
BUG=http://crbug.com/318
TEST=none
Review URL: http://codereview.chromium.org/141011
------------------------------------------------------------------------

When you "sign online" using your signing/non-repudiation certificate,
you're not doing SSL client authentication.  Perhaps I misunderstood
what you meant by signing online.

If the website rejects a certificate, Chromium will ask the user to
select a certificate when you go back to that website.

Finnaly! I tested the function in Chromium and it works great. Now only the UI remains 
to be implemented! In wich dev build is this funcion going to be included?

miran.merljak: thanks a lot for testing --auto-ssl-client-auth.  This command-line
option will be in the Dev channel release next week (the week of 2009-06-26).  We
have weekly Dev channel releases.  Any code checked in before Monday morning will be
included in the Dev channel release that week.

Thanks a lot ! It works fine, still can't choose if I had various valid certificates 
but It authenticate without problem. Finally I can use Chrome as my default browser.

(No comment was entered for this change.)

jcampan: I emailed you the sample code for using
CryptUIDlgSelectCertificateFromStore.  There is another function
named CryptUIDlgSelectCertificate.  I don't think
CryptUIDlgSelectCertificate offers any advantage over
CryptUIDlgSelectCertificateFromStore.  If you want to try
CryptUIDlgSelectCertificate, you'll need the code in the
attached file because that function and the associated
CRYPTUI_SELECTCERTIFICATE_STRUCT structure aren't declared
in any header file for some reason.

For completeness, I just found the CertSelectCertificate
function.  But it seems inconvenient to use (need to call
LoadLibrary and GetProcAddress).

	select_certificate.cc
	2.3 KB Download

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

------------------------------------------------------------------------
r19029 | wtc@chromium.org | 2009-06-23 10:06:42 -0700 (Tue, 23 Jun 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate.h?r1=19029&r2=19028
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=19029&r2=19028

Define the == operator for X509Certificate::Fingerprint.

R=eroman
BUG=http://crbug.com/318
TEST=none
Review URL: http://codereview.chromium.org/140034
------------------------------------------------------------------------

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

------------------------------------------------------------------------
r19056 | wtc@chromium.org | 2009-06-23 14:03:42 -0700 (Tue, 23 Jun 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate.h?r1=19056&r2=19055
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=19056&r2=19055

Following the style guide, replace the overloaded operator==
with the Equals method.

R=eroman
BUG=http://crbug.com/318
TEST=none
Review URL: http://codereview.chromium.org/146040
------------------------------------------------------------------------

The --auto-ssl-client-auth command-line option is in the 3.0.190.1 Dev
channel update for Windows.

I tried it in the 3.0.190.1 dev release but it doesn't seem to work. Too bad, I was 
really hoping for this release to enable the SSL functionality!

miran.merljak: I just tried the 3.0.190.1 dev release with this command line:

  chrome.exe --auto-ssl-client-auth

It works for me.  Did you add the --auto-ssl-client-auth command-line option?

Typing "about:version" in the location bar shows this version:

  Google Chrome	3.0.190.1 (Official Build 19007)

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

------------------------------------------------------------------------
r19456 | jcampan@chromium.org | 2009-06-26 22:11:41 -0700 (Fri, 26 Jun 2009) | 2 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/generated_resources.grd?r1=19456&r2=19455
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc?r1=19456&r2=19455
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.h?r1=19456&r2=19455
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ssl/ssl_client_auth_handler.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome.gyp?r1=19456&r2=19455
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=19456&r2=19455
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=19456&r2=19455

A first implementation of the SSL client auth UI.This uses the Windows API that prompts the user for a cert.R=wtcBUG=http://crbug.com/318TEST=Visit a site that requires client auth. A dialog to select a certificate should be shown. Try selecting no cert. Try again this time select a cert.
Review URL: http://codereview.chromium.org/147233
------------------------------------------------------------------------

First version of the client auth UI implemented.

It work's!!. I tried with SAP Marketplace site. Select no cert, no access. Close tab
and open new one, this time, select one certificate and log on without problem. Close
the tab open another, pick up a different certificate and It works perfect!!. I'm not
a power tester but this works fine for me.
Thanks a lot an keep the good work!

Great job!

When can we expect a release?

Next Dev Release will be with this GUI...

Yay, finally client certs on Chrome!

I can now uninstall FF. ;)

I'm using the "dev channel" release:

Google Chrome	3.0.193.0 (Official Build 20299)
WebKit	531.3
V8	1.2.13.2
User Agent	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/531.3 
(KHTML, like Gecko) Chrome/3.0.193.0 Safari/531.3

And it's working for me without using a command-line argument.

193.0 is that Dev Release (see 2 post upper)

Although not mentioned in the release notes, 3.0.191.3 is the first
Dev channel release that has jcampan's SSL client auth UI:
http://dev.chromium.org/getting-involved/dev-channel/release-notes/releasenotes301913

The remaining work is tracked in the following three bugs:
- issue 16830: Linux implementation.
- issue 16831: Mac implementation.
- issue 148: certificate enrollment.

I am on the Beta channel and just got version 3.0.193.2 I am now able to successfully 
use client side certificate authentication for the University of Virginia "Netbadge" 
system. WOOT! unstarring :)

Same or similar issue for me.  Connecting to an Apache 2.0 site that has

SSLVerifyClient optional
SSLVerifyDepth  10

gave Error 2 (net::ERR_FAILED)

After reading this issue, I changed it to

SSLVerifyClient none
SSLVerifyDepth  10

and now it works.

Same issue?

Problem was occurring for me on 2.0.latest and 3.0.195.6 from the beta channel.

mi...@mikelward.com: thanks for the bug report.  Could you
please open a new bug report for your problem with the
Apache 2.0 site?  Note: 2.0.latest doesn't support SSL
client authentication, so please test only a Beta channel
or Dev channel release.

Wow, I starred this issue ages ago (when unable to connect to my bank service) - now I 
got a "heads up" that it's dev-released. Haven't been able to try it yet but thanks for 
an impressive effort, keep it up!

Still can't open any SAP-note with Chrome 4.0.203.2

error 107 (net::ERR_SSL_PROTOCOL_ERROR)

 Issue 20499  has been merged into this issue.

http://web.skandia.se/hem/bankredirect.aspx?page=login still does not find my client 
certificate. If a valid client cert. is found I get redirected to:
https://secure.skandiabanken.se/Skbsecure/LoginInternet/SKBLoginInternet.aspx (works 
in Firefox and IE)
This doesn't happen in either 3.0195.6 or 4.0.203.2 instead I'm redirected to a 
page[1] that asks me to download a cert (which also fails but that is probably 
another problem).

[1]https://secure.skandiabanken.se/cert/gibcert/Login.aspx

I use http://pip.verisignlabs.com as openID provider, and the issue is also 
reproducible there (I've generated both Firefox's PKCS#11 certificate and regular IE 
certificate, both are working). Something I like about Firefox over IE is that it will 
ask you the first time about which certificate you want to use (in case you have many, 
or in case you don't want to authenticate for some reason): IE will just use the 
certificate you've generated for that site, without asking you (at least this is the 
default behavior).

marcelo.dacruz: if I create an account at https://pip.verisignlabs.com/,
will I be able to reproduce the problem?  If you could provide specific
steps to reproduce the problem, I'd appreciate it.

jonelf: I guess it'd be hard for me to get an account at Skandia bank.
Hopefully the underlying problem is the same as the problem with
https://pip.verisignlabs.com/.

anton.dyakov: Is there a public accessible URL for SAP-note?  Can I
(as an individual) get an account for SAP-note?

wtc: There is a catch --> I'm not sure whether PIP is identifying the browsers and disabling the functionality if you don't have one of the supported browsers. The 
problem is that once you generate a certificate for one of your browsers (let say, Firefox), you won't be able to login to your account with Chrome (or at least, you'll 
have to go fetch a one-time-password sent to your e-mail, which is not really user-friendly)

Follow the next steps to create an account and generate the certificate(s):
1) Go to the link and create an account
2) Once in your home page (usually after login), select "My Account"
3) Scroll down and you'll see three options for providing strong authentication
   a. VIP credential (it's actually a OTP token, or softid)
   b. Browser certificate (--> this is what you want to get <--)
   c. Information card (I guess this is for using with "Windows Cardspace")
4) Select the "Browser Certificate" option
   --> This will start the certificate request and finally install the certificate in your computer
   --> If you are using Firefox, it will use the browser's internal PKCS #11 keystore
   --> If you are using IE, it will use Window's keystore (you can see the certificates if you create a management console and attach the certificate snap-in)
   --> If you are using Chrome, it fails to generate the certificate

Keep in mind that once you generate a browser certificate, let's say for Firefox, the PIP portal won't let you login with a different browser (since those two browsers 
do not share the same keystore): In order to enroll new browsers PIP will send you a one-time-password to the e-mail you used to register the account, then you can login 
with the new browser and "enroll" it --> so now you can login using certificates from those two browsers.

[updated] PIP won't even let me generate a certificate for Chrome, since it's not listed in their "browsers that support certificates" list (so the functionality is 
disabled for Chrome... you might want to try to fake the "User-Agent" header to make Chrome look like Firefox/IE and avoid this check). I've tried generating an IE's 
certificate, hoping that Chrome would use the Windows' keystore to retrieve it later, but that doesn't work either.

btw, is there an easy way to change the User-Agent header in Chrome --> I can probably help you guys testing this stuff.

1. Right click on one of the Chrome Shortcuts and select Copy.
2. Right click on desktop and select Paste.
3. Right click on the newly created shortcut and select Properties.
4. In the properties window, select Shortcut tab.
5. In the target field, add a space and the following string:
--user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) 
Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)"
6. Click on ok and *close all instances of Chrome*.
7. Launch Chrome from the newly created Shortcut.

Just saw the post too late and modified the Chrome.dll binary to replace the User-
agent with an hex editor... but is good to know there is an easier path :)

Good news: After changing the User-agent, I can login to PIP (Chrome will successfully grab the certificate from Window's keystore) --> Now, since this 
certificate was the one I generated thru IE, I haven't yet tested the actual 
generation of the certificate using Chrome --> I'll try this out and post the results 
later

Summing up:
1. Chrome grabbing the certificate from Window's keystore: Working
2. Chrome generating a cert request: Status unknown

Ok, so I can confirm certificate generation is not working in Chrome (with fake User-agent), using 
Verisign's PIP (when changing User-agent to match Firefox's)

Steps to reproduce:
1) Follow steps 1-2 is comment 117 to create the account in Verisign's PIP
2) Make sure you don't have a PIP/Verisign certificate associated with your browser: unbind the certificates that show up in PIP (just click on "delete" on the certificate management section), and 
delete the certificate from you keystore (use a Windows management console, and attach the certificate 
snap-in)
3) Start Chrome as explained by progame in comment 118
4) Follow step 3-4 in comment 117 to generate the certificate with Chrome
   --> Remember that PIP won't let you login if you have certificate-based authentication enabled and the 
browser you are using is not binded to a cert: you'll have to let PIP send an OTP to your e-mail account 
and use that for a temporary login

Current behavior:
--> PIP will try to issue the cert requests, but will fail (no cert generation request pops up in the 
browser as it should).

Summing up:
1. Chrome grabbing the certificate from Window's keystore: Working
   --> Includes certificates that have been generated by IE
2. Chrome generating a cert request, sending it to the web application, and installing the resulting 
certificate: Not working

btw, to verify you are indeed using the correct user agent string, you can view 
about:version (for example, what i posted in comment 18 was cut in to 2 lines...)

Thanks progame, I'm using the whole two lines from your comment

marcelo.dacruz: thank you for your test report.  So we need to
talk to VeriSign to add Chrome to their list of supported
browsers for Personal Identity Portal (PIP).  It may make sense
to wait until we have implemented certificate enrollment (issue
148) to talk to VeriSign.

The current status of SSL client authentication and certificate
enrollment is published at
http://dev.chromium.org/developers/design-documents/ssl-client-authentication