centos 6 https，centos7点几哪个版本好用
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
curl:(60) Peer's Certificate issuer is not recognized.
more details here:
此种情况多发生在自签名的证书，报错含义是签发证书机构未经认证，无法识别。
解决办法是将签发该证书的私有CA公钥cacert.pem文件内容，追加到/etc/pki/tls/certs/ca-bundle.crt。
我们在访问12306.cn订票网站时也报了类似的错误。
复制代码代码如下:
[root@ip-172-31-32-208~]# curl
curl:(60) Peer's certificate issuer has been marked as not trusted by the user.
More details here:
2.SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
复制代码代码如下:
[root@GO-EMAIL-1 aa]# curl
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:
此问题多是由于本地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证书库。
方法一：
下载替换/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
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根证书库的位置。
centos无法从extensions.gnome.org下载更新,怎么办
问题现象：刚安装好的CentOS 8使用GNOME软件来更新时出现问题，不能更新下载。
问题分析：初步分析是原系统下载源被和谐或者是下载速度过慢的原因。
解决办法：查找网上教程，通过将下载源更换为国内yum下载源恢复下载，操作如下：
1.备份现有源
mv/etc/yum.repos.d/etc/yum.repos.d.backup
2.设置新的yum目录
mkdir/etc/yum.repos.d
3.安装wget
yum install-y wget
4.下载配置。此处一定要注意，很多教程都是CentOS 7的教程，所以贴的CentOS 7的下载源，对于CentOS 8一定要改为CentOS 8的下载源，否则还是不行。
wget-O/etc/yum.repos.d/CentOS-Base.repo
5.清除文件并重建元数据缓存
yum clean all
yum makecache
6.最后更新软件包，稍等软件安装包安装完就可以了
yum update-y
以上内容参考了：Centos8.1 Linux更改yum源
————————————————
版权声明：本文为CSDN博主「PittsAi」的原创文章，遵循 CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：
【UTC】CentOS7修改时区的正确姿势
整个地球分为二十四时区，每个时区都有自己的本地时间。在国际无线电通信场合，为了统一起见，使用一个统一的时间，称为通用协调时(UTC,Universal Time Coordinated)。
格林威治标准时间(Greenwich Mean Time)指位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本初子午线被定义在通过那里的经线。(UTC与GMT时间基本相同，本文中不做区分)
中国标准时间(China Standard Time)【GMT + 8 = UTC + 8 = CST】
夏令时(Daylight Saving Time)指在夏天太阳升起的比较早时，将时钟拨快一小时，以提早日光的使用。（中国不使用）
RTC(Real-Time Clock)或CMOS时钟，一般在主板上靠电池供电，服务器断电后也会继续运行。仅保存日期时间数值，无法保存时区和夏令时设置。
一般在服务器启动时复制RTC时间，之后独立运行，保存了时间、时区和夏令时设置。
在CentOS 6版本，时间设置有date、hwclock命令，从CentOS 7开始，使用了一个新的命令timedatectl。
Centos7修改系统时区timezone ，解决快、慢8小时问题
如果服务器用非 UTC的时间，时区转换很容易不一致，而且对于有 daylight saving的时区，每年多一小时少一小时的那两天，系统就会出现各种诡异现象。
服务器使用UTC时间，如要显示用户所在时区的本地时间，在客户端转化即可。
# timedatectl
我们可以看到，服务器使用的CST时间
# timedatectl set-timezone UTC
# timedatectl set-time"YYYY-MM-DD HH:MM:SS"
# timedatectl set-time "HH:MM:SS"
# timedatectl
我们可以看到，服务器时间类型更改为UTC了
# ll /etc/locatime
lrwxrwxrwx. 1 root root 25 1月 14 08:30 /etc/localtime->../usr/share/zoneinfo/UTC
实际上是做了一个将
文件 /etc/localtime 做了一个软连接到 /usr/share/zoneinfo/UTC
# ln -s /usr/share/zoneinfo/UTC /etc/localtime
ln:无法创建符号链接"/etc/localtime":文件已存在
# ln -sf /usr/share/zoneinfo/UTC /etc/localtime
做软连接时，需要加-f参数，强制覆盖，不然会显示软链接已存在
# timedatectl set-time"YYYY-MM-DD HH:MM:SS"
# timedatectl set-time "HH:MM:SS" //只设置时分秒
# timedatectl
# clock -w
# date -u //显示UTC时间
CentOS7修改时区的正确姿势
CentOS7上运行Java程序，发现程序生成的时间与当前时间匹配不上，还以为是数据停止更新了，后来发现没有正确使用修改时区的姿势，导致程序时区错误。
正确的修改CentOS7时区的姿势：
# ln -sf/usr/share/zoneinfo/Asia/Shanghai /etc/localtime
其他系统的修改文件可能是/var/etc/localtime.
错误的姿势：通过cp命令覆盖/etc/localtime时间
# cp-f /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
通过cp命令修改时区，通过date, data-R命令显示的时区都是正确的，可是对于java程序而言，是错误的。
具体原因在于Java访问系统时区的方式上，可参见文章：
Java TimeZone和 Linux TimeZone问题
该文章很好的说明了Java访问系统时区的方式：
1.如有环境变量 TZ设置，则用TZ中设置的时区
2.在/etc/sysconfig/clock文件中找“ZONE”的值
3.如何2)都没，就用/etc/localtime和/usr/share/zoneinfo下的时区文件进行匹配，如找到匹配的，就返回对应的路径和文件名。
问题在于，如果使用cp命令来修改/etc/localtime文件，那么可能就会导致修改的不是/etc/localtime文件，而是原时区的文件内容。
/etc/localtime是通过符号链接链接/usr/share/zoneinfo下的文件，而java是通过文件名来确认时区的，data命令是通过文件内容确认时区的，这样就导致了data命令时区正确，而java的时区是错误的！
如上图所示：CentOS7是通过符号链接到/usr/share/zoneinfo/下的时区文件的，如果通过cp指令只会修改原时区文件内容，这样，通过date的系统命令，查看时间是OK的，可是java是通过读取文件名的方式确认时区信息的。所以时区还是纽约。
