英文:
SSL ("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",)
问题
I see you're experiencing an SSL error after updating from Sectigo RSA to Let's Encrypt on your Ubuntu 16.04 server. It appears to be a certificate verification issue. Here's a rough translation of the issue and your server configuration:
错误描述:在将 SSL 从 Sectigo RSA 更新为 Let's Encrypt 后,出现 SSL 错误,似乎是证书验证问题。
nginx 配置如下:
-
You have a redirect for
x.com
tohttps://x.com
, but the SSL settings are missing inside that server block. You should include SSL settings there.你在将
x.com
重定向到https://x.com
,但是在该服务器块内缺少 SSL 设置。你应该在那里包括 SSL 设置。 -
There is a server block for
listen 443 ssl
, but it seems to be commented out with#
at the beginning of each line. You need to uncomment these lines to enable SSL on this server block.有一个服务器块为
listen 443 ssl
,但似乎在每行开头以#
注释掉了。你需要取消注释这些行以在该服务器块上启用 SSL。 -
Make sure that the SSL certificate paths in your nginx configuration match the paths where Let's Encrypt stores the SSL certificates (
/etc/letsencrypt/live/x.com/
).确保你的 nginx 配置中的 SSL 证书路径与 Let's Encrypt 存储 SSL 证书的路径匹配(
/etc/letsencrypt/live/x.com/
)。
After making these adjustments, don't forget to reload or restart nginx for the changes to take effect:
在进行这些调整后,不要忘记重新加载或重新启动 nginx 以使更改生效:
sudo service nginx reload
This should help resolve the SSL handshake error you're encountering.
英文:
So I have an old Ubuntu 16.04 server and I've recently installed let'sencrypt SSL. Before I used to use an SSL from Sectigo RSA and it worked perfectly but after I updated it to let's encrypt it's showing this error:
SSLError at /layers/geonode:test
("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",)
Request Method: GET
Request URL: https://x.com/layers/geonode:test
Django Version: 1.8.7
Exception Type: SSLError
Exception Value:
("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",)
Exception Location: /usr/local/lib/python2.7/dist-packages/requests/adapters.py in send, line 497
Python Executable: /usr/bin/uwsgi-core
Python Version: 2.7.12
Python Path:
['.',
'',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-x86_64-linux-gnu',
'/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/root/.local/lib/python2.7/site-packages',
'/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages',
'/var/www/x/x']
Server time: Fri, 4 Aug 2023 19:30:56 +0600
I've tried updating the root ca-certificates with sudo apt install ca-certificates
but it says:
ca-certificates is already the newest version (20210119~16.04.1).
0 upgraded, 0 newly installed, 0 to remove and 392 not upgraded.
And here's how my nginx configuration looks like:
server {
server_name x.com;
return 301 $scheme://x.com$request_uri;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/x.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/x.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = x.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name x.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
server_name x.com;
# include snippets/x-signed.conf;
# include snippets/ssl-params.conf;
ssl_certificate /etc/letsencrypt/live/x.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/x.com/privkey.pem; # managed by Certbot
charset utf-8;
access_log /var/log/nginx/x.access.log;
error_log /var/log/nginx/x.error.log info;
# sit2605
client_max_body_size 1600M;
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
# NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
# With php5-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# With php5-fpm
fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
include fastcgi_params;
# Increasing timeout
fastcgi_read_timeout 600;
}
location / {
root /var/www/uploads;
try_files $uri @wsgiapp;
}
location @wsgiapp {
uwsgi_read_timeout 10800;
uwsgi_pass unix:///var/lib/uwsgisock/x.sock;
include /etc/nginx/uwsgi_params;
}
location /geoserver/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://x.x.x.x:8080/geoserver/;
}
}
server {
if ($host = x.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name x.com;
listen 80;
return 404; # managed by Certbot
}
Any idea on how to fix it?
答案1
得分: 1
你可能在使用已过期的CA证书,这些证书来自OpenSSL博客:
当新证书发行时,推荐的证书链,供Let's Encrypt ACME客户端使用,包含一个由过期的DST Root CA X3证书签名的中间证书(ISRG Root X1),该证书在2021年09月30日到期。在某些情况下,OpenSSL 1.0.2版本会将由Let's Encrypt CA签发的证书视为具有过期的信任链。
它链接到另一篇博客文章,在lets-encrypt上解释了这个问题以及如何处理它。以下是他们的建议(强调是我的):
你应该做什么?对于大多数人来说,什么都不需要做!我们已经设置了证书签发,以便在大多数情况下,您的网站会自动处理,以支持广泛的兼容性。如果您提供API或必须支持物联网设备,您需要确保两件事:(1)您API的所有客户端必须信任ISRG Root X1(而不仅仅是DST Root CA X3),(2)如果您API的客户端使用OpenSSL,它们必须使用1.1.0或更高版本。在OpenSSL 1.0.x中,证书验证中的一个怪癖意味着即使客户端信任ISRG Root X1,当使用我们默认推荐的与Android兼容的证书链时,它们也会失败。
您应该检查您的OpenSSL版本,Ubuntu 16上可能已经过时,需要升级,可以参考这个SO答案来进行操作。
英文:
Your probably using old CA certificates which were expired, from openssl blog:
>The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.
It links to another blog post, on lets-encrypt that explains this problem and how to handle it. Here's what they recommend (emphasis are mine):
>What should you do? For most people, nothing at all! We’ve set up our certificate issuance so your web site will do the right thing in most cases, favoring broad compatibility. If you provide an API or have to support IoT devices, you’ll need to make sure of two things: (1) all clients of your API must trust ISRG Root X1 (not just DST Root CA X3), and (2) if clients of your API are using OpenSSL, they must use version 1.1.0 or later. In OpenSSL 1.0.x, a quirk in certificate verification means that even clients that trust ISRG Root X1 will fail when presented with the Android-compatible certificate chain we are recommending by default.
You should check your openssl version, which is probably outdated on Ubuntu 16 and upgrade it, check this SO answer for how to do it.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论