我有一个自定义的easyrsa安装程序，它有一个根和三个由root签名的CA。 （根据用户types，三个不同的子卡），如下所示： RootCA +—– AdminUserCA +—– EmployeeCA +—– ClientCA 我有身份validation使用以下configuration： server { listen 127.0.0.1:443; server_name www.acme.corp; ssl on; ssl_certificate /data/src/easy-rsa/bundles/www.acme.corp_bundle.crt; ssl_certificate_key /data/src/easy-rsa/whfWebCA/pki/private/www.acme.corp.key; add_header Strict-Transport-Security "max-age=315360000; includeSubdomains"; ssl_protocols SSLv3 TLSv1; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA; ssl_prefer_server_ciphers on; ssl_verify_client optional; ssl_client_certificate /data/src/easy-rsa/bundles/client_auth_ca_chain.crt; ssl_verify_depth 2; ssl_crl /data/src/easy-rsa/bundles/crls/all.pem; … } 问题在于CRL检查。 CRL由签发CA签字，因此不能像中间证书+根证书一样join。 因此，用户的证书将由给定的中间CA根据他们的用户types来发布。 问题是我真的需要检查四个CRL列表才能生效。 nginx ssl_crl只支持一个文件。 所以我的问题是：是否有可能让nginx正确检查客户端证书在这个安装程序，而不必在我的应用程序进行检查？
我试图用命令sudo nginx在我的Mac OS X上启动sudo nginx 它失败，并出现以下错误 nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use) nginx: [emerg] bind() to 0.0.0.0:8080 […]
首先，我有什么： OpenSSL 1.0.1e-fips 11 Feb 2013 nginx version: nginx/1.6.2 CentOS Linux release 7.0.1406 (Core) 并为了testing目的，自签名证书： openssl req -x509 -sha256 -newkey rsa:2048 -keyout private_key.pem -out certificate.pem -days 365 openssl rsa -in private_key.pem -out certificate_key.pem openssl dhparam -out dhparam.pem 4096 所以，问题在于 – 当我在浏览器中打开test.example.com时，我得到了ERR_CONNECTION_RESET。 在nginx错误日志中，我看到以下内容： 2015/02/07 03:18:34 [error] 27951#0: *17 no "ssl_certificate" is defined in server listening on […]
我喜欢运行nginx作为本地代理服务器，如果上游服务器不可用，则提供陈旧的caching文件。 这个效果很好，除了本地机器重新启动，而互联网连接故障。 在这种情况下，nginx根本不会启动，说'主机不在上游….'。 我需要在每种情况下启动nginx，否则无法在上游连接失败时提供陈旧的caching。 那么如何让nginx在启动时忽略连接错误呢？
我试图分开机器人访问日志和人类访问日志，所以我使用下面的configuration： http { …. map $http_user_agent $ifbot { default 0; "~*rogerbot" 3; "~*ChinasoSpider" 3; "~*Yahoo" 1; "~*Bot" 1; "~*Spider" 1; "~*archive" 1; "~*search" 1; "~*Yahoo" 1; "~Mediapartners-Google" 1; "~*bingbot" 1; "~*YandexBot" 1; "~*Feedly" 2; "~*Superfeedr" 2; "~*QuiteRSS" 2; "~*g2reader" 2; "~*Digg" 2; "~*trendiction" 3; "~*AhrefsBot" 3; "~*curl" 3; "~*Ruby" 3; "~*Player" 3; "~*Go\ http\ package" […]
我希望Nginx将访问者redirect到我的顶级域名上的HTTPS，但不是为某些子域名（因为我不想麻烦添加子域名到我的证书，而不是必要的）。 似乎发生的事情是Nginxredirect到我的顶级域以及所有子域上的HTTPS，尽pipe我只是明确地将redirect放在顶级域的服务器块中。 下面基本上是我这样做的方式： server { server_name example.com; listen 80; return 301 https://example.com$request_uri; } server { server_name example.com; listen 443 ssl; … } server { server_name nossl.example.com; listen 80; } 当用户访问http://nossl.example.com时 ，他们被迫使用SSL（HTTPS），从而得到关于证书的丑陋警告。 我怎么能这样做呢？
我们在我们的系统前面有Nginx，我们在后面代理Apache。 我们使用SSL / TLS进行连接。 题： 在性能/ SSL握手方面，Nginx是否是终止SSL / TLS连接的最佳select？ 我是否在做所有需要的性能调整？ 我还能改善我的代码吗？ 这是我的configuration： ssl_certificate /path/ssl.crt; ssl_certificate_key /path/ssl.key; ssl_dhparam /path/dh.pem; ssl_buffer_size 4k; ssl_session_timeout 4h; ssl_session_cache shared:SSL:20m; ssl_session_tickets on; ssl_trusted_certificate /path/trust.crt; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s; 我使用Mozilla SSLconfiguration生成器在下面生成我的密码。 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'; ssl_prefer_server_ciphers on; 密码是为了适应大多数的浏览器。 我也有严格的运输安全设置。 我们的系统使用CloudFront在Amazon AWS上运行。 目前需要大约130秒的SSL实验室才能进行testing。 Pingdom显示一个请求的SSL连接需要至less220ms 。 […]
我有一个stream利的服务器，正在处理平均1000请求/秒。 这个服务器由32个cpus组成。 在这台服务器上运行32个相同configuration的fluentd docker容器。 服务器的入口点是一个nginx作为负载均衡器configuration循环algorithm，并将其发送到不同的容器。 容器和nginx都在24224 / tcp上侦听。 这个节点的input是6个使用fluent-logger-csharp发送给Fluentd服务器的C＃应用程序。 所以，对于每个应用程序打开一个连接到Fluentd服务器，并由于stream量大，应用程序保持打开套接字。 这会导致只有6个docker正在处理请求。 如何在不修改C＃客户端的情况下更好地使用服务器利用率？
目前，我们通过Apache和Apache客户服务大部分Rails和LAMP应用程序，但是我们正在考虑添加Nginx或Varnish作为反向代理来减less服务器的负载。 我知道你可以一起使用Varnish和Nginx，但是鉴于在学习两者如何工作方面有时间投入，并且尽可能地保持尽可能低的基础设施中“移动部分”的数量，试图找出使用之间的优点和缺点： nginx本身就是一个反向的反向代理/caching 作为反向代理/caching单独的清漆 nginx和清漆一起 据我所知，nginx速度非常快，而且随着HTTP服务器越来越stream行，它越来越受到人们的关注，所以我可以看到有一段时间来学习这个服务器的工作原理，但是Varnish仍然是一个未知的我。 如果nCache现在在Nginx中，为什么要使用Varnish？ 谢谢
在apache2中，我可以通过执行apache2ctl -S来查看所有活动的虚拟主机。 这是有用的，因为我不需要通过configuration文件，也如果我已经对configuration文件进行了更改，但尚未重新启动apache2。 在nginx中是否有等价的函数？