Hmmm not sure : rewrite is done at url level by Apache, when ssl is used at content level
Ok let me try your nginx examble
I think NGINX is smarter than Apache - LOL
Even though it allows the config, it already knows that IP:port are doing TLS, so it doesn't multi-bind HTTP and HTTPS to it.
Although it should then say something about it with nginx -t
400 The plain HTTP request was sent to HTTPS port
hmm... protocol broker...
I don't even pass
nginx -t
with same ip:port but different server_name
nginx version: nginx/1.17.1 (CentOS)
nginx/1.19.4 (Alpine Linux v3.12 in docker container)
server {
listen *:89 ssl http2;
server_name www.d.com;
location / {
proxy_pass https://d.com/;
}#location
}#server
server {
listen *:89;
server_name d.com;
location / {
proxy_pass https://d.com/;
}#location
}#server
nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
nginx version: nginx/1.14.0 (Ubuntu)
Anyway, the point is that it is NOT always NOT allowed.
[double negative?]
So cerbtot can't be 100% certain if you meant to also use that port with HTTP.
Or was that an implied upgrade?
[I may have missed something there...]
1 Like
I tried to rebuild my image with your nginx version but I have some errors. But it's too late now. I'll retry soon and let you now.
But if it's allowed by some nginx version, I'm agree it's not a bug, of course.
Thanks for time, i'll let you know when i'm abble to test.
2 Likes
For what it's worth in this scenario, per JuergenAuer:
I don’t know if openHAB supports two protocols on the same port (some programs do).
Hi all
Ok I have tried:
server {
server_name domain1.com;
location / {
... proxy pass ...
}
listen *:8443 ssl http2; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/domain1.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/domain1.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 {
server_name domain2.com;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
listen *:8443 ;
}
Nginx file is OK, loaded without conflict, but http port is invalid:
/ $ nginx -v
nginx version: nginx/1.19.4
/ $ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
/ $ nginx -s reload
2020/11/12 21:59:37 [notice] 116#116: signal process started
/ $ curl http://domain2.com:443/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 255 100 255 0 0 3148 0 --:--:-- --:--:-- --:--:-- 3187<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.19.4</center>
</body>
</html>
Yesterday, it was not a version error, but http section has to be set AFTER https section, else it is refused by Nginx:
server {
server_name domain2.com;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
listen *:8443 ;
}
server {
server_name domain1.com;
location / {
... proxy pass ...
}
listen *:8443 ssl http2; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/domain1.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/domain1.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
}
,
/ $ nginx -t
2020/11/12 22:09:36 [emerg] 119#119: no "ssl_certificate" is defined for the "listen ... ssl" directive in /etc/nginx/conf.d/default.conf:1
nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /etc/nginx/conf.d/default.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed
But with http before of afer, you can' t merge both domain sections:
#merdeg with http section before
/ $ nginx -t
2020/11/12 22:11:38 [emerg] 120#120: a duplicate listen 0.0.0.0:8443 in /etc/nginx/conf.d/default.conf:20
nginx: [emerg] a duplicate listen 0.0.0.0:8443 in /etc/nginx/conf.d/default.conf:20
nginx: configuration file /etc/nginx/nginx.conf test failed
/ $
/ $
/ $
# merge with http section after
/ $ nginx -t
2020/11/12 22:15:19 [emerg] 121#121: a duplicate listen 0.0.0.0:8443 in /etc/nginx/conf.d/default.conf:25
nginx: [emerg] a duplicate listen 0.0.0.0:8443 in /etc/nginx/conf.d/default.conf:25
nginx: configuration file /etc/nginx/nginx.conf test failed
About the "The plain HTTP request was sent to HTTPS port" error, I event tried a rewrite to forward to https like you do in your with Apache example, but it does not work, or maybe I'm not writing it well:
server {
server_name domain2.com;
rewrite ^.*$ https://domain1.com$request_uri last;
return 403;
listen *:8443 ;
}
But Ok, even if doesn't work, Nginx accepts the config...
Anyway, as both sections can't be merged , neither the server_name can be the same in both section when listen port is the same:
Then don't you think that Certbot command can identify section, as you have to specify the certificate domain wich identifies the section if port is the same?
If your are not agree, I have another working solution, then np it's not a bug and I can deal with it 
2 Likes
Has that old hag been around here again? Always causing trouble, breaking padlocks, and erasing keys...
You would be amazed at the horror stories we tell around here about the configurations we see.
Bitnami, anyone? 
Hey! Where you guys going?
1 Like
Too much "The Witcher" maybe 
2 Likes
1 Like
Oh interesting feature that I wasn't aware, thanks!
Then that means it's a way to have both protocol in same config, and that ends the debate.
Ok, Ok, I'm game over, I'm going out 
So you can close the thread.
Thanks all
2 Likes
I wonder what happens if you just change the order...
server {
listen 8443;
server_name mydomain.com;
1 Like
Retry from my initial docker problem?
If so, I retried: same error from Certbot, it still tries to add
listen 8443 ssl; # managed by Certbot
in the same section, then ends with error
[emerg] 80#80: a duplicate listen 0.0.0.0:8443 in /etc/nginx/conf.d/default.conf:15
2 Likes
This is exactly why I have railed against the careless prescription of installers and advocated for the complete segregation of acquisition and installation functionality in certbot.
If users needed to first run:
certbot acquire ...
Then could run (with caution and in full awareness of the rollback function):
certbot install ...
So many of these issues could be avoided entirely!
1 Like
But actually it's rollbacked if I setup config to raise this error. The segregation wouldn't solve my problem:
- I would first acquire the certificate, ok
- I would start Nginx without ssl (because I want a full ssl autoconfig from certbot)
- I would run certbot install, but I would be in the same situation than now, foced to use a dummy port, so certbot can configure the real ssl port I want to be configurated.
1 Like
rollback unbreaks your configuration after a failed installation