zoukankan      html  css  js  c++  java
  • OpenSSL and s_client why is a private key required from the client?

    OpenSSL and s_client - why is a private key required from the client?

    回答1

    Certificates on their own are only public pieces of information. What links a public key certificate to the name it contains is the fact that whoever has legitimate control over that name (e.g. your name or your server's name) also has the private key for it.

    Certificates are used to prove the identity of the remote party by challenging the remote party to perform an operation that can only be done with the corresponding private key: signing something (which can be verified with the public key) or deciphering something that was encrypted with the public key. (Both can happen in the SSL/TLS handshake, depending on the cipher suite.)

    During the SSL/TLS handshake, the server sends its certificate (in clear) and proves to the client that it has the corresponding private key using an authenticated key exchange.

    In your case, you also want to use client-certificate authentication. It's not enough to send the client certificate during the handshake: the client must also prove it has the private key. Otherwise, anyone who receives that certificate could clone it. The point of using certificates is to prevent any cloning, in such a way that you never have to show your own secret (the private key).

    More specifically, the client has to sign the handshake messages in the Certificate Verify message of the TLS handshake so that the server can verify it against the public key sent in the client certificate. Without this step, no client-certificate authentication would be taking place.

    the client certificate was given to me by the third party, but it does not contain any private key

    Giving you your certificate without its private key seems a bit pointless, unless you're expected to have generated a certificate request on your side beforehand (in which case you would have the private key).

    Indeed, rather than being given a certificate and its private key, it's better practice for you to generate your key-pair, create a certificate request (CSR), and have your CA issue a certificate from that CSR (but without them ever knowing your private key). In this case, you would be expected to have kept your private key, and you would be able to use it with the cert you would have received.

    Client Private Key is set as part of client certificate authentication

    Having the certificate itself doesn't prove anything. Certificate is never secret, can be shared freely and as such multiple parties could be in a possession of a valid client certificate. As part of the TLS handshake with mutual authentication, client sends CertificateVerify message to prove it also has the private key matching the certificate it sent in Certificate message before. With TLS server already having client's certificate (and thus its public key), it can verify the signature.

    https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html

    服务器使用client certificate中的public key验证certificate verify,而certificate verify是用client certificate中的private key加密的

    https://support.alertlogic.com/hc/en-us/articles/360002999732-How-does-SSL-mutual-authentication-work-

    The server can validate the message digest of the digital signature by using the client's public key (which is found in the client certificate). 

  • 相关阅读:
    Python 基础知识----数据类型
    drf 之序列化组件
    Django Rest framework 框架之解析器
    css选择器
    Python 爬虫 解析库的使用 --- Beautiful Soup
    Python 爬虫 解析库的使用 --- XPath
    动态渲染页面爬取(Python 网络爬虫) ---Selenium的使用
    HDU 1014(互质数 **)
    HDU 6432(不连续环排列 ~)
    HDU 6433(2的n次方 **)
  • 原文地址:https://www.cnblogs.com/chucklu/p/15672234.html
Copyright © 2011-2022 走看看