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

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?

1 Like

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.

2 Likes

'/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.

1 Like

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.

1 Like

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

2 Likes

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)

3 Likes

@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.

3 Likes

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.

3 Likes

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

3 Likes

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

}

1 Like

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.

3 Likes

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

2 Likes

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

3 Likes

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.

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]

1 Like

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