使用客户端证书认证的curl

11

我们希望使用客户端证书认证而不是基本认证来访问Web服务器。

证书是PEM证书,密钥文件是单独的文件。

curl调用如下:

curl -v --cert cert.crt --key key.key --pass foobar https://testserver/soap/request

来自调试日志:

HTTP/1.1 401 Unauthorized
X-message-code: PWD_WRONG
WWW-Authenticate: Basic realm="Test Platform"
Transfer-Encoding: chunked
Date: Wed, 30 May 2018 10:26:51 GMT
Server: TEST
Set-Cookie: ...

我了解到WWW-Authenticate: Basic是服务器向客户端提供基本身份验证的请求。但是,这可能发生在未经身份验证的请求中,因此它并不能证明服务器不提供证书验证。

阅读https://medium.com/@sevcsik/authentication-using-https-client-certificates-3c9d270e8326作为双重检查,我尝试使用Firefox浏览器将两个文件合并为PKCS#12格式,并将其导入浏览器。它有效,所以服务器支持证书验证。

失败的curl调用有什么问题?是否有任何支持证书认证的测试服务器?https://www.httpbin.org/似乎没有提供该设置。

当使用PKCS#12版本与curl时,会出现相同的错误:

curl -v --cert cert.p12 --cert-type p12 --pass foobar
https://testserver/soap/request...

完整的调试日志:
* Uses proxy env variable no_proxy == '10.0.0.0/8,127.0.0.1,172.16.0.0/12,192.168.20.0/24,'
* Uses proxy env variable https_proxy == 'http://gateway01:8080'
*   Trying 10.190.224.23...
* TCP_NODELAY set
* Connected to gateway01 (10.190.224.23) port 8080 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to testserver:443
> CONNECT testserver:443 HTTP/1.1
> Host: testserver:443
> User-Agent: curl/7.60.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 Connection established
< 
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=DE; ST=Baden-Wurttemberg; L=...; O=...; OU=...; CN=...
*  start date: Aug 15 07:54:38 2016 GMT
*  expire date: Aug 15 07:54:38 2019 GMT
*  subjectAltName: host "testserver" matched cert's "*.testserver"
*  issuer: C=NL; L=Amsterdam; O=Verizon Enterprise Solutions; OU=Cybertrust; CN=Verizon Public SureServer CA G14-SHA2
*  SSL certificate verify ok.
> GET /soap/request HTTP/1.1
> Host: testserver
> User-Agent: curl/7.60.0
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
< X-message-code: PWD_WRONG
< WWW-Authenticate: Basic realm="Test Platform"
< Transfer-Encoding: chunked
< Date: Wed, 06 Jun 2018 05:10:56 GMT
< Server: TEST
< Set-Cookie: ...; path=/; httponly; secure
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< 
* Connection #0 to host gateway01 left intact

作为 Firefox 能够进行身份验证,我使用 Wireshark 分析了两个请求。通过过滤“tcp contains”和我的证书的已知 CN,在两个网络转储中找到了证书数据,但 Firefox 和 curl 将证书放置在不同的数据包中。在本地主机上有一个 SOCKS5 代理:localhost:8081,我捕获回环接口并过滤该 tcp 端口 8081,您可以在转储中看到:
$ tshark -r firefox_request.pcapng
    1 0.000000000    127.0.0.1 → 127.0.0.1    TCP 74 51254 → 8081 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1945282596 TSecr=0 WS=128
    2 0.000013339    127.0.0.1 → 127.0.0.1    TCP 74 8081 → 51254 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1945282596 TSecr=1945282596 WS=128
    3 0.000025766    127.0.0.1 → 127.0.0.1    TCP 66 51254 → 8081 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=1945282597 TSecr=1945282596
    4 0.000052377    127.0.0.1 → 127.0.0.1    TCP 69 51254 → 8081 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=3 TSval=1945282597 TSecr=1945282596
    5 0.000058018    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51254 [ACK] Seq=1 Ack=4 Win=43776 Len=0 TSval=1945282597 TSecr=1945282597
    6 0.000110299    127.0.0.1 → 127.0.0.1    TCP 68 8081 → 51254 [PSH, ACK] Seq=1 Ack=4 Win=43776 Len=2 TSval=1945282597 TSecr=1945282597
    7 0.000127024    127.0.0.1 → 127.0.0.1    TCP 66 51254 → 8081 [ACK] Seq=4 Ack=3 Win=43776 Len=0 TSval=1945282597 TSecr=1945282597
    8 0.000145980    127.0.0.1 → 127.0.0.1    TCP 112 51254 → 8081 [PSH, ACK] Seq=4 Ack=3 Win=43776 Len=46 TSval=1945282597 TSecr=1945282597 [TCP segment of a reassembled PDU]
    9 0.049958725    127.0.0.1 → 127.0.0.1    TCP 76 8081 → 51254 [PSH, ACK] Seq=3 Ack=50 Win=43776 Len=10 TSval=1945282646 TSecr=1945282597
   10 0.050239394    127.0.0.1 → 127.0.0.1    TCP 583 51254 → 8081 [PSH, ACK] Seq=50 Ack=13 Win=43776 Len=517 TSval=1945282647 TSecr=1945282646 [TCP segment of a reassembled PDU]
   11 0.100158230    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51254 [ACK] Seq=13 Ack=567 Win=44800 Len=0 TSval=1945282697 TSecr=1945282647
   12 0.107621822    127.0.0.1 → 127.0.0.1    TLSv1.2 2786 Server Hello
   13 0.107672270    127.0.0.1 → 127.0.0.1    TCP 66 51254 → 8081 [ACK] Seq=567 Ack=2733 Win=174720 Len=0 TSval=1945282704 TSecr=1945282704
   14 0.107832838    127.0.0.1 → 127.0.0.1    TLSv1.2 1426 Certificate, Server Key Exchange
   15 0.108417953    127.0.0.1 → 127.0.0.1    TCP 1426 8081 → 51254 [PSH, ACK] Seq=4093 Ack=567 Win=44800 Len=1360 TSval=1945282705 TSecr=1945282704 [TCP segment of a reassembled PDU]
   16 0.108423407    127.0.0.1 → 127.0.0.1    TCP 66 51254 → 8081 [ACK] Seq=567 Ack=5453 Win=436608 Len=0 TSval=1945282705 TSecr=1945282704
   17 0.109263897    127.0.0.1 → 127.0.0.1    TLSv1.2 2674 Certificate Request, Server Hello Done
   18 0.118830308    127.0.0.1 → 127.0.0.1    TCP 3613 51254 → 8081 [PSH, ACK] Seq=567 Ack=8061 Win=464896 Len=3547 TSval=1945282715 TSecr=1945282706 [TCP segment of a reassembled PDU]
   19 0.118851470    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51254 [ACK] Seq=8061 Ack=4114 Win=175744 Len=0 TSval=1945282715 TSecr=1945282715
   20 0.173415105    127.0.0.1 → 127.0.0.1    TLSv1.2 117 Change Cipher Spec, Client Hello[Malformed Packet]
   21 0.173932334    127.0.0.1 → 127.0.0.1    TCP 798 51254 → 8081 [PSH, ACK] Seq=4114 Ack=8112 Win=464896 Len=732 TSval=1945282770 TSecr=1945282770 [TCP segment of a reassembled PDU]
   22 0.173943923    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51254 [ACK] Seq=8112 Ack=4846 Win=182912 Len=0 TSval=1945282770 TSecr=1945282770
   23 0.250413758    127.0.0.1 → 127.0.0.1    TLSv1.2 844 Application Data
   24 0.300115138    127.0.0.1 → 127.0.0.1    TCP 66 51254 → 8081 [ACK] Seq=4846 Ack=8890 Win=464896 Len=0 TSval=1945282897 TSecr=1945282847
   25 2.490166002    127.0.0.1 → 127.0.0.1    TCP 798 51254 → 8081 [PSH, ACK] Seq=4846 Ack=8890 Win=464896 Len=732 TSval=1945285087 TSecr=1945282847 [TCP segment of a reassembled PDU]
   26 2.490201268    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51254 [ACK] Seq=8890 Ack=5578 Win=184320 Len=0 TSval=1945285087 TSecr=1945285087
   27 2.554148656    127.0.0.1 → 127.0.0.1    TLSv1.2 844 Application Data
   28 2.554155780    127.0.0.1 → 127.0.0.1    TCP 66 51254 → 8081 [ACK] Seq=5578 Ack=9668 Win=464896 Len=0 TSval=1945285151 TSecr=1945285151
   29 12.610141935    127.0.0.1 → 127.0.0.1    TCP 66 [TCP Keep-Alive] 51254 → 8081 [ACK] Seq=5577 Ack=9668 Win=464896 Len=0 TSval=1945295207 TSecr=1945285151
   30 12.610162448    127.0.0.1 → 127.0.0.1    TCP 66 [TCP Keep-Alive ACK] 8081 → 51254 [ACK] Seq=9668 Ack=5578 Win=184320 Len=0 TSval=1945295207 TSecr=1945285151

Curl:

$ tshark -r curl_request.pcapng
    1 0.000000000    127.0.0.1 → 127.0.0.1    TCP 74 51196 → 8081 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1944382941 TSecr=0 WS=128
    2 0.000014517    127.0.0.1 → 127.0.0.1    TCP 74 8081 → 51196 [SYN, ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1944382941 TSecr=1944382941 WS=128
    3 0.000026917    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=1 Ack=1 Win=43776 Len=0 TSval=1944382941 TSecr=1944382941
    4 0.000068294    127.0.0.1 → 127.0.0.1    TCP 69 51196 → 8081 [PSH, ACK] Seq=1 Ack=1 Win=43776 Len=3 TSval=1944382941 TSecr=1944382941
    5 0.000076382    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=1 Ack=4 Win=43776 Len=0 TSval=1944382941 TSecr=1944382941
    6 0.000105767    127.0.0.1 → 127.0.0.1    TCP 68 8081 → 51196 [PSH, ACK] Seq=1 Ack=4 Win=43776 Len=2 TSval=1944382941 TSecr=1944382941
    7 0.000114276    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=4 Ack=3 Win=43776 Len=0 TSval=1944382941 TSecr=1944382941
    8 0.012753479    127.0.0.1 → 127.0.0.1    TCP 76 51196 → 8081 [PSH, ACK] Seq=4 Ack=3 Win=43776 Len=10 TSval=1944382954 TSecr=1944382941
    9 0.056073156    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=3 Ack=14 Win=43776 Len=0 TSval=1944382997 TSecr=1944382954
   10 0.060558849    127.0.0.1 → 127.0.0.1    TCP 76 8081 → 51196 [PSH, ACK] Seq=3 Ack=14 Win=43776 Len=10 TSval=1944383002 TSecr=1944382954
   11 0.106077184    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=14 Ack=13 Win=43776 Len=0 TSval=1944383047 TSecr=1944383002
   12 0.156827822    127.0.0.1 → 127.0.0.1    TLSv1 583 Client Hello
   13 0.156838865    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=13 Ack=531 Win=44800 Len=0 TSval=1944383098 TSecr=1944383098
   14 0.204829368    127.0.0.1 → 127.0.0.1    TLSv1.2 2786 Server Hello
   15 0.204837221    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=531 Ack=2733 Win=174720 Len=0 TSval=1944383146 TSecr=1944383146
   16 0.204942723    127.0.0.1 → 127.0.0.1    TLSv1.2 4146 Certificate, Server Key Exchange
   17 0.204950957    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=531 Ack=6813 Win=305664 Len=0 TSval=1944383146 TSecr=1944383146
   18 0.204981363    127.0.0.1 → 127.0.0.1    TLSv1.2 1314 Certificate Request, Server Hello Done
   19 0.204987399    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=531 Ack=8061 Win=436608 Len=0 TSval=1944383146 TSecr=1944383146
   20 0.208331980    127.0.0.1 → 127.0.0.1    TLSv1.2 2066 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
   21 0.208341083    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=8061 Ack=2531 Win=175744 Len=0 TSval=1944383149 TSecr=1944383149
   22 0.255529146    127.0.0.1 → 127.0.0.1    TLSv1.2 117 Change Cipher Spec, Client Hello[Malformed Packet]
   23 0.255792019    127.0.0.1 → 127.0.0.1    TLSv1.2 220 Application Data
   24 0.255799639    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=8112 Ack=2685 Win=179840 Len=0 TSval=1944383197 TSecr=1944383197
   25 2.312629664    127.0.0.1 → 127.0.0.1    TLSv1.2 535 Application Data
   26 2.312809015    127.0.0.1 → 127.0.0.1    TLSv1.2 97 Encrypted Alert
   27 2.312821190    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=8581 Ack=2716 Win=179840 Len=0 TSval=1944385254 TSecr=1944385254
   28 2.313444679    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [FIN, ACK] Seq=2716 Ack=8581 Win=444800 Len=0 TSval=1944385255 TSecr=1944385254
   29 2.356079624    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [ACK] Seq=8581 Ack=2717 Win=179840 Len=0 TSval=1944385297 TSecr=1944385255
   30 2.357676736    127.0.0.1 → 127.0.0.1    TCP 66 8081 → 51196 [FIN, ACK] Seq=8581 Ack=2717 Win=179840 Len=0 TSval=1944385299 TSecr=1944385255
   31 2.357690888    127.0.0.1 → 127.0.0.1    TCP 66 51196 → 8081 [ACK] Seq=2717 Ack=8582 Win=444800 Len=0 TSval=1944385299 TSecr=1944385299

筛选我本地证书的特殊CN,我可以在两个转储文件中找到它:

$ for file in {firefox,curl}_request.pcapng;do tshark -r "$file" -Y "tcp contains FOOBAR";done
   18 0.118830308    127.0.0.1 → 127.0.0.1    TCP 3613 51254 → 8081 [PSH, ACK] Seq=567 Ack=8061 Win=464896 Len=3547 TSval=1945282715 TSecr=1945282706 [TCP segment of a reassembled PDU]
   20 0.208331980    127.0.0.1 → 127.0.0.1    TLSv1.2 2066 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message

然而,仅对于curl,它被检测为TLS握手的一部分。
$ for file in {firefox,curl}_request.pcapng;do tshark -r "$file" -Y "ssl contains FOOBAR";done
   20 0.208331980    127.0.0.1 → 127.0.0.1    TLSv1.2 2066 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message

Firefox(成功)和Curl(失败)的身份验证有何不同?
4个回答

7
服务器在其CertificateRequest消息中包含了可接受的证书颁发机构列表。然后,客户端应该发送符合这些标准的证书链。
基于您的客户端证书在Firefox的“TCP分段的重组PDU”中被包含的事实,我猜它还包括中间证书颁发机构以完成认证路径。这样会使握手消息变大,无法适应单个TLS记录(或TCP分段)。
使用cURL时,您可能没有包括这个中间证书,导致客户端向服务器发送较小的Certificate消息,适合于单个TLS记录。这将导致Wireshark显示ssl contains YOUR_CN。(这个显示问题的原因实际上是Wireshark缺少一个功能,即在不同TLS记录之间重新组装握手消息bug 3303。)
为了解决这个问题,您可以尝试将中间CA追加到本地客户端证书中。
(我可能错了,但这是我根据文本跟踪能想到的一个可能原因。)

要解决这个问题,你可以尝试将中间证书颁发机构附加到你的本地客户端证书上。谢谢!我已经寻找了好几天,找到一个甚至记录了cURL如何发送客户端证书链的地方。 - undefined

3

感谢Lekensteyn,你说得对,问题在于CA中间证书。 查看Firefox的证书、客户端密钥交换部分,它添加了Comodo的另一个中间CA,我不知道它从哪里得到。

然而,将这两个证书合并为一个文件并没有帮助curl,添加2个--cert也没有帮助。但是--cacert起作用了,这很有趣,因为--cacert实际上是用于设置要在客户端上检查服务器证书的CA证书。


在cURL 7.79版本中,实际上可以将客户端证书的中间证书添加到同一个文件中,但在早期版本(例如7.29),cURL只会在caFILE(--cacert参数的参数)或(可能)系统CA存储中找到的中间证书中完成客户端证书链。这些中间证书应该只包含根证书,所以确实很“有趣”。 - undefined

2

Firefox和curl的Wireshark跟踪并排显示

在这些跟踪中,你可以看到Firefox发送了2个证书,而curl只发送了一个证书。

问题是,这种发送CA证书的常见方法在哪里有记录呢?因为TLS没有描述这一点。为什么Firefox会这样做,它如何知道在总共4个证书链中只发送一个中间证书直到根证书?


0
旧版本的cURL会在“CA证书列表”中寻找客户端证书的中间证书,这至少是出乎意料的。如果找不到中间证书,您的TLS连接将因为错误的证书警报而中断。
在我的情况下,使用cURL 7.29,我必须为服务器实体证书提供CA证书,并为客户端证书提供中间证书,都在同一个文件中(作为--cacert的参数),因为它们都不在系统的CA存储中。
使用cURL 7.79,我可以将客户端中间证书放在提供给--cert的文件中,这对我来说更有意义。不,我没有选择版本的权利,我必须使用能够访问多个服务器的(多台)机器上安装的版本。
(这是在使用单独的X509证书时。如果您的cURL接受PKCS12文件,可能早期就可以工作。也有可能实际上是加密后端及其版本造成了差异。在我的情况下,NSS/3.36 [在caFILE中查找]与OpenSSL/1.1.1q [在客户端证书中查找])。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接