2019-01-09 15:52:53 -05:00
|
|
|
#!/usr/bin/env bash
|
2015-06-27 04:41:19 -04:00
|
|
|
# Based on
|
|
|
|
|
# https://www.exratione.com/2014/03/running-nginx-as-a-non-root-user/
|
|
|
|
|
# https://github.com/exratione/non-root-nginx/blob/9a77f62e5d5cb9c9026fd62eece76b9514011019/nginx.conf
|
|
|
|
|
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
# USAGE: ./boulder-integration.conf.sh /path/to/root cert.key cert.pem >> nginx.conf
|
|
|
|
|
|
|
|
|
|
ROOT=$1
|
|
|
|
|
CERT_KEY_PATH=$2
|
|
|
|
|
CERT_PATH=$3
|
|
|
|
|
|
2015-06-27 04:41:19 -04:00
|
|
|
cat <<EOF
|
|
|
|
|
# This error log will be written regardless of server scope error_log
|
|
|
|
|
# definitions, so we have to set this here in the main scope.
|
|
|
|
|
#
|
|
|
|
|
# Even doing this, Nginx will still try to create the default error file, and
|
|
|
|
|
# log a non-fatal error when it fails. After that things will work, however.
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
error_log $ROOT/error.log;
|
2015-06-27 04:41:19 -04:00
|
|
|
|
|
|
|
|
# The pidfile will be written to /var/run unless this is set.
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
pid $ROOT/nginx.pid;
|
2015-06-27 04:41:19 -04:00
|
|
|
|
|
|
|
|
worker_processes 1;
|
|
|
|
|
|
|
|
|
|
events {
|
|
|
|
|
worker_connections 1024;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
http {
|
2016-01-01 19:35:57 -05:00
|
|
|
# Set an array of temp, cache and log file options that will otherwise default to
|
2015-06-27 04:41:19 -04:00
|
|
|
# restricted locations accessible only to root.
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
client_body_temp_path $ROOT/client_body;
|
|
|
|
|
fastcgi_temp_path $ROOT/fastcgi_temp;
|
|
|
|
|
proxy_temp_path $ROOT/proxy_temp;
|
|
|
|
|
#scgi_temp_path $ROOT/scgi_temp;
|
|
|
|
|
#uwsgi_temp_path $ROOT/uwsgi_temp;
|
|
|
|
|
access_log $ROOT/error.log;
|
2015-06-27 04:41:19 -04:00
|
|
|
|
|
|
|
|
# This should be turned off in a Virtualbox VM, as it can cause some
|
|
|
|
|
# interesting issues with data corruption in delivered files.
|
|
|
|
|
sendfile off;
|
|
|
|
|
|
|
|
|
|
tcp_nopush on;
|
|
|
|
|
tcp_nodelay on;
|
|
|
|
|
keepalive_timeout 65;
|
|
|
|
|
types_hash_max_size 2048;
|
|
|
|
|
|
2015-06-30 10:52:05 -04:00
|
|
|
#include /etc/nginx/mime.types;
|
2015-06-27 04:41:19 -04:00
|
|
|
index index.html index.htm index.php;
|
|
|
|
|
|
|
|
|
|
log_format main '\$remote_addr - \$remote_user [\$time_local] \$status '
|
|
|
|
|
'"\$request" \$body_bytes_sent "\$http_referer" '
|
|
|
|
|
'"\$http_user_agent" "\$http_x_forwarded_for"';
|
|
|
|
|
|
|
|
|
|
default_type application/octet-stream;
|
|
|
|
|
|
|
|
|
|
server {
|
|
|
|
|
# IPv4.
|
2018-03-27 20:33:48 -04:00
|
|
|
listen 5002 $default_server;
|
2015-06-27 04:41:19 -04:00
|
|
|
# IPv6.
|
2018-03-27 20:33:48 -04:00
|
|
|
listen [::]:5002 $default_server;
|
2019-03-18 13:22:19 -04:00
|
|
|
server_name nginx.wtf nginx2.wtf;
|
2015-06-27 04:41:19 -04:00
|
|
|
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
root $ROOT/webroot;
|
2015-06-27 04:41:19 -04:00
|
|
|
|
|
|
|
|
location / {
|
|
|
|
|
# First attempt to serve request as file, then as directory, then fall
|
|
|
|
|
# back to index.html.
|
|
|
|
|
try_files \$uri \$uri/ /index.html;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-03-27 20:33:48 -04:00
|
|
|
|
|
|
|
|
server {
|
|
|
|
|
listen 5002;
|
|
|
|
|
listen [::]:5002;
|
|
|
|
|
server_name nginx3.wtf;
|
|
|
|
|
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
root $ROOT/webroot;
|
2018-03-27 20:33:48 -04:00
|
|
|
|
|
|
|
|
location /.well-known/ {
|
|
|
|
|
return 404;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 301 https://\$host\$request_uri;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
server {
|
|
|
|
|
listen 8082;
|
|
|
|
|
listen [::]:8082;
|
|
|
|
|
server_name nginx4.wtf nginx5.wtf;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
server {
|
|
|
|
|
listen 5002;
|
|
|
|
|
listen [::]:5002;
|
|
|
|
|
listen 5001 ssl;
|
|
|
|
|
listen [::]:5001 ssl;
|
|
|
|
|
if (\$scheme != "https") {
|
|
|
|
|
return 301 https://\$host\$request_uri;
|
|
|
|
|
}
|
|
|
|
|
server_name nginx6.wtf nginx7.wtf;
|
Fix the Nginx configuration during integration tests (#6801)
If you execute `tests/lock_test.py` or `tox -e integration` on a fairly recent machine, you will get the following error during tests executing against a live Nginx instance:
```
no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: x.x.x.x, server: y:y:y:y:z
```
Indeed, having no defined ssl certificate for a ssl port would inevitably lead to an error during the handshake SSL process between a client and this mis-configured nginx instance.
However it was not a problem one year before, because the handshake was not occurring in practice: the test just need to have a nginx started, and then immediately proceed to modify the configuration with a correct SSL setup. And nginx was able to start with a mis-configuration on SSL.
But then this fix has been done: https://trac.nginx.org/nginx/ticket/178
Basically with this, validation of the configuration is done during nginx startup, that will refuse to start with invalid configuration on SSL. Consequently, all related tests are failing with a sufficiently up-to-date nginx. For now, it is not seen on Travis because Ubuntu Trusty is used, with an old Nginx.
The PR fixes that, by generating on the fly self-signed certificates in the two impacted tests, and pushing the right parameters in the Nginx configuration.
* Fix nginx configuration with self-signed certificates generated on the fly
* Fix lint/mypy
* Fix old cryptography
* Unattended openssl
* Update lock_test.py
2019-03-01 16:54:09 -05:00
|
|
|
|
|
|
|
|
ssl_certificate ${CERT_PATH};
|
|
|
|
|
ssl_certificate_key ${CERT_KEY_PATH};
|
2018-03-27 20:33:48 -04:00
|
|
|
}
|
2015-06-27 04:41:19 -04:00
|
|
|
}
|
|
|
|
|
EOF
|