Linux中使用curl命令访问https站点4种常见错误和解决方法

文章来源:http://www.jb51.net/LINUXjishu/287588.html


这篇文章主要介绍了Linux中使用curl命令访问https站点常见的4种错误和解决方法,本文列举的都是一些常见报错信息,,需要的朋友可以参考下


每一种客户端在处理https的连接时都会使用不同的证书库。IE浏览器和FireFox浏览器都可以在本浏览器的控制面板中找到证书管理器。在证书管理器中可以自由添加、删除根证书。

而Linux的curl使用的证书库在文件“/etc/pki/tls/certs/ca-bundle.crt”中。(CentOS)

以下是curl在访问https站点时常见的报错信息

1.Peer’s Certificate issuer is not recognized


复制代码
代码如下:

[root@ip-172-31-32-208 Nginx]# curl https://m.ipcpu.com
curl: (60) Peer's Certificate issuer is not recognized.
more details here: http://curl.haxx.se/docs/sslcerts.html

此种情况多发生在自签名的证书,报错含义是签发证书机构未经认证,无法识别。

解决办法是将签发该证书的私有CA公钥cacert.pem文件内容,追加到/etc/pki/tls/certs/ca-bundle.crt。

我们在访问12306.cn订票网站时也报了类似的错误。

复制代码
代码如下:

[root@ip-172-31-32-208 ~]# curl https://kyfw.12306.cn/
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html

2.SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed


复制代码
代码如下:

[root@GO-EMAIL-1 aa]# curl https://github.com/
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

此问题多是由于本地CA证书库过旧,导致新签发证书无法识别。

经排查,github.com证书是由GTE CyberTrust Root签发,现行证书时间是:

1.不早于(1998/8/13 0:29:00 GMT)
2.不晚于(2018/8/13 23:59:00 GMT)

而在我们的Redhat5.3系统中ca-bundle.crt文件发现,GTE CyberTrust Root的时间已经过期。

复制代码
代码如下:

Issuer: C=US, O=GTE Corporation, CN=GTE CyberTrust Root
Validity
Not Before: Feb 23 23:01:00 1996 GMT
Not After : Feb 23 23:59:00 2006 GMT

解决办法是更新本地CA证书库。

方法一:

下载http://curl.haxx.se/ca/cacert.pem 替换/etc/pki/tls/certs/ca-bundle.crt

方法二:

使用update-ca-trust 更新CA证书库。(CentOS6,属于ca-certificates包)

3.unknown message digest algorithm


复制代码
代码如下:

[root@WEB_YF_2.7 ~]#curl https://www.alipay.com
curl: (35) error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm

此问题多由证书本地openssl不能识别SSL证书签名算法所致。www.alipay.com 使用了SHA-256 RSA 加密算法。而openssl在OpenSSL 0.9.8o才加入此算法。

解决办法是升级本地openssl。

在我的操作系统RedHat5.3中,yum 升级openssl到openssl-0.9.8e-22.el5 就可以识别SHA-256算法。原因是Redhat每次都是给0.9.8e打补丁,而不是直接更换版本。在srpm包中我找到了这个补丁。

复制代码
代码如下:

Summary: The OpenSSL toolkit
Name: openssl
Version: 0.9.8e
...
Patch89: openssl-fips-0.9.8e-ssl-sha256.patch

4.JAVA和PHP的问题

java和php都可以编程来访问https网站。例如httpclient等。

其调用的CA根证书库并不和操作系统一致。

JAVA的CA根证书库是在 JRE的$JAVA_HOME/jre/lib/security/cacerts,该文件会随着JRE版本的升级而升级。可以使用keytool工具进行管理。

PHP这边我没有进行测试,从php安装curl组件的过程来看,极有可能就是直接采用的操作系统curl一直的数据。

当然PHP也提供了 curl.cainfo 参数(php.ini)来指定CA根证书库的位置。




### Linuxcurl 命令因网络问题导致的拒绝连接错误解决方案 当在 Linux 系统中执行 `curl` 命令时遇到 “curl: (7) Failed to connect...” 错误,通常表示目标服务器无法访问或本地配置存在问题。以下是可能的原因及对应的解决方法: #### 1. 检查目标服务是否正常运行 确认目标 IP 地址端口号的服务状态。可以通过以下方式验证: - 使用 `ping` 测试主机连通性: ```bash ping 192.168.100.100 ``` - 使用 `telnet` 或 `nc` 测试指定端口是否开放: ```bash telnet 192.168.100.100 1666 # 或者 nc -zv 192.168.100.100 1666 ``` 如果上述命令显示超时或不可达,则可能是目标服务未启动或防火墙阻止了该端口。 --- #### 2. 防火墙或安全组设置 检查是否有防火墙规则或云平台的安全组策略阻断了请求: - 对于本地防火墙,可以临时关闭以测试效果: ```bash sudo systemctl stop firewalld ``` - 如果使用的是 Docker 容器环境,需确保容器能够访问宿主机或其他外部资源[^1]。 --- #### 3. DNS 解析问题 如果目标地址是一个域名而非 IP 地址,DNS 可能未能正确解析。尝试通过 `-4` 参数强制 IPv4 连接来排除此可能性: ```bash curl -4 http://raw.githubusercontent.com:443/ ``` 或者手动指定 IP 地址替代域名进行测试。 --- #### 4. 代理配置冲突 某些情况下,系统全局设置了 HTTP/HTTPS 代理,而目标站点不需要代理支持。这可能导致连接被重定向到错误位置并最终失败。清除当前会话中的代理变量即可解决问题: ```bash unset http_proxy https_proxy all_proxy ``` 对于需要持久化更改的情况,在 `/etc/environment` 文件中移除相关条目或将它们置为空字符串。 另外需要注意的是,若确实存在合法的企业内部网关,则应按照文档说明正确填写认证信息[^4]: ```bash export http_proxy=http://%40username:%40password@proxy.example.com:8080 export https_proxy=$http_proxy ``` > 特殊字符如 "@" 必须替换为其 URL 编码形式 "%40" 才不会引起语法误解。 --- #### 5. SELinux AppArmor 的影响 SELinux/AppArmor 是增强型操作系统保护机制,默认可能会限制应用程序对外部网络发起调用的行为。调整其工作模式至宽容(permissive),有助于诊断此类异常现象是否存在关联因素。 ```bash setenforce 0 # 切换 selinux 至 permissive mode aa-status # 查看 apparmor 当前状况 ``` 完成排查后再恢复默认严格(enforcing)设定以免留下安全隐患。 --- #### 6. 超时时间过短 有时由于链路质量较差造成握手过程耗时较长从而触发客户端提前中断操作的现象也很常见。适当延长 timeout 时间参数或许有所帮助: ```bash curl --connect-timeout 10 ... ``` 以上列举了几种常见的引发 "connection refused" 类报错的情形及其对应处置办法。具体实施还需依据实际场景灵活运用。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值