One subdomain with 2 ips on the same server

[gigecdn]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: xxx.yyy.com

I set this in nginx :
server {
listen aaa.bbb.ccc.ddd:443 ssl;
listen eee.fff.ggg.hhh:443 ssl;
server_name xxx.yyy.com;
I ran this command: certbot renew --force-renewal -d xxx.yyy.com

It produced this output: command run ok but ssl only works on first ip, get this error on the second ip:
(I force the ip via /etc/hosts file)
sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

My web server is (include version): nginx/1.16.1

The operating system my web server runs on is (include version): Centos 6

My hosting provider, if applicable, is: Me

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): Hell no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 1.2.0

[rg305]

You can only bind nginx to IPs that actually exist on the local system.
Thay said, do aaa.bbb.ccc.ddd and eee.fff.ggg.hhh exist on the local system?
Like:

 listen 8.8.8.8:443 ssl;

will NOT work.

[ifconfig|grep -Ei ‘add|inet’]

[gigecdn]

Of course , same config sans https on port 80 works fine

[rg305]

@gigecdn

listen aaa.bbb.ccc.ddd:443 ssl;
listen eee.fff.ggg.hhh:443 ssl;

Try reversing the order in the config:

listen eee.fff.ggg.hhh:443 ssl;
listen aaa.bbb.ccc.ddd:443 ssl;

[see what that changes, if anything]

[jsha]

Hi @gigecdn,

This sounds like an interesting problem! I’m surprised it works with one IP address and not the other. It would be really helpful if you could share your real hostname and real IP addresses, since those are critical to understanding and diagnosing the problem. As the help template describes, your hostname is published in the CT logs, so there’s no harm in sharing it here.

Thanks,
Jacob

[gigecdn]

Hello Jacob, first of all congratulations on the project , and thank you so much for the great service,
Seems this is the culprit:
ssl_session_tickets off;
when removed from configs, it works.
I can replicate most I think and give you access links but it will take me a few days is a dual network server (which I do not think is the issue ) and we do not provision many of those .

Thanks,
Bernard

[jsha]

Ah, interesting! I would not have guessed that would be what fixed it. Thanks for the update, and for the kind words.

[mnordhoff]

FYI, that sounds like this issue:

Investigate cause of 0.37.1

The issue focuses on Apache, but it’s an OpenSSL bug that affects both Apache and Nginx if used with equivalent configurations.

You can turn off session tickets – but to avoid the bug, you have to make sure all of your virtual hosts have it set the same way.