understanding client certificate - pfx on the general

Question

Today I am given a pfx and told to access a website. I have absolutely no idea what was given to me initially, so please kindly confirm my understanding on a general level

1) the pfx is a container which is use to safeguard private key and certificate.

2) when I double click the pfx, it actually prompt me for a password. This is the password use for extracting the contents (e.g. private key and cert).

window prompted me to choose on which store to put the certificate or automatically select the certificate store

q1) how do I find out where is the certificate store on my system ?

q2) where is the private key extracted to then ?

In this scenario, I believe in order to access a website, the client will need to provide the certificate which contain the public key which the server will use to communicate with it.

In order for all these to work (client authentication)

• a) the client must generate a CSR with its public key inside
• b) the client must submit the CSR to be signed by an authorized CA
• c) the authorized CA certification and all roots certficates for it must be installed/available in the SERVER side
• d) the client send its certificate over to the server, the server validate the cert, uses the cert's public key to encrypt information before sending over to the client.
• e) the client who has the private key will decrypt this information etc etc.

this private key and certificate is store in a pfx file. Anyone with the pfx file (and the password to open the pfx) file, can communicate with the server.

q3) does that means anyone/client who has a valid certificate signed by a CA can access the server then ? how does the server choose which client to allow access and which not to ?

Answer 1

So let's tackle easy first:

Q1/Q2 you can see your certificates in the certificate manager a.k.a. certmgr.msc

Q3 your scenario is probably wrong. If you are provided with a client certificate, it is probably already signed by some certificate authority (maybe an internal CA used by the service you're trying to access maybe).

Therefore, the CSR workflow don't have to happen here, since you do not need to generate a certificate from a freshly generated key pair.

If you are referring to the process of creating the certificate prior to you getting one shipped, then you are correct. Public key goes into a CSR with your info. Some CA signs it. You need the root CA of the chain.

The last part is the authentication. I'm currently looking for the right protocol, if there is one. But what should be done is:

• check the signature of the certificate against the CA public key
• check the validity of the certificate
• check for revocation
• check the subject of the certificate (from who it comes from)
• assess proof of possession (through a challenge)

The client certificate might not have to be send, if there is a public keystore for the webservice.

Resources :

• oracle - Sun Directory Server Enterprise protocol
• The bear stance on client cert validation

Answer 2

q1) If you are asked to connect to a webpage through your browser, its very likely that its supposed to be in your own 'Personal' store.

q2) It ends up in your certificate store, most likely 'Your user' 'Personal', use MMC. (Google 'How to: View Certificates with the MMC Snap-in')

q3) Yes. Most likely. You have probably been given your client certificate that will give you access.

It might require a client certificate that is signed by the CA, but it doesn't need to be the only requirement. A web application can even have a list of what client certificates to accepts, or to accept only those with a name that begins with 'A'. Given the information provided, it is really hard to say.

I guess this is SSL Client Authentication without any special tricks, so 'Yes'.