Certificates are not trusted in chrome


#1

certificates are not trusted in google chrome


#2

tombala.tv has a COMODO certificate (CloudFlare) from the world wide web (source: SSLLabs for tombala.tv)

So… What is the exact error message you’re receving? Because without more info we can’t debug any further I’m afraid… Not me anyway :stuck_out_tongue:


#3

this certificate is signed for video.tombala.tv
@Osiris


#4

Well, that subdomain is behind a CloudFlare CDN too… No Let’s Encrypt certificate visible from the outside world what so ever…

You just surf to exactly those domains from your home computer? And those domains also resolve to the IP’s 104.24.104.175 and 104.24.105.175? (CloudFlare’s)


#5

i just put it behind im setting that now


#6

Yes, I see… And I see the problem:

https://www.ssllabs.com/ssltest/analyze.html?d=video.tombala.tv&hideResults=on&latest

Certificate name mismatch
Click here to ignore the mismatch and proceed with the tests
Try these other domain names (extracted from the certificates):

tombala.tv

The Subject Alternative Name doesn’t contain video.tombala.tv, nor does it contain www.tombala.tv.

How did you envoke the Let’s Encrypt script?


#7

letsencript-auto certonly -d video.tombala.tv


#8

I guess you also invoked the script once with -d tombala.tv, otherwise you wouldn’t end up with that certificate. :wink:

I can see you’ve got 4 certificates: https://crt.sh/?Identity=%tombala.tv&iCAID=7395

You just have to point your webserver to the right one. :smile:

For future reference: by using multiple -d switches, you can generate one certificate for multiple domains.


#9

i dont understand the point here cant i use letsencript for subdomains ?


#10

whats the solution for now ?


#11

That’s perfectly possible. From the history of your domain I can see you started with your “main” domain and next generated a few certificates extra for your subdomains. But somehow your webserver points to the first certificate you generated.

I don’t know how you’ve generated the first certificate? Also with certonly? Or the apache/nginx plugin?Anyway, you can find all your certificates in the directories in /etc/letsencrypt/live/ (symlinks to them anyway). Just point the configuration files in your webserver to the proper certificates and you’ll be on your way.


#12

i created everything by certonly argument and we have 2 servers one is running so i cant shutdown working nginx there so im changing dns records in order to point other device and creating certs there and copying live/domain.tld to other server and configuring the server block for nginx


#13

@Osiris i face still the same problem everything is correct and installed but chrome says this is an insecure connection for https://video.tombala.tv


#14

The server which is responsible for the host video.tombala.tv is (still) serving the certificate for tombala.tv and not the correct one, i.e. for video.tombala.tv.

You should edit your nginx configuration file for video.tombala.tv to point to the correct certificate and reload (or something) the server, so the correct configuration file is in effect. Don’t know how that’s done in nginx, I only work with Apache :neutral_face:


#15

@Osiris i just edited it is impossible it to serve for tombala.tv i created a seperated cert with -d video.tombala.tv and my server points to /etc/letsencript/archive/video.tombala.tv/[certificateFilesHere]


#16

Is it the correct server? Is it the correct configuration file? Did you reload nginx (if needed)? Because openssl s_client -connect video.tombala.tv:443 -servername video.tombala.tv doesn’t lie:

osiris@desktop ~ $ openssl s_client -connect video.tombala.tv:443 -servername video.tombala.tv
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X1
verify return:1
depth=0 CN = tombala.tv
verify return:1

Certificate chain
0 s:/CN=tombala.tv
i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X1
1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Now, a CommonName is quite deprecated nowadays, but openssl provides the PEM encoded certificate too, so we can triple check the SAN:

       X509v3 Subject Alternative Name: 
           DNS:tombala.tv
       X509v3 Certificate Policies: 

Nope, no video.tombala.tv in sight :neutral_face:

I would recommend debugging your nginx from your end somehow. I know I’ve got to give my Apache a /etc/init.d/apache2 reload for a graceful restart, so it reloads the new configuration changes.

Some info I found with some googling: Gracefully Restart Nginx Web Server After Changes Made In a Config File


#17

@Osiris i reloaded nginx many times already


#18

Have you verified the file your nginx configuration is pointing to contains the correct certificate with openssl x509 -noout -text -in /etc/letsencript/archive/video.tombala.tv/[certificateFilesHere] from the conf-file?

BTW, I think it is best practice to use the /live/ directory, but YMMV.


#19

@Osiris


#20

Well, that is the correct certificate indeed…

But I guess you’ve somehow wrecked your nginx configuration altogether:

http://video.tombala.tv/ gives:

Welcome to nginx on Fedora!

This page is used to test the proper operation of the nginx HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly.

Sorry dude, perhaps you’ve got some (virtualhost) nginx debugging to do? :stuck_out_tongue:

If I manually try to HTTP my way to the sites with openssl s_client with both Host: tombala.tv and Host: video.tombala.tv, both the returning HTML seems to be the same… Can that be correct? Both contain:

<meta name="description" content="Türkiyenin ilk canlı tombala sitesi!"/>

Identical for both host-headers.