服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

“SSL_ERROR_INTERNAL_ERROR_ALERT”使用Let's Encrypt&Nginx

我一直在运行我的Nginx Web服务器近一个星期,突然之间,它开始抛出这个错误(只使用HTTPS)并redirect到/defaultsite当使用HTTP。 网站链接是https://leakkiller.com ,如果你想看看自己发生了什么。 我已经尝试清除浏览器caching。 我的doamin注册商是1&1(我生命中最大的错误),但我使用数字海洋的VPS,所以我路由我的DNS通过他们。 下面你可以find我的服务器块为Nginx。 server { listen 80 default_server; listen [::]:80 default_server; server_name leakkiller.com www.leakkiller.com; return 301 https://$host$request_uri; } server { listen 443 ssl; listen [::]:80 ssl ipv6only=on; ssl_certificate /etc/letsencrypt/live/leakkiller.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/leakkiller.com/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security […]

Ubuntu 16.04,PHP-FPM在使用libsodium-php模块启动时超时

问题(修改:用REPRO步骤!) 重新制作一个新的VPS与Ubuntu 16.04(可能适用于任何Debian发行版,但没有testing),并按照这些指示: 通过实验,我将指令简化为绝对最低限度的重现 apt-get install php7.0 php7.0-dev php-pear apt-get install libsodium-dev pecl install libsodium echo "extension=libsodium.so" >> /etc/php/7.0/fpm/php.ini shutdown -r 0 当我重新启动服务器( shutdown -r 0 )PHP-FPM死了(通过service php7.0-fpm status确认) 如果我运行service php7.0-fpm start ,它启动毫秒service php7.0-fpm start 。 我在libsodium-php跟踪器上创build了一个问题,希望有人能find解决方法: https : //github.com/jedisct1/libsodium-php/issues/94 问题 现在我已经缩小了这个问题,我真正想要的是: 一个方法来弄清楚为什么它是超时(是否有一个好的方法来configuration什么资源被访问或什么是启动时间过程?) 一种方法来解决它(有没有办法改变引导顺序,以便libsodium引导最后,以防万一它的依赖性问题?) 新的更新 我一直在研究这个,并发现所有的PHP在libsodium库的初始化过程中都会停顿(对sodium_init()的调用)。 这个调用大概需要3-4分钟才能完成,直到这个时间过去了,甚至一个调用php -v失败。 作为解决方法,我已经将以下内容添加到/lib/systemd/system/php7.0-fpm.service : TimeoutStartSec=600 这会导致我的Web服务器在重新启动后返回HTTP状态码502几分钟,但最终会再次开始工作(比手动login和修复更好) 我将尝试与libsodium和libsodium-php的开发人员联系,以find更好的解决scheme,但现在我相信我已经解决了这个问题: 解决scheme 当启动时没有运行某个东西时,开始使用journalctl […]