Disable only Hostname verification of proxied HTTPS server certificate
Is there any way where we can configure nginx to only verify the root of the proxied HTTPS server (upstream server) certificate and to skip the host name (or domain name) verification? As I understand, proxy_ssl_verify directive can be used to completely enable/disable the verification of proxied HTTPS server certificate but not selectively. Is there any directive to only disable the host name verification? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,286129,286129#msg-286129 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Verification of proxied HTTPS server certificate
Hi, According to the documentation (http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_verify) the directive "proxy_ssl_verify" is used to enable or disabled the verification of the proxied HTTPS server certificate. But it doesn't talk about what all different types of validations (like Host Name Verification, Certificate Expiry etc) it does. Could someone list out the validations Nginx performs on the obtained server certificate from the upstream server when the above said directive is set to "on"? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,285683,285683#msg-285683 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: RE: Idle Timeout during the HTTP request response phase
Thanks for the pointers. For backend/upstream servers does they translate to the below two directives For read : proxy_read_timeout For send: proxy_send_timeout Please correct me if I am wrong Posted at Nginx Forum: https://forum.nginx.org/read.php?2,281614,281618#msg-281618 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Idle Timeout during the HTTP request response phase
Hi, Is there any directive available in Nginx to set a timeout between two successive receive or two successive send network input/output operations during the HTTP request response phase? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,281614,281614#msg-281614 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
SSL Handshake Failure with error:1407609B:SSL in error logs
Hi,
We are trying to configure TCP load balancing with TLS termination. But when
we try to access the URL, we could see the below error in the nginx error
and access logs
Nginx Error Log:
2018/07/04 07:16:45 [crit] 7944#0: *61 SSL_do_handshake() failed (SSL:
error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request)
while SSL handshaking, client: XX.XXX.XX.XX, server: 0.0.0.0:443
Nginx Access Log:
10.90.241.125 - - [04/Jul/2018:07:24:55 +] TCP 500 0 0 0.000 "-"
The nginx.conf file looks like this
stream {
log_format sample '$remote_addr - - [$time_local] $protocol $status
$bytes_sent $bytes_received $session_time "$upstream_addr"';
upstream backends {
server sample-domain-name.com:443;
}
server {
listen 443 ssl;
access_log /etc/access_logs/tcp_access_log sample;
ssl_certificate Certificate_PATH;
ssl_certificate_key Private_Key_Path;
proxy_ssl off;
proxy_pass backends;
}
}
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,280396,280396#msg-280396
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Make nginx ignore unresolvable upstream server host names during reload or boot up
Hi,
I have multiple upstream servers configured in an upstream block in my nginx
configuration.
upstream example2 {
server example2.service.example.com:8001;
server example1.service.example.com:8002;
}
server {
listen 80;
server_name example2.com;
location / {
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://example2/;
}
}
When i try to reload Nginx and at that time if one of my upstream servers
(say example2.service.example.com) is not DNS resolvable, then the reload
fails with an error "host not found in upstream".
Is there any way we can ask nginx to ignore such unresolvable host names or
rather configure Nginx to resolve these upstream server host names at run
time instead of resolving it during the boot up or reload process?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,278972,278972#msg-278972
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Make nginx ignore unresolvable upstream server host names during reload or boot up
Hi,
I have multiple upstream servers configured in an upstream block in my nginx
configuration.
upstream example2 {
server example2.service.example.com:8001;
server example1.service.example.com:8002;
}
server {
listen 80;
server_name example2.com;
location / {
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://example2/;
}
}
When i try to reload Nginx and at that time if one of my upstream servers
(say example2.service.example.com) is not DNS resolvable, then the reload
fails with an error "host not found in upstream".
Is there any way we can ask nginx to ignore such unresolvable host names or
rather configure Nginx to resolve these upstream server host names at run
time instead of resolving it during the boot up or reload process?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,278968,278968#msg-278968
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Upgrading Nginx executable on the fly
Hi, We have been trying to upgrade the Nginx binary on the fly by invoking USR2 signal to spawn a new set of master and worker processes with the new configuration. The question I have is when this new master process is spawned, after issuing USR2 signal to the existing or the old master process, what would be it's parent process? Will it be the root process (1) or the old master process? We have been seeing different case of this. In some cases we have seen the new master process' PPID is 1, whereas in other cases its PPID is that of the old master process. Could someone please explain this scenario in detail. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,278038,278038#msg-278038 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx reload intermittenlty fails when protocol specified in proxy_pass directive is specified as HTTPS
Just one quick question. Does Nginx check if the upstream servers are reachable via the specified protocol, during the reload process? If say, in this case the upstreams are not accepting ssl connections, will the reload fail? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,277399,277418#msg-277418 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Nginx reload intermittenlty fails when protocol specified in proxy_pass directive is specified as HTTPS
I am trying to use nginx as a reverse proxy with upstream SSL. For this, I
am using the below directive in the nginx configuration file
proxy_pass https://;
where "" is another file which has the list of
upstream servers.
upstream {
server : weight=1;
keepalive 100;
}
With this configuration if I try to reload the Nginx configuration, it fails
intermittently with the below error message
nginx: [emerg] host not found in upstream \"\"
However, if I changed the protocol mentioned in the proxy_pass directive
from https to http, then the reload goes through.
Could anyone please explain what mistake I might be doing here?
Thanks in advance.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,277415,277415#msg-277415
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Nginx reload intermittenlty fails when protocol specified in proxy_pass directive is specified as HTTPS
I am trying to use nginx as a reverse proxy with upstream SSL. For this, I
am using the below directive in the nginx configuration file
proxy_pass https://;
where "" is another file which has the list of
upstream servers.
upstream {
server
: weight=1;
keepalive 100;
}
With this configuration if I try to reload the Nginx configuration, it fails
intermittently with the below error message
nginx: [emerg] host not found in upstream \"\"
However, if I changed the protocol mentioned in the proxy_pass directive
from https to http, then the reload goes through.
Could anyone please explain what mistake I might be doing here?
Thanks in advance.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,277399,277399#msg-277399
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx PID file missing
Hi, In one of the environment, we never tried to stop nginx. We see that the nginx master process and worker processes are running, but the pid file goes missing all of a sudden. How can we explain that? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,274425,274427#msg-274427 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Nginx PID file missing
Hi, In our environments we are intermittently facing an issue where the nginx.pid file goes missing, due to which whenever we try to do a reload of nginx, it fails saying "no pid file exists". Is there any known scenarios due to which the nginx.pid file goes missing? Does the nginx reload has any effect on the pid file? Ideally it should not, isn't ? Also, what we have noticed is, sometimes whenever we tried to do a restart of nginx, i.e quit nginx and then start it again, at times, the nginx master and worker processes start but there is no pidfile written by nginx at the expected location? Could anyone help on this issue? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,274425,274425#msg-274425 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Reload of NGinX doesnt kill some of the older worker processes
Earlier, it says the pid file doesn't exist even though the master and worker processes were running. 2017/05/12 15:35:41 [notice] 19042#0: signal process started 2017/05/12 15:35:41 [error] 19042#0: open() "/u01/data/logs/nginx.pid" failed (2: No such file or directory) Can the above issue ( where the nginx.pid file went missing) and the communication break up between the master and the worker processes be correlated? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,274213,274233#msg-274233 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Reload of NGinX doesnt kill some of the older worker processes
At times, the error logs say 2017/05/15 11:37:01 [notice] 9#0: signal process started 2017/05/15 11:37:02 [alert] 22030#0: sendmsg() failed (32: Broken pipe) 2017/05/15 11:37:02 [alert] 22030#0: sendmsg() failed (32: Broken pipe) 2017/05/15 11:37:04 [alert] 22030#0: sendmsg() failed (9: Bad file descriptor) 2017/05/15 11:37:04 [alert] 22030#0: sendmsg() failed (32: Broken pipe) 2017/05/15 11:37:04 [alert] 22030#0: sendmsg() failed (9: Bad file descriptor) 2017/05/15 11:37:04 [alert] 22030#0: sendmsg() failed (32: Broken pipe) Posted at Nginx Forum: https://forum.nginx.org/read.php?2,274213,274230#msg-274230 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Reload of NGinX doesnt kill some of the older worker processes
Hi Maxim, This is what I could find in the error logs 2017/05/15 11:32:18 [notice] 21499#0: signal process started 2017/05/15 11:32:19 [alert] 22030#0: sendmsg() failed (88: Socket operation on non-socket) 2017/05/15 11:32:19 [alert] 22030#0: sendmsg() failed (32: Broken pipe) 2017/05/15 11:32:19 [alert] 22030#0: sendmsg() failed (88: Socket operation on non-socket) 2017/05/15 11:32:19 [alert] 22030#0: sendmsg() failed (32: Broken pipe) 2017/05/15 11:32:20 [alert] 22030#0: sendmsg() failed (88: Socket operation on non-socket) 2017/05/15 11:32:20 [alert] 22030#0: sendmsg() failed (32: Broken pipe) 2017/05/15 11:32:20 [alert] 22030#0: sendmsg() failed (88: Socket operation on non-socket) 2017/05/15 11:32:20 [alert] 22030#0: sendmsg() failed (32: Broken pipe) Posted at Nginx Forum: https://forum.nginx.org/read.php?2,274213,274229#msg-274229 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Reload of NGinX doesnt kill some of the older worker processes
I am facing an issue where once I issued a reload to the NGinX binary, few of the older worker processes are not dying. They still remain orphaned. This is the configuration before issuing a reload : [poduser@ucfc2z3a-1582-lb8-nginx1 logs]$ ps -ef | grep nginx poduser 12540 22030 0 06:39 ?00:00:00 nginx: worker process poduser 12541 22030 0 06:39 ?00:00:00 nginx: worker process poduser 12762 11601 0 06:41 pts/000:00:00 grep nginx poduser 22030 1 1 May12 ?00:49:01 nginx: master process /u01/app/Oracle_Nginx/sbin/nginx poduser 23528 22030 0 May12 ?00:00:22 nginx: worker process poduser 24950 22030 0 May12 ?00:00:22 nginx: worker process Configuration after issuing a relaod [poduser@ucfc2z3a-1582-lb8-nginx1 logs]$ ps -ef | grep nginx poduser 13280 22030 2 06:45 ?00:00:00 nginx: worker process poduser 13281 22030 2 06:45 ?00:00:00 nginx: worker process poduser 13323 11601 0 06:45 pts/000:00:00 grep nginx poduser 22030 1 1 May12 ?00:49:02 nginx: master process /u01/app/Oracle_Nginx/sbin/nginx poduser 23528 22030 0 May12 ?00:00:22 nginx: worker process poduser 24950 22030 0 May12 ?00:00:22 nginx: worker process If you notice, there are two worker processes orphaned with PID's 23528 and 24950. Could someone please explain the cause for this, as to why few of the worker processes are orphaned? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,274213,274213#msg-274213 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Return Specific Error Page in NGinX when all the upstream servers are marked down
I have an upstream block as follows
upstream sample{
server abc1.example.com down;
server abd2.example.com down;
}
Currently I get a 502 error. In this special case where I receive a 502 and
all upstream servers are down I would like a receive a specific error page
as temporarily unavailable.
How can i achieve that?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,274075,274075#msg-274075
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Nginx reload process in detail
We have a persistent connection to Nginx on which we are issuing https requests. Now when we do a reload, the persistent connections (the requests which are already accepted) are failing as soon as the reload was issued. Those connections are being dropped. Is this the expected behavior? In the Nginx documentation, it was mentioned that the older worker process would continue to run untile they have served the accepted inflight requests and then would go down. But the actual behavior seems to be different as the persistent connections are being dropped as soon as a configuration reload was issued. To add to the above question, while reload was in progress, i am trying to establish a new connection and its not being established. Can't the new worker processes which were spawned as a result of configuration reload, straight away serve the incoming new connections? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,273904,273904#msg-273904 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx upstream server certificate verification
Thank Sergey, for you response. I have one more question. If I have multiple upstream server host names in the upstream server block, then how can I specify the specific upstream server host name to which the request is being proxied, in the proxy_ssl_name directive? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,273295,273462#msg-273462 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Nginx upstream server certificate verification
Thank Sergey, for you response. I have one more question. If I have multiple upstream server host names in the upstream server block, then how can I specify the specific upstream server host name to which the request is being proxied, in the proxy_ssl_name directive? Posted at Nginx Forum: https://forum.nginx.org/read.php?2,273295,273355#msg-273355 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Nginx upstream server certificate verification
I am trying to implement HTTPS protocol communication at every layer of a
proxying path. My proxying path is from client to load balancer (nginx) and
then from nginx to the upstream server.
I am facing a problem when the request is proxied from nginx to the upstream
server.
I am getting the following error in the nginx logs
2017/03/26 19:08:39 [error] 76753#0: *140 upstream SSL certificate does not
match "8ba0c0da44ee43ea894987ab01cf4fbc" while SSL handshaking to upstream,
client: 10.191.200.230, server:
abc.uscom-central-1.ssenv.opcdev2.oraclecorp.com, request: "GET /a/a.html
HTTP/1.1", upstream: "https://10.240.81.28:8001/a/a.html;, host:
"abc.uscom-central-1.ssenv.opcdev2.oraclecorp.com:10003"
This is my configuration for the upstream server block
upstream 8ba0c0da44ee43ea894987ab01cf4fbc {
server slc01etc.us.oracle.com:8001 weight=1;
keepalive 100;
}
proxy_pass https://8ba0c0da44ee43ea894987ab01cf4fbc;
proxy_set_header Host $host:10003;
proxy_set_header WL-Proxy-SSL true;
proxy_set_header IS_SSL ssl;
proxy_ssl_trusted_certificate
/u01/data/secure_artifacts/ssl/trusted_certs/trusted-cert.pem;
proxy_ssl_verify on;proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
When the request goes from Nginx to the upstream server, nginx matches the
upstream ssl certificate against the pattern present in the proxy_pass
directive. But my upstream ssl certificate pattern is the upstream server
hostname (slc01etc.us.oracle.com) .
Is there any way, where I can force Nginx to verify the upstream ssl
certificate against the server hostnames provided in the upstream server
block, instead of the pattern present in the proxy_pass directive?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,273295,273295#msg-273295
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
