Client certificate without a private key

Our ASP.NET webapi application is hosted on IIS 8 and requires SSL as well as client certificates.  As expected it is protected with a server certificate and any incoming requests must carry a valid client certificate.

Our IT manager created a root CA for the company, which then issued the server and client certificates.  Everything works as expected and access is allowed if the request contains a client certificate with the private key, but not if it contains a certificate without the private key (403 Forbidden is returned).

As far as my understanding, that is as it should be, since part of the SSL handshake appears to be for the server to encrypt a token with its public key and see if the client certificate can decrypt it with its private key.

Out IT Manager says the private-key client certificate should only be necessary for browser-based access, but not direct webapi access.  He is rightly cautious in not giving out the private key unless necessary, but it appears we must give the private-key certificate to our client who will access the api.

Given all this, is there a way to configure IIS (and/or a webapi application hosted on it) to work with client certificates that do NOT include a private key?  Or am I correct in thinking that we need to give our client a certificate that includes the private key?  Perhaps it's not a question of IIS configuration but one of configuring the server and client certificate when generating them to fore go private key usage?
StudentNumber9Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Shalom CarmelCTOCommented:
tl;dr : You are right and your manager is not.

A certificate is basically the public key of the client signed by an authority that confirms the client's identity and validity. Where there is a public key there must also be a private key. So if you issue a client certificate and send it to the client, you must also send the private key to complement it.

You could have several private keys, like one for each client. This is actually considered good practice.
So you should not give out THE private key, but A private key.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gheistCommented:
Private key is absolute must for SASL client authenticaton. You (i.e your boss in the role of CA) must sign public keys of all users accessing that server. That adds as a bonus Outlook encrypted/signed mail.
And it is not directly encrypted using client/server keys. A random session key is generated on the fly (Read on wikipedia about PFS)
0
Dave HoweSoftware and Hardware EngineerCommented:
More agreement here. you should specify which client certificates are acceptable (and this should be those signed by your own private CA) and you should issue individual certificates *with unique keys* to each client user; the private key is ideally held by the customer themselves (and a signing request issued) but few users know how to do that, so it is more common to send them a pfx.
0
ON-DEMAND: 10 Easy Ways to Lose a Password

Learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees in this on-demand webinar. We cover the importance of multi-factor authentication and how these solutions can better protect your business!

BembiCEOCommented:
I guess the concert of your Administrator is, how your client can access / use the cert with the private key...
Inside MS PKI, you can define inside the cert template, if the private key is exportable or even not.
So if your client can request the cert from the PKI, he can get "a" private key for the machine / user, but can not export the containing private key....

This avoids, that a user exports the cert from one machine, and puts it onto another machine.

A common way is, that the computer is prepared by the system administration, they put a certificate onto the machine with an non exportable private key and then the computer is given out to the client.
Another option is to work with certificate cards. No the only possible solution, but a common used procedure.
0
David Johnson, CD, MVPOwnerCommented:
in order for a certificate to be of any use you need the public and private key. Certificates are used for both authentication and encryption.

You do not give out the servers public or private key (it will be sent as part of the handshake) but after you follow your policy you issue each client its own public and private key.

Sender uses  your public key and their private key
Receiver uses their private key and your public key

A public key without a private key is useless. Many companies publish their users public keys in a publicly available area, same with CRLs and AIA's
0
StudentNumber9Author Commented:
Thank you all for your advice and notes, I am waiting for the actual resolution of the problem between our client and IT Manager before marking this closed.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SSL / HTTPS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.