Valid certificate has an issue with “ Your connection is not private”

wberdnik · October 15, 2021, 9:02am

Hi, my domains are leadinka.com and crm.leadinka.com. Other sites on my web server with 'certbot' certificates are working correct.

A lot of years we used the certbot(0.28.0) and Let`s Encrypt certificates. Just now I have had an issue with this two certificates.

I am working with a root shell web server (Ubuntu, nginx/1.10.3)

I ran this commands:

'nginx -t' type 'syntax is correct'
'openssl rsa -modulus -in ./privkey.pem' and 'openssl x509 -modulus -in ./cert.pem' are equal

'openssl s_client -servername leadinka.com -connect leadinka.com:443 -showcerts' :
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = leadinka.com
verify return:1

But
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits

All TLS Handshake Session Ticket arrived.

curl -I 'https://leadinka.com'
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Fri, 15 Oct 2021 08:02:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=3qo6iajun8pfd2vau297vnvib2; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: ****************************

lynx https://leadinka.com has opened

Check by site https://check-your-website.server-daten.de/?q=leadinka.com :
the certificate is correct. Page has opened.

Google Chrome, Mozilla FireFox and other don't open https://leadinka.com:
ERR_CONNECTION_CLOSED. Your connection is not private. Owner information of site is absent.

local machine:
openssl s_client -tls1 -connect leadinka.com:443 -state -debug
CONNECTED
SSL_connect: before connect initialization
write to 0x1316760 [0x2ca3ae3] (200 bytes => 200 (0xC8))
0000 - 16 03 01 00 c3 01 00 00-bf 03 01 7d d4 62 a7 d6 ...........}.b..

00c0 - 23 00 00 00 0f 00 01 01- #.......
SSL_connect:SSLv3 write client hello A
read from 0x1316760 [0x2c9f593] (5 bytes => 0 (0x0))
SSL_connect:failed in SSLv3 read server hello A

But, site of this web server
openssl s_client -ssl3 -connect proflead.org:443 -state -debug

CONNECTED(00000240)
SSL_connect:before/connect initialization
write to 0x13961b0 [0x1223b93] (149 bytes => 149 (0x95))

0080 - c0 08 00 16 00 13 00 10-00 0d c0 0d c0 03 00 0a ................
0090 - 00 ff 02 01 ....
0095 - <SPACES/NULS>
SSL_connect:SSLv3 write client hello A
read from 0x13961b0 [0x121f643] (5 bytes => 5 (0x5))
0000 - 15 03 00 00 02 .....
read from 0x13961b0 [0x121f648] (2 bytes => 2 (0x2))
0000 - 02 28 .(

What does it mean and what to do me?

SagePtr · October 15, 2021, 11:27am

SSL Server Test: leadinka.com (Powered by Qualys SSL Labs) shows different results for IPv4 and IPv6. Either DNS records are configured incorrectly and point to different servers, or nginx doesn't listen SSL socket for IPv4, only for IPv6.

wberdnik · October 15, 2021, 11:50am

'/etc/nginx' has not changed and file 'nginx.conf' has correct configuration. I have no confidence of NS-service of name.com. I'm checking this.

wberdnik · October 15, 2021, 12:19pm

DNS records are correct. I checked at local machine, web server and online service.
I've not IPv6 at local machine so have not https.
I'm should looking for a bug of nginx or system because 'hello A handshake' don't answer too.

wberdnik · October 15, 2021, 1:18pm

I will definitely report this error to Nginx Inc (#2257 (Неявное разрушение всех настроек и очень странное поведение сервера) – nginx). I had a website configured in nginx.conf that had no longer needed. I commented out lines 'ssl_certificate*' without changing lines 'listen'. 'nginx -t' did not show any error, but a bellow of changing settings began to do so strangely with ipv4. The nginx server should not work like this with such settings.
Thank you all

SagePtr · October 15, 2021, 2:02pm

If you use very outdated nginx version, it may have a lot of bugs. Try to update nginx to the latest stable or mainline version. Also, don't forget each server block should have their own listen directives, it won't inherit them from the upper context according to docs.
If you are listening both 80 and 443 port and both IPv4 and IPv6, you should have 4 listen directives in each virtual host (unless you separate them into multiple server blocks)

MikeMcQ · October 15, 2021, 2:19pm

@SagePtr I can reproduce a similar problem with nginx 1.20.0 (maybe the same problem).

To test, I setup a server with listen 443 ssl; but commented out the two ssl_certificate* lines. Let's call this Server2

I have a default server defined with listen 443 default_server ssl; and a self-signed cert. Let's call this Server1

nginx -t is ok. Stop/Start is good.

Requests to Server2 succeed (via SNI) but the certificate used is from the default server - Server1. Note though the response is as defined in Server2. The default server only issues a 403 but Server2 responds different. So, Server2 is not invalid - it just serves the "wrong" chain. Perhaps this is documented somewhere but it caused me some confusion a few weeks back when testing configurations.

I did not test having another non-default server for 443 and valid cert lines to see if nginx would have chosen just the prior server def rather than the specific one marked default.

Maybe this info can help @wberdnik work with nginx or just better understand what happened. It is a peculiar combination to have a listen for 443 but no certificates defined.

SagePtr · October 15, 2021, 2:44pm

It's the different problem: wrong virtual host served. In original case, the server didn't serve IPv4 at all (but served IPv6), but later the author fixed it and it started to serve both.

MikeMcQ · October 15, 2021, 2:54pm

@SagePtr Yes, they had other odd things. I was focusing on this quoted comment.

wberdnik · October 15, 2021, 4:31pm

http {
## some settings

server {
	server_name www.proflead.org;
	listen otherIPv4:443 ssl;
	listen [2a00:ab00:603:87::2]:443 ssl;
	#foo bar foo bar foo bar
	
	#this site was working correct

	ssl_certificate /etc/letsencrypt/live/www.proflead.org/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/www.proflead.org/privkey.pem;
}

a set of sites with otherIPv4 - very long list

server {
	server_name 7prav.ru www.7prav.ru;
	listen 87.251.80.91;
	listen 87.251.80.91:443 ssl;
	listen [2a00:ab00:603:87::2];
	listen [2a00:ab00:603:87::2]:443 ssl;
	 
	 ## this site is dead  
	 
	 #here was commented
	ssl_certificate /etc/letsencrypt/live/7prav.ru/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/7prav.ru/privkey.pem;
}

a set of sites with otherIPv4 - very long list

server {
	server_name leadinka.com www.leadinka.com;
	listen 87.251.80.91:443 ssl;
	listen [2a00:ab00:603:87::2]:443 ssl;
	## site 1 -corrupted IPv4
	ssl_certificate /etc/letsencrypt/live/leadinka.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/leadinka.com/privkey.pem;
}	
server {
	server_name crm.leadinka.com www.crm.leadinka.com;
	listen 87.251.80.91:443 ssl;
	listen [2a00:ab00:603:87::2]:443 ssl;
	##site 2 -corrupted IPv4
	ssl_certificate /etc/letsencrypt/live/crm.leadinka.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/crm.leadinka.com/privkey.pem;
}

a set of sites with otherIPv4 - very long list

}

SagePtr · October 15, 2021, 5:21pm

this site is dead

This domain looks expired:

domain:        7PRAV.RU
nserver:       ns1.expired.r01.ru.
nserver:       ns2.expired.r01.ru.

The other sites work correctly from both IPv4 and IPv6, except www.crm.leadinka.com which doesn't have corresponding DNS records.

wberdnik · October 15, 2021, 5:31pm

You're right, it is. Server Settings of 7prav.ru should not affect other sites. I planned to turn it off completely, but random circumstances have stopped me. These lines have remained commented out and nginx -t did not make any comments

JimPas · October 17, 2021, 3:13am

You may want to upgrade your version of certbot - v0.28.0 is quite old. The latest is v1.20.0.

wberdnik · October 17, 2021, 6:55am

It seems unreasonable to discuss version update preferences and policies in this post. The team's efforts in recent years have been focused on the transition to cloud solutions. The described problem has nothing to do with certbot, OS. It is very likely that this error is present in the latest versions of nginx. And even updating the nginx version for testing does not seem easy, since it was compiled with our modules, and not installed from the repository.

rg305 · October 22, 2021, 4:00am

Some of the listen don't even have a port:

I think you need to recheck all your listen statements.
[I'm not even sure why you put an IP in there at all]

system · November 21, 2021, 4:00am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Your connection isn't private Help	22	1659	December 23, 2020
Certbot SSL certificate failed for nginx server Help	9	1404	November 6, 2022
Safari users get "Connection is not Private" error Help	7	842	April 15, 2022
OpenSSL.SSL.Error: Help	6	13793	August 8, 2020
Error getting validation data, Type: connection Help	3	479	September 1, 2021

Valid certificate has an issue with “ Your connection is not private”

a set of sites with otherIPv4 - very long list

a set of sites with otherIPv4 - very long list

a set of sites with otherIPv4 - very long list

this site is dead

Related topics