精华内容
下载资源
问答
  • tls证书验证 因此,您有了一个管理面板,因为它比摆弄Rails控制台来管理应用程序要容易得多。 另一方面,这是一个非常敏感的地方。 如果有人获得了访问权限,那将是……不好。 您已经拥有了所有东西:没有保存在...

    tls证书验证

    因此,您有了一个管理面板,因为它比摆弄Rails控制台来管理应用程序要容易得多。 另一方面,这是一个非常敏感的地方。 如果有人获得了访问权限,那将是……不好。

    您已经拥有了所有东西:没有保存在电子邮件中的强密码,以及用于整个应用程序和蛮力保护的TLS。

    但是,如果除了您和其他几个人之外,其他任何人都无法访问管理面板,该怎么办?

    一种方法是使其成为Intranet上的内部应用程序。 另一个选择可能是要求相互TLS身份验证, ,客户端还使用客户端证书针对服务器对自身进行身份验证。 这就是我们在这篇文章中要讨论的内容。

    设置相互TLS身份验证

    相互认证? 这是如何运作的? 它涉及创建您自己的证书颁发机构,为管理面板自签名服务器和客户端证书,以及在浏览器中安装证书颁发机构和客户端证书。

    这是否意味着您将不再需要传统的管理员登录保护? 从理论上讲,没有; 不再需要了。 但是,我们想在这里添加另一个不干扰用户的身份验证,因此我们将保留登录表单。 另外,我们仍然需要CSRF保护的登录名。

    现有证书

    您可能已经在管理面板中使用了TLS,因此,如有可能,请将其移至子域。 这样可以更轻松地为应用程序的不同部分处理不同的证书。

    我要在https://client-ssl.bauland42.com/admin上安装我的系统。 出于演示目的,我预先安装了带有流行提供程序的Rails服务器,并且安装了一个简单的管理面板gem和Devise。 您可以像这样在路由中添加子域约束

    constraints subdomain: 'admin' do
      resources :users # or ActiveAdmin.routes(self) for the ActiveAdmin gem
    end

    认证中心(CA)

    我们将创建自己的CA,以对服务器和客户端证书请求进行签名。 根CA通常不直接签署证书。 通常,它们创建受信任的中间CA,以尽可能保留未使用的根证书密钥。

    由于我们仅使用很少的证书,因此我们将跳过该步骤。 但是,我们必须保持根CA密钥非常安全。 最好的选择是仅将其保留在断开连接的计算机上。

    认证机构证书

    为了本演示的目的,我们将所有CA密钥和证书保留在/etc/nginx/certs/ca中。 我们将为CA使用密钥长度4096。

    此处可以接受密钥长度为256位的3DESAES加密算法,并且最好使用强密码。 这将为CA创建一个新的私钥和密码:

    openssl genrsa -aes256 -out ca/ca.key 4096 chmod 400 ca/ca.key

    现在,我们可以使用SHA256哈希算法创建有效期为两年的根CA证书(不再使用SHA1):

    openssl req -new -x509 -sha256 -days 730 -key ca/ca.key -out ca/ca.crt

    通过输入将所有属性字段留空. 。 仅CommonName将是42CA来标识证书。

    chmod 444 ca/ca.crt

    您可以openssl x509 -noout -text -in ca/ca.crt使用openssl x509 -noout -text -in ca/ca.crt验证根证书,以检查有效性(2年)。 颁发者和主题均为42CA,因为这是根证书,始终是自签名的。

    证书签名请求(CSR)

    下一步是来自服务器的CSR,这是为特定域名创建证书的请求。 通常,CA和证书请求者是两个不同的公司,它们不想共享其私钥。 这就是为什么我们需要这个中间步骤。

    首先,我们将为服务器创建一个私钥,然后为CSR创建一个私钥。 此处2048位密钥就足够了,因为该密钥仅有效一年,而4096位将减慢TLS握手。 虽然,当然,管理面板将看到相对较低的流量。 这次我们也省略了-aes256选项,因为我们不想在每次启动Web服务器时都输入密码。

    openssl genrsa -out server/client-ssl.bauland42.com.key 2048
    chmod 400 server/client-ssl.bauland42.com.key
    openssl req -new -key server/client-ssl.bauland42.com.key -sha256 -out server/client-ssl.bauland42.com.csr

    对于后者,我们将为每个CSR详细信息输入一个点,但是“通用名称”必须是服务器的标准域名。 就我而言,它是client-ssl.bauland42.com

    服务器证书

    现在,我们将使用根CA签署CSR一年。 系统将提示您输入根CA的密码。

    openssl x509 -req -days 365 -sha256 -in server/client-ssl.bauland42.com.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 1 -out server/client-ssl.bauland42.com.crt
    chmod 444 server/client-ssl.bauland42.com.crt

    openssl x509 -noout -text -in server/client-ssl.bauland42.com.crt使用openssl x509 -noout -text -in server/client-ssl.bauland42.com.crt来验证有效性,颁发者(42CA)和主题( client-ssl.bauland42.com )。 可以肯定的是,我们还可以验证信任链。 虽然,它并不是真正的链条-根CA直接签署了服务器证书。 跑:

    openssl verify -CAfile ca/ca.crt server/client-ssl.bauland42.com.crt
    server/client-ssl.bauland42.com.crt: OK

    客户端证书(最终)

    生成客户端证书与创建服务器证书非常相似。 最好的选择是,如果用户创建了客户端的CSR,则服务器将看不到用户的私钥。 服务器将只签署CSR并将证书返回给用户。 请注意,我们正在使用序列号2将此证书。

    openssl genrsa -out client/heiko.key 2048
    openssl req -new -key client/heiko.key -out client/heiko.csr
    openssl x509 -req -days 365 -sha256 -in client/heiko.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/heiko.crt

    配置NGINX

    我正在本演示中使用NGINX,并且从Mozilla获得了现代且安全的SSL配置。 在HTTP(端口80)配置中,我将/ admin重定向到HTTPS版本。 对于SSL服务器,我将打开ssl_verify_client并通过ssl_client_certificate发送根CA证书。 您可以在此处找到本文的完整配置和其他资源

    这是两个重要部分:

    server {
      listen 80;
      ...
      location /admin {
        rewrite ^ https://$host$request_uri? permanent;
      }
      ...
    }
    server {
      listen 443 ssl;
      ...
      ssl_certificate /etc/nginx/certs/server/client-ssl.bauland42.com.crt;
      ssl_certificate_key /etc/nginx/certs/server/client-ssl.bauland42.com.key;
      ssl_client_certificate /etc/nginx/certs/ca/ca.crt;
      ssl_verify_client on;
      ...
    }

    在浏览器中安装CA

    为了通过浏览器连接到管理面板,我们可以在进入管理面板时忽略浏览器警告。 但这并不安全,因此我们必须在系统范围内或仅在浏览器中本地安装CA证书。

    我将在Firefox中安装它,因为这是最简单的。 使用scp将CA证书安全地复制到您的计算机:

    scp user@IP:/etc/nginx/certs/ca/ca.crt .

    然后通过Preferences > Advanced > Certificates > View Certificates > Authorities > Import …将其导入Firefox。 我只在“ 此证书可以识别网站 ”复选框中打勾。 现在,在浏览器中重新加载站点,您将看到预期的错误: 400错误的请求,未发送必需的SSL证书 。 如果遇到其他错误,请重新启动Firefox。

    安装客户端证书

    要安装客户端证书,我们需要一个PKCS#12文件,该文件同时存储证书和客户端的私钥。 您可以创建该文件,或者用户可以向她发送CSR,而不是为她创建私钥。

    openssl pkcs12 -export -clcerts -in client/heiko.crt -inkey client/heiko.key -out client/heiko.p12

    请按照提示完成以下步骤:

    1. 输入导出密码,导入密码在导入文件时也需要。
    2. 使用scp
      user@IP:/etc/nginx/certs/client/heiko.p12 .
      安全复制文件 scp
      user@IP:/etc/nginx/certs/client/heiko.p12 .
      到您的计算机。
    3. 在“偏好设置”>“高级”>“证书”>“查看证书”>“您的证书”中将其导入Firefox。
    4. 重新启动浏览器。
    5. 在“证书”选项卡上是“ 服务器请求我的个人证书时”选项。 我选择每次询问我
    6. 在出现的消息框中,选择一个客户端证书。 您可以选择记住本次会议的决定。

    选择一个客户证书

    在Firefox中选择一个客户端证书。

    管理面板

    如果您现在转到管理面板,则希望会看到一个客户端证书消息框和其后的管理员登录页面。

    您可能需要进行健全性检查,然后在其他浏览器中打开页面。 您将看到“无效的证书颁发机构”警告,但是现在您将转到不安全的站点,仅用于测试。

    NGINX将返回“ 400错误请求,未发送必需的SSL证书”错误,因为我们将ssl_verify_client设置ssl_verify_client on。 如果您不信任浏览器,则可以使用curl --insecure尝试相同操作,以忽略证书警告: curl --insecure https://client-ssl.bauland42.com/admin/

    授予和撤销访问

    将证书发送给同事时,请确保对电子邮件进行加密。 在同一分钟内,在日历中设置一个提醒,以在证书过期至少一周之前更新证书。 它们通常在最坏的时刻过期。

    每当颁发证书时,例如,如果有人离开公司,您还必须考虑如何吊销证书。 有证书吊销列表(CRL)和用于正式吊销证书的在线证书状态协议

    但是,我认为这里的设置过于严格,需要一些持续的维护。 无论如何,可能只有极少数人可以访问管理面板。 因此,我认为我们可以从Rails的客户端证书中将通用名称(CN)列入白名单。

    因此,我们将客户证书的主题放在特殊的X-Client-Dn标头中,从nginx传递到上游服务器:

    location @app {
            proxy_set_header X-Client-Dn $ssl_client_s_dn;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://app_server;
        }

    标头将如下所示:

    /CN=Heiko Webers/emailAddress=42@bauland42.de

    在应用程序中,我们可以将通用名称列入白名单,如下所示:

    raise unless request.headers['HTTP_X_CLIENT_DN'] =~ %r(\A\/CN=(.+)\/) && ['Heiko Webers'].include?($1)

    由于只有具有有效客户端证书的人员才能访问Rails应用程序,因此您不能仅发送标题字符串进行身份验证。

    有效客户证书

    Firefox中的绿色图标

    结论

    为了对应用程序敏感区域进行相互TLS身份验证,您需要满足以下条件:

    • 一个用于分隔SSL配置的子域(或新域)。
    • Web服务器配置。 这是我使用的完整NGINX示例配置 ,并提示了如何在Apache中执行此操作。
    • 您自己的证书颁发机构(CA)。
    • 自签名的Web服务器和客户端证书。 两者都必须安装在浏览器中。

    翻译自: https://www.javacodegeeks.com/2016/03/set-mutual-tls-authentication.html

    tls证书验证

    展开全文
  • 2、身份验证,也可以叫证书验证吧~ 3、消息完整性校验 第三个是网络协议中常用的一个校验和机制,我这我们就先按下不表。 加密 我们再看一遍客户端和服务端之间的加密机制: TLS协议是基于TCP协议之上的,...

    前言

    大家都知道,苹果在2016年WWDC上宣布了关于应用需要强制使用HTTPS的规定。这也算是个好消息吧,虽然开发者们可能需要适配下HTTPS,但是我们的应用可算是披上一个安全的保护罩了。本篇文章就算是笔者在学习HTTPS过程中的一个记录吧。

    HTTPS加密过程

    最近重新了解了下HTTP和HTTPS: 首先二者都是网络传输协议;HTTPS在传输过程中是可以通过加密来保护数据安全的,以免用户敏感信息被第三方获取。 可以说HTTPS是HTTP的升级版、安全版。下面我们就简单看下HTTPS的加密过程,先看下图。
    在这里插入图片描述
    1、客户端发起HTTPS请求
    这个没什么好说的,就是用户在浏览器里输入一个HTTPS网址,然后连接到服务端的443端口。
    2、服务端的配置
    采用HTTPS协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解,可以想象成一把钥匙和一个锁头,只是世界上只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。
    3、传送证书
    这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。
    4、客户端解析证书
    这部分工作是由客户端的SSL/TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警示框,提示证书存在的问题。如果证书没有问题,那么就生成一个***随机值***。然后用证书(也就是公钥)对这个随机值进行加密。就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。
    5、传送加密信息
    这部分传送的是用证书加密后的随机值,目的是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
    6、服务端解密信息
    服务端用私钥解密后,得到了客户端传过来的随机值,然后把内容通过该随机值进行对称加密,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够彪悍,私钥够复杂,数据就够安全。
    7、传输加密后的信息
    这部分信息就是服务端用私钥加密后的信息,可以在客户端用随机值解密还原。
    8、客户端解密信息
    客户端用之前生产的私钥解密服务端传过来的信息,于是获取了解密后的内容。整个过程第三方即使监听到了数据,也束手无策。

    到了这里,HTTPS的整个加密过程也就差不多完成了,但是这个过程中是不是还有些概念还是不太清楚,比如SSL是什么,TLS又是什么,他们是怎么验证我们的证书是否有效的呢,它们的验证策略又是怎样的呢。别急,下面我们就讨论下TLS。

    TLS

    刚开始听到TLS的时候,你可能还不太熟悉,但是说起SSL你可能就觉得好耳熟了。其实TLS就是从SSL发展而来的,只是SSL发展到3.0版本后改成了TLS。

    TLS主要提供三个基本服务

    1、加密
    2、身份验证,也可以叫证书验证吧~
    3、消息完整性校验

    第三个是网络协议中常用的一个校验和机制,我这我们就先按下不表。

    加密

    我们再看一遍客户端和服务端之间的加密机制:
    在这里插入图片描述
    TLS协议是基于TCP协议之上的,图中第一个蓝色往返是TCP的握手过程,之后两次橙色的往返,我们可以叫做TLS的握手。握手过程如下:

    client1:TLS版本号+所支持加密套件列表+希望使用的TLS选项
    Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+(要求客户端证书);
    Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥(自己生成的一个随机值);
    Server2:使用私钥解密出对称秘钥(随机值)后,发送加密的Finish消息,表明完成握手

    这里可能要提一下什么是对称加密和非对称加密:
    一般的对称加密像这样:

    encrypt(明文,秘钥) = 密文
    decrypt(密文,秘钥) = 明文

    复制代码也就是说加密和解密用的是同一个秘钥。而非对称加密是这样的:

    encrypt(明文,公钥) = 密文
    decrypt(密文,私钥) = 明文

    复制代码加密和解密是需要不同的秘钥的。
    经过这几次握手成功后,客服端和服务端之间通信的加密算法和所需要的密钥也就确定下来了,之后双方的交互都可以使用对称加密算法加密了。

    证书机制/证书验证

    在TLS中,我们需要证书来保证你所访问的服务器是真实的,可信的。
    看这张图我们来讨论下证书的验证过程。
    在这里插入图片描述
    1、客户端获取到了站点证书,拿到了站点的公钥;
    2、要验证站点可信后,才能使用其公钥,因此客户端找到其站点证书颁发者的信息;
    3、站点证书的颁发者验证了服务端站点是可信的,但客户端依然不清楚该颁发者是否可信;
    4、再往上回溯,找到了认证了中间证书商的源头证书颁发者。由于源头的证书颁发者非常少,我们浏览器之前就认识了,因此可以认为根证书颁发者是可信的;
    5、一路倒推,证书颁发者可信,那么它所颁发的所有站点也是可信的,最终确定了我们所访问的服务端是可信的;
    6、客户端使用证书中的公钥,继续完成TLS的握手过程。

    那么,客户端是是如何验证某个证书的有效性,或者验证策略是怎样的?
    证书颁发者一般提供两种方式来验证证书的有效性: CRL 和 OCSP。

    CRL

    CRL(Certificate Revocation List)即 证书撤销名单。证书颁发者会提供一份已经失效证书的名单,供浏览器验证证书使用。当然这份名单是巨长无比的,浏览器不可能每次TLS都去下载,所以常用的做法是浏览器会缓存这份名单,定期做后台更新。这样虽然后台更新存在时间间隔,证书失效不实时,但一般也OK。

    OCSP

    OCSP(Online Certificate StatusProtocol)即 在线证书状态协议。除了离线文件,证书颁发者也会提供实时的查询接口,查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手,延迟会更大。
    以上是站点在证书颁发者的角度说明会提供的两种判断方式,实际情况下浏览器究竟会选择哪种方式判断,每个浏览器都会有自己的实现。下面是通过Chrome查看GitHub网站的证书信息:
    在这里插入图片描述

    原文:https://juejin.im/post/5a4f4884518825732b19a3ce

    展开全文
  • https加解密过程详解和TLS证书验证

    千次阅读 2019-05-16 12:50:42
    身份验证,也可以叫证书验证吧~ 消息完整性校验 我们再看一遍客户端和服务端之间的加密机制: TLS 协议是基于 TCP 协议之上的,图中第一个蓝色往返是 TCP 的握手过程,之后两次绿色的往返,我们可以叫做 ...

    定义

    HTTPS是HTTP over SSL的简称,即工作在SSL上的HTTP,也就是加密通信的HTTP。

     

    工作原理

    HTTPS在通信过程中使用的是对称加密,当然,它的密钥是无法直接获取的,因为它的密钥是通过非对称加密进行传输的,中间还有很多复杂的过程,保证密钥是绝对安全的。

    先简单看下https的加密过程,如下图:

    文字描述一下这个过程,就是:

      1.客户端访问 https开头的url

      2.服务端返回公钥1,客户端验证通过(如果不通过,则访问终断)。

      3.客户端根据公钥1生成一个私钥2,这个私钥2用来加密和解密请求信息。使用公钥1对私钥2进行加密,回传给服务端。服务端用私钥1对该信息解密,得到私钥2。至此,客户端和服务端都已经有了私钥2。

      4.客户端和服务端之间使用私钥2对信息进行加密后通信,这样即使第三方抓包,也无法轻易获取通信内容了。

    这里的公钥1和私钥1是非对称加密,私钥2是对称加密。

    • 对称密钥(Symmetric-key algorithm)又称为共享密钥加密,对称密钥在加密和解密的过程中使用的密钥是相同的,常见的对称加密算法有DES、3DES、AES、RC5、RC6。对称密钥的优点是计算速度快,但是他也有缺点,密钥需要在通讯的两端共享,让彼此知道密钥是什么对方才能正确解密,如果所有客户端都共享同一个密钥,那么这个密钥就像万能钥匙一样,可以凭借一个密钥破解所有人的密文了,如果每个客户端与服务端单独维护一个密钥,那么服务端需要管理的密钥将是成千上万,这会给服务端带来噩梦。
    • 非对称密钥(public-key cryptography),又称为公开密钥加密,服务端会生成一对密钥,一个私钥保存在服务端,仅自己知道,另一个是公钥,公钥可以自由发布供任何人使用。客户端的明文通过公钥加密后的密文需要用私钥解密。非对称密钥在加密和解密的过程的使用的密钥是不同的密钥,加密和解密是不对称的,所以称之为非对称加密。与对称密钥加密相比,非对称加密无需在客户端和服务端之间共享密钥,只要私钥不发给任何用户,即使公钥在网上被截获,也无法被解密,仅有被窃取的公钥是没有任何用处的。常见的非对称加密有RSA。

     

    TLS

    刚开始听到TLS的时候,你可能还不太熟悉,但是说起SSL你可能就觉得好耳熟了。其实TLS就是从SSL发展而来的,只是SSL发展到3.0版本后改成了TLS

    TLS主要提供三个基本服务:

    • 加密
    • 身份验证,也可以叫证书验证吧~
    • 消息完整性校验

    我们再看一遍客户端和服务端之间的加密机制:

    TLS协议是基于TCP协议之上的,图中第一个蓝色往返是TCP的握手过程,之后两次绿色的往返,我们可以叫做TLS的握手。握手过程如下:

    1. client1TLS版本号+所支持加密套件列表+希望使用的TLS选项
    2. Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+(要求客户端证书)
    3. Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥(自己生成的一个随机值)
    4. Server2:使用私钥解密出对称秘钥(随机值)后,发送加密的Finish消息,表明完成握手

    经过这几次握手成功后,客户端和服务端之间通信的加密算法和所需要的密钥也就确定下来了,之后双方的通信都可以使用对称加密算法加密了。

     

    证书机制/证书验证

    TLS中,我们需要证书来保证你所访问的服务器是真实的,可信的。

    看这张图我们来讨论下证书的验证过程。

    1. 客户端获取到了站点证书,拿到了站点的公钥;
    2. 要验证站点可信后,才能使用其公钥,因此客户端找到其站点证书颁发者的信息;
    3. 站点证书的颁发者验证了服务端站点是可信的,但客户端依然不清楚该颁发者是否可信;
    4. 再往上回溯,找到了认证了中间证书商的源头证书颁发者。由于源头的证书颁发者非常少,我们浏览器之前就认识了,因此可以认为根证书颁发者是可信的;
    5. 一路倒推,证书颁发者可信,那么它所颁发的所有站点也是可信的,最终确定了我们所访问的服务端是可信的;
    6. 客户端使用证书中的公钥,继续完成TLS的握手过程。

    那么,客户端是如何验证某个证书的有效性,或者验证策略是怎样的?

    证书颁发者一般提供两种方式来验证证书的有效性:CRLOCSP

    CRL

    CRL(Certificate Revocation List)即证书撤销名单。证书颁发者会提供一份已经失效证书的名单,供浏览器验证证书使用。当然这份名单是巨长无比的,浏览器不可能每次TLS都去下载,所以常用的做法是浏览器会缓存这份名单,定期做后台更新。这样虽然后台更新存在时间间隔,证书失效不实时,但一般也OK。

    OCSP

    OCSP(Online Certificate StatusProtocol)即在线证书状态协议。除了离线文件,证书颁发者也会提供实时的查询接口,查询某个特定证书目前是否有效。实时查询的问题在于浏览器需要等待这个查询结束才能继续TLS握手,延迟会更大。

    以上是站点在证书颁发者的角度说明会提供的两种判断方式,实际情况下浏览器究竟会选择哪种方式判断,每个浏览器都会有自己的实现。

    展开全文
  • 目录 背景 相关工作 解决的问题 系统设计 实验
  • 基于深度学习的SSL/TLS证书验证程序的自动化测试 Deep Learning-based Automated Testing of Certificate Verification in SSL/TLS Implementations 目录 背景 相关工作 解决的问题 系统设计 实验 背 景 ...
  • SSL与TLS证书验证程序的自动化测试.pptx
  • SSL与TLS证书验证程序的自动化测试.pdf
  • tls证书验证A walk-through of a simplified implementation of mTLS. mTLS简化实现的演练。 First, what is TLS? 首先,什么是TLS? Transport Layer Security (TLS), and its now-deprecated predecessor, ...

    tls证书验证

    A walk-through of a simplified implementation of mTLS.

    mTLS简化实现的演练。

    First, what is TLS?

    首先,什么是TLS?

    Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL),[1] are cryptographic protocols designed to provide communications security over a computer network.[2] Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.

    传输层安全性(TLS)及其现在不推荐使用的安全套接字层(SSL)[1]是旨在在计算机网络上提供通信安全性的加密协议。[2] 协议的几种版本在Web浏览,电子邮件,即时消息传递和IP语音(VoIP)等应用程序中得到广泛使用。 网站可以使用TLS来保护其服务器与Web浏览器之间的所有通信。

    — Wikipedia — Transport Layer Security

    —维基百科— 传输层安全

    Yes, it is the mechanism by which our web browsers create secure connections to web servers. Just click on the lock in your browser’s address bar when visiting most any web site and you will get an informational popup.

    是的,这是我们的Web浏览器创建与Web服务器的安全连接的机制。 在访问大多数网站时,只需单击浏览器地址栏中的锁,您将看到一个信息弹出窗口。

    Image for post

    At the heart of TLS is Public Key Infrastructure (PKI) and in particular X.509 certificates.

    TLS的核心是公钥基础结构(PKI),尤其是X.509证书。

    In cryptography, X.509 is a standard defining the format of public key certificates.[1] X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS[2], the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures. An X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.

    在密码术中,X.509是定义公共密钥证书格式的标准。[1] X.509证书用于许多Internet协议中,包括TLS / SSL,这是HTTPS [2](浏览网页的安全协议)的基础。 它们还用于脱机应用程序,例如电子签名。 X.509证书包含公钥和身份(主机名,组织或个人),并且由证书颁发机构签名或自行签名。 当证书由受信任的证书颁发机构签名或通过其他方式进行验证时,持有该证书的人可以依靠其包含的公钥与另一方建立安全通信,或验证由相应私钥进行数字签名的文档。

    — Wikipedia — X.509

    —维基百科— X.509

    To inspect a X.509 certificate, click on the Certificate entry in the informational popup (shown when we clicked on the lock above).

    要检查X.509证书,请在信息弹出窗口中单击“ 证书”条目(当我们单击上面的锁时显示)。

    So then, what is mTLS?

    那么,什么是mTLS?

    By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer. TLS also offers client-to-server authentication using client-side X.509 authentication.[1] As it requires provisioning of the certificates to the clients and involves less user-friendly experience, it’s rarely used in end-user applications.

    默认情况下,TLS协议仅使用X.509证书向客户端证明服务器的身份,而客户端对服务器的身份验证则留给应用程序层。 TLS还使用客户端X.509身份验证提供客户端到服务器的身份验证。[1] 由于它需要向客户端提供证书,并且涉及的用户友好性较差,因此很少在最终用户应用程序中使用。

    Mutual TLS authentication (mTLS) is much more widespread in business-to-business (B2B) applications, where a limited number of programmatic and homogeneous clients are connecting to specific web services, the operational burden is limited, and security requirements are usually much higher as compared to consumer environments.

    相互TLS身份验证(mTLS)在企业对企业(B2B)应用程序中更为广泛,其中有限数量的编程和同类客户端正在连接到特定的Web服务,操作负担有限,并且对安全性的要求通常更高与消费者环境相比。

    — Wikipedia — Mutual authentication

    —维基百科— 相互认证

    With all this in mind, let us walk through a mTLS example of using the cURL web browser (the client) to connect to a Node.js web server (the server) serving on the DNS name localhost. In doing so:

    考虑到所有这些,让我们来看一个使用cURL Web浏览器(客户端)连接到DNS名称为localhost的Node.js Web服务器(服务器)的mTLS示例。 在这样做:

    • The client will validate that the server is trusted to serve up content for the DNS name localhost

      客户端将验证服务器是否可以提供DNS名称localhost的内容

    • The server will validate the client is known, i.e., it will authenticate it

      服务器将验证客户端是已知的,即它将对其进行身份验证

    The first step is to create a certificate authority (CA) that both the client and server trust. The CA is just a public and private key with the public key wrapped up in a self-signed X.509 certificate. The command we use to do this is:

    第一步是创建一个客户端和服务器都信任的证书颁发机构(CA)。 CA只是一个公钥和私钥,公钥包含在自签名的X.509证书中。 我们用于执行此操作的命令是:

    openssl req \
    -new \
    -x509 \
    -nodes \
    -days 365 \
    -subj '/CN=my-ca' \
    -keyout ca.key \
    -out ca.crt

    This outputs two files, ca.key and ca.crt, in the PEM format (base64 encoding of the private key and X.509 certificate respectively).

    这将以PEM格式 (分别为私钥和X.509证书的base64编码)输出两个文件ca.keyca.crt

    Looking at the openssl req documentation, we see that the -new and -x509 options enable the creation of a self-signed root CA X.509 certificate. The nodes (No DES) option disables securing the private key with a pass-code; this option is optional. The subj option provides the CA’s identity; in this case the Common Name (CN) of my-ca. The remaining options are self-explanatory.

    查看openssl req 文档 ,我们看到-new-x509选项启用了自签名根CA X.509证书的创建。 节点 (无DES)选项禁止使用密码保护私钥; 此选项是可选的。 subj选项提供CA的身份; 在这种情况下, my-ca的通用名称(CN)。 其余选项不言自明。

    We can turn-around and inspect the certificate using the following command:

    我们可以使用以下命令来周转和检查证书:

    openssl x509 \
    --in ca.crt \
    -text \
    --noout

    The options here are self-explanatory as documented in the openssl x509 documentation.

    openssl x509 文档中所述,此处的选项不言自明。

    Looking at the output, we can confirm a number of things:

    查看输出,我们可以确认以下几点:

    Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    [OBMITTED]
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: CN = my-ca
    Validity
    Not Before: Jun 13 00:49:48 2020 GMT
    Not After : Jun 13 00:49:48 2021 GMT
    Subject: CN = my-ca
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public-Key: (2048 bit)
    Modulus:
    [OBMITTED]
    Exponent: [OBMITTED]
    X509v3 extensions:
    X509v3 Subject Key Identifier:
    [OBMITTED]
    X509v3 Authority Key Identifier:
    keyid:[OBMITTED] X509v3 Basic Constraints: critical
    CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
    [OBMITTED]
    • Both the Subject and Issuer have the value CN = my-ca; this indicates that this certificate is self-signed

      主题颁发者的值均为CN = my-ca; 这表明该证书是自签名的

    • The Validity indicates that the certificate is valid for a year

      有效期表明证书有效期为一年

    • The X509v3 Basic Constraints value CA:TRUE indicate that this certificate can be used as a CA, i.e., can be used to sign certificates

      X509v3基本约束CA:TRUE表示此证书可以用作CA,即可以用来签署证书

    Next we create the server’s key and certificate; starting with the key:

    接下来,我们创建服务器的密钥和证书; 从键开始:

    openssl genrsa \
    -out server.key 2048

    The options here are self-explanatory as documented in the openssl genrsa documentation.

    此处的选项是不言自明的,如openssl genrsa 文档中所述

    Remember, our goal here is to create a server certificate for the DNS name localhost signed by the CA. We now create a Certificate Signing Request (CSR) with the Common Name (CN) localhost:

    记住,我们的目标是为由CA签名的DNS名称localhost创建服务器证书。 现在,我们用通用名称(CN) localhost创建一个证书签名请求(CSR):

    openssl req \
    -new \
    -key server.key \

    -out server.csr

    Using the CSR, the CA (really using the CA key and certificate) creates the signed certificate:

    使用CSR,CA(实际上使用CA密钥和证书)创建签名证书:

    openssl x509 \
    -req \
    -in server.csr \
    -CA ca.crt \
    -CAkey ca.key \
    -CAcreateserial \
    -days 365 \
    -out server.crt

    The output is the signed server certificate, server.crt, in the PEM format.

    输出为PEM格式的签名服务器证书server.crt

    Most of the options are either familiar (from above) or self-explanatory as documented in the openssl x509 documentation. The one exception is the CAcreateserial option that manages a newly created file, ca.srl, that enables each certificate created by this CA to have a unique serial number.

    多数选项是熟悉的(从上方)或不加解释,如openssl x509 文档中所述 。 一个例外是CAcreateserial选项,该选项管理一个新创建的文件ca.srl ,该文件使该CA创建的每个证书都具有唯一的序列号。

    As before we inspect the certificate using the following command:

    和以前一样,我们使用以下命令检查证书:

    openssl x509 \
    --in server.crt \
    -text \
    --noout

    Looking at the output, we can confirm a number of things:

    查看输出,我们可以确认以下几点:

    Certificate:
    Data:
    Version: 1 (0x0)
    Serial Number:
    [OBMITTED]
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: CN = my-ca
    Validity
    Not Before: Jun 13 00:50:18 2020 GMT
    Not After : Jun 13 00:50:18 2021 GMT
    Subject: CN = localhost
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public-Key: (2048 bit)
    Modulus:
    [OBMITTED]
    Exponent: [OBMITTED]
    Signature Algorithm: sha256WithRSAEncryption
    [OBMITTED]
    • The Issuer has the value CN = my-ca; this indicates that this certificate is signed by the my-ca certificate authority

      发行者的值为CN = my-ca; 这表明此证书是由my-ca证书颁发机构签名的

    • The Validity indicates that the certificate is valid for a year

      有效期表明证书有效期为一年

    • The Subject has the value CN = localhost; this indicates that this certificate can be served to a client to validate that the server is trusted to serve up content for the DNS name localhost

      主题的值为CN = localhost ; 这表明可以将该证书提供给客户端,以验证服务器是否可以信任DNS名称localhost的内容。

    We essentially repeat the process to create the client’s key and certificate; starting by creating the client’s key:

    我们实质上重复创建客户密钥和证书的过程; 首先创建客户的密钥:

    openssl genrsa \
    -out client.key 2048

    Creating the CSR with the arbitrary Common Name of my-client:

    使用my-client的任意通用名称创建CSR

    openssl req \
    -new \
    -key client.key \

    -out client.csr

    And finally the creating the client’s certificate:

    最后是创建客户的证书:

    openssl x509 \
    -req \
    -in client.csr \
    -CA ca.crt \
    -CAkey ca.key \
    -CAcreateserial \
    -days 365

    note: If you inspect this certificate, you will observe that the Serial Number is indeed different than the server’s certificate.

    注意 :如果您检查此证书,则会发现序列号确实与服务器的证书不同。

    One observation is that both the server and client certificates are simpler X.509 v1 certificates; the CA certificate however is a X.509 v3 certificate. This is because OpenSSL automatically creates X.508 v3 self-signed certificates (CA certificate) and we did not supply any v3 extensions when signing the server and client certificates (using the extfile and extensions options).

    一种观察结果是,服务器证书和客户端证书都是较简单的X.509 v1证书。 但是,CA证书是X.509 v3证书。 这是因为OpenSSL自动创建X.508 v3自签名证书(CA证书),并且在对服务器证书和客户端证书进行签名时(使用extfileextensions选项)我们没有提供任何v3扩展

    note: The use of various X.509 v3 extensions is outside the scope of this article; besides I have not found any simple explanations of them myself.

    注意 :各种X.509 v3扩展的使用超出了本文的范围; 除了我自己,我还没有找到任何简单的解释。

    With all of our keys and certificates (ca, server, and client) created we can configure our server and client.

    使用我们创建的所有密钥和证书(ca,服务器和客户端),我们可以配置服务器和客户端。

    The server is the basic Hello World example, provided by Node.js, enhanced to support mTLS.

    该服务器是Node.js提供的基本Hello World示例 ,已增强为支持mTLS。

    Here the requestCert, rejectUnauthorized, and ca options are used to require the browser (client) to supply a certificate signed by the CA certificate to interact with the server.

    在这里, requestCertrejectUnauthorizedca选项用于要求浏览器(客户端)提供由CA证书签名的证书,以便与服务器进行交互。

    The key and cert options enable the server to serve up the CA signed server certificate.

    密钥证书选项使服务器可以提供CA签名的服务器证书。

    The client is simply the cURL web browser with options:

    客户端只是具有以下选项的cURL Web浏览器:

    curl \
    --cacert ca.crt \
    --key client.key \
    --cert client.crt \
    https://localhost:3000

    Here the cacert option is used so that the client (cURL) can validate the server supplied certificate. The key and cert are used so the client sends the CA signed client certificate with the request.

    在这里,使用cacert选项,以便客户端(cURL)可以验证服务器提供的证书。 使用密钥证书 ,以便客户端将CA签名的客户端证书与请求一起发送。

    Indeed, we observe that this request successfully returns hello world. If, however, we leave off the cacert option, we get the error:

    实际上,我们观察到该请求成功返回hello world 。 但是,如果不使用cacert选项, 则会收到错误消息:

    curl --key client.key --cert client.crt  https://localhost:3000
    curl: (60) SSL certificate problem: self signed certificate in certificate chain
    More details here: https://curl.haxx.se/docs/sslcerts.htmlcurl failed to verify the legitimacy of the server and therefore could not
    establish a secure connection to it. To learn more about this situation and
    how to fix it, please visit the web page mentioned above.

    On the other hand, if we leave off the key and cert options, we get a different error:

    另一方面,如果我们省略了key和cert选项,则会得到另一个错误:

    curl --cacert ca.crt https://localhost:3000
    curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

    Wrap Up

    结语

    Nothing spectacularly new here. At the same time, hope you learned something.

    这里没有什么新奇的东西。 同时,希望您能学到一些东西。

    翻译自: https://codeburst.io/mutual-tls-authentication-mtls-de-mystified-11fa2a52e9cf

    tls证书验证

    展开全文
  • 出现的错误提示不是很明确,没有支出到底为啥证书验证失败,只能进行各种排查 1、检查命令参数是否正确--->确定正确 2、在ubuntu上进行测试--->同样的命令可以正常发布/订阅消息 3、更换opens
  • 科普:TLS、SSL、HTTPS以及证书 不少人可能听过其中的超过3个名词,但它们究竟有什么关联呢? TLS是传输层安全协议(Transport Layer Security)的缩写,是一种对基于网络的传输的加密协议,可以在受信任的第三方...
  • 《为 Horizon 7 设置 TLS 证书的方案》提供了一些示例来说明如何设置 TLS 证书以供 Horizon 7 服务器使 用。第一个方案演示如何从证书颁发机构获取签名 TLS 证书,并确保证书具有可供 Horizon 7 Server 使用 的格式...
  • 这个CA证书的问题,导致我不能上传代码,发现有个简单粗暴的方法: git config --global http.sslVerify false 记录下来备用
  • nginx 双向证书验证Additional layer of security for your Flask or FastAPI serverFlask或FastAPI服务器的附加安全层 You will learn to create self-signed server certificates in order to serve your web ...
  • TLS1.3通信中,使用双方数字证书进行身份认证,在一个完整的通信中计算出所有的密钥,在计算每个密钥的过程中,对所用到的输入以及各种条件进行详细地说明,感兴趣的爱好者可以借鉴,希望能对你有所帮助。
  • mbedtls学习(10)数字证书X.509

    千次阅读 2019-11-24 17:16:25
    数字证书又称公钥证书或身份证书,目的是为了解决密钥分发问题,因为虽然有了公钥算法和数字签名算法,但是如果攻击者将公钥都替换掉则不能验证对方身份。所以才有数字证书的出现,数字证书主要包含公钥信息、用户...
  • tlspretense, 测试 SSL/TLS 客户端证书验证的测试框架 TLSPretense - SSL/TLS 客户机测试框架测试 SSL/TLS 客户端证书验证的测试框架。描述注:TLSPretense仍在进行大量抛光。 它目前可用,但功能可能会改变,文档...
  • HTTPS之TLS证书

    2020-11-16 20:57:13
    TLS证书格式1. 概述2. 示例:知乎网站证书解析(mac系统)3. 通过openssl获取证书的含义三. 证书链(Certificate Chain)1. 背景2. 概述3. 背景问题的解释参考资料 一. TLS概述 1. TLS概述 TLS 握手的作用之一是...
  • 客户端 config := &tls.Config{ Certificates: []tls.Certificate{crt}, RootCAs: pool, InsecureSkipVerify: false, } 客户端tls配置, Certificates 客户端证书 RootCAs 根证书验证,简单点...
  • Flask-TLSAuth 集成了一个最小的证书颁发机构(CA)并实现了 TLS 客户端证书认证。 它依赖于 nginx 来处理 TLS 身份验证部分。 安装 pip install flask_tlsauth Flask-TLSAuth 依赖于 tlsauth,它提供了充当 CA 的...
  • TLS客户端身份验证

    2020-04-26 07:58:05
    我决定为电子识别方案设计一个原型,因此我研究了如何使用Java / Spring服务器端进行TLS客户端身份验证(即使您不是Java开发人员,也可以继续阅读-大部分文章是Java -不可知)。 为什么要进行TLS客户端身份验证? ...
  • SSL证书/TLS证书是什么

    万次阅读 2018-01-29 11:59:01
    A. SSL协议与TLS是什么?它们的功能是什么? 答:SSL(Security Socket Layer)是一种广泛运用在互联网上的资料加密协议;...3. 透过SSL证书内的公共金钥加密资料传输至服务器端,服务器端用私密金钥解密来证明
  • ... 本人一个普通程序员,项目期间工期紧张,并未抽出时间详细了解Https网络请求过程中TLS握手过程,因此这件事一直在我的待办...这篇文章以Wireshark抓包,详细了解Https请求中TLS的握手过程 与 客户端证书校验过程。 H
  • 证书关系到了SSL的众多安全性,比如身份认证,密钥交换。所以有必要单拉出一章来讲证书。本章完善一下前几节中的身份认证的一些缺点。 首先,通过前面讲解,我们知道,证书需要几个重要的字段。例如“拥有者”、...
  • (1)验证SSL证书验证证书链中的所有证书是否存在错误 (2)实现证书过期检查。检查证书链中所有证书证书到期 (3)该工具还会检查证书中是否存在所有可能的重定向URL
  • 之前搞的https请求,对百度等确实有效,但是拿到生产环境就会抛出异常,这是因为jdk1.6版本不支持TLS1.2协议,而对方平台服务器采用了TLS1.2服务器,此处需要第三方插件 jar包为:bcprov-jdk15on-1.54.jar 首先继承...
  • mbedTLS验证服务器证书

    千次阅读 2017-12-07 16:53:22
    验证服务器证书 mbedtls_printf( " . Verifying peer X.509 certificate..." ); /* In real life, we probably want to bail out when ret != 0 */ if( ( flags = mbedtls_ssl_get_verify_result( &ssl ) ) !=
  • RFC8705-OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens 摘要 ...为OAuth授权服务器提供了一种将访问令牌绑定到客户端的双向TLS证书的机制,并且为OAuth保..
  • http-01和tls-alpn-01验证 HTTPS(带有证书自动颁发)和HTTP反向代理 零配置以开始使用 签发证书的期限 自动在证书中包含子域(默认值:domain和 ) 记录stderr和/或文件 自转日志文件(可以通过配置禁用) 可以...
  • 解决过程: 通过提示知道问题出在证书验证,仔细排查发现证书并没有任何问题。 随后我在Communicator的选项中...仔细想了一下,想到由于TLS是通过证书验证,而证书中包含的是DNS的名称,并且TLS也是使用的DNS...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 40,227
精华内容 16,090
关键字:

tls证书验证