.p12文件同时包含了证书，私钥，和证书链。安装.p12文件后，情况如下：有三个证书，
- In the Details tab, the certificates intended purpose has the following text: “Proves your identity to a remote computer”
- Verify that the Enhanced Key Usage field of the certificate has the OID set to (1.3. 6.1. 5.5. 7.3. 2).
用代码解析证书后，一共有4个。第四个是授权给个人使用的，绑定了一个邮箱。
这四个证书，包含了证书链。所以服务端应该是可以确认客户端最后一个证书的真实性的。所以，服务器上必然安装有前面三个证书。
另外客户端发给服务端的证书，是没有加密的证书(从.p12里面解析出来的最后一个证书)，证书本身不包含私钥，是可以使用的。
最后服务端收到的证书是没有加密的，可以直接从证书里面提取公钥。对客户端稍后发过来的certificate verify进行验证。
(certificate verify是经过证书里面的私钥加密的信息，可以用证书里面的公钥进行验证)
证书本身是包含公钥的
.p12安装在current user下的话，
| CertificateAuthority | 3 |
The X.509 certificate store for intermediate certificate authorities (CAs). |
| Root | 6 |
The X.509 certificate store for trusted root certificate authorities (CAs). |
Find the certificate 【CN=Class 1 Authentication CA - G2, O=Renault】 with thumbprint C11A93A3860BBC8D13DF61417DBC375EEA8062BD under CurrentUser/CertificateAuthority
Find the certificate 【CN=Renault Internal CA - G2, O=Alliance】 with thumbprint E39C035F64D2982D18DE6750392410633701D656 under CurrentUser/CertificateAuthority
Find the certificate 【CN=Alliance Root CA - G2, O=Alliance】 with thumbprint 4A5C0EFA611160AE86B719EFF2FC005F67612D58 under CurrentUser/Root
Find the certificate 【OID.0.9.2342.19200300.100.1.1=awtag04, E=test@chuck.com, CN=TROPHEE IRN-9690, O=Renault】 with thumbprint 3670CFBFA9E736DFCAB784B0304D2C0CA3B5D3B2 under CurrentUser/My
貌似也会自动把前面三个证书安装在LocalMachine的位置下，但是最后一个证书不会安装在LocalMachine下的My下面。因为只有最后一个证书，是签发给个人的。
Find the certificate 【CN=Class 1 Authentication CA - G2, O=Renault】 with thumbprint C11A93A3860BBC8D13DF61417DBC375EEA8062BD under LocalMachine/CertificateAuthority
Find the certificate 【CN=Renault Internal CA - G2, O=Alliance】 with thumbprint E39C035F64D2982D18DE6750392410633701D656 under LocalMachine/CertificateAuthority
Find the certificate 【CN=Alliance Root CA - G2, O=Alliance】 with thumbprint 4A5C0EFA611160AE86B719EFF2FC005F67612D58 under LocalMachine/Root
Can not find the certificate with thumbprint 3670CFBFA9E736DFCAB784B0304D2C0CA3B5D3B2 under LocalMachine AddressBook,AuthRoot,CertificateAuthority,Disallowed,My,Root,TrustedPeople,TrustedPublisher
代码提取
X509Certificate2Collection certificates = new X509Certificate2Collection();
certificates.Import(rawData, password,
X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet |
X509KeyStorageFlags.Exportable);
How to validate a client certificate
问题
My understanding is that when using a client certificate for security one issues a private and public key cert (for example X509) of some sort and sends that of to the consumer of the service that one wants to authorize themselves before consuming.
But what's then the standard way of checking that it's actually a valid client cert they are presenting? Please present the standard workflow here and also the role of the CA in this case.
also wondering what's preventing someone for just exporting the client cert from the client machine and using it somewhere else, is preventing export for the private key safe enough?
回答1
From a high level perspective, three things have to happen:
-
The client has to prove that it is the proper owner of the client certificate. The web server challenges the client to sign something with its private key, and the web server validates the response with the public key in the certificate.
-
The certificate has to be validated against its signing authority This is accomplished by verifying the signature on the certificate with the signing authority's public key. In addition, certificate revocation lists (CRLs) are checked to ensure the cert hasn't been blacklisted.
-
The certificate has to contain information which designates it as a valid user of the web service. The web server is configured to look at specific items in the certificate (typically the subject field) and only allow certain values.
How exactly TLS/SSL works regarding client certificate?
I can copy/paste from openssl wiki: https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Client_Authentication
Basically Client send Client Certificate to server that match the CA DN given by Server. Client send then a Cerificate Verify that uses its private key to prove he owns it.
A Client Certificate authentication requires the client to own a Certificate and have the corresponding private key. Client never send its private key but use it to prove he has the corresponding pair key of public key advertised within Certificate.
What he digests ? a digest of the whole handshakes exchanges so far. If server manage to verify this with public key and it matches digest of whole handshake so far (computed at server side) then i prove two things :
- client owns private key ( else deciphering with public key would not be correct )
- client is at the other side of this handshake, it protects against replay of a client Certificate Verify from another handshake.
So yes challenge is in fact whole handshake messages.
Client Authentication
Client authentication is optional. In many cases the client does not authenticate at the ssl layer, but rather with the usage of protocols above ssl, for example with HTTP authentication methods.
Client Certificates
- Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.
- Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).
- CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).
This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.