Error - Certificate isn't trusted, RemoteCertificateNameMismatch

Help
1

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: www.biodanza-ferdi.nl

I ran this command:https://check-your-website.server-daten.de/?q=biodanza-ferdi.nl

It produced this output:Error - Certificate isn’t trusted, RemoteCertificateNameMismatch

My web server is (include version):Lighttpd 1.4.45

The operating system my web server runs on is (include version):Ubuntu 18.04 server

My hosting provider, if applicable, is:VIMEXX

I can login to a root shell on my machine (yes or no, or I don’t know):no, not directly, but sudo is available.

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): can’t check right now, will add asap

Since yesterday Chrome and Firefox refuse to connect to my website with an display an SSL error that is not really helpful, but other browsers show the site without any problems.
So far IE11, Microsoft Edge and Samsung Browser (android) all show my site without error.
https://www.ssllabs.com/ssltest/ gives me an A rating, but the https://check-your-website.server-daten.de/?q=biodanza-ferdi.nl site gave me more helpful message, but how can I solve this?
Up till now it has been working correctly for over a year, without any change to the certificates, except for the regular update.
Anyone have a clue?

2

Hi @ferdiS

reading the output there are two https connections:

Domainname Http-Status redirect Sec. G
• http://biodanza-ferdi.nl/
185.104.30.12 200 0.040 H
• http://www.biodanza-ferdi.nl/
185.104.30.12 200 0.036 H
• https://biodanza-ferdi.nl/
185.104.30.12 200 1.147 N
Certificate error: RemoteCertificateNameMismatch
• https://www.biodanza-ferdi.nl/
185.104.30.12 200 0.840 B

non-www doesn't work, www does -> check www with Ssllabs - all is ok.

The reason: Your certificate

CN=www.biodanza-ferdi.nl
	31.05.2019
	29.08.2019
expires in 70 days	www.biodanza-ferdi.nl - 1 entry

has only one domain name, the www version. So non-www isn't secure.

--> Create one certificate with both domain names and use that.

If you use Certbot, start with something like

certbot -d www.biodanza-ferdi.nl -d biodanza-ferdi.nl [yourOtherParameters]

PS: Interesting. Perhaps you have cleaned your cache (your saved redirects are removed), so browsers first fetch the non-www version -> error.

PS: Later you should add a redirect http -> https.

3

Hi JuergenAuer

Thanks for the quick reply. So far the error occurs on www.biodanza-ferdi.nl, I never use the non-www name but i will add the non-www name to the certificate asap and check if that will work.

I tested on multiple machines running different OS’es (Windows 10; Linux; Android) All have the issue with Firefox and Chrome. None of these machines had ever been used to connect to my site, specifically wanted to test this after the error occurred on my personal machine.

I temporarily disabled the http -> https redirect on the server because of this issue so my site is at least reachable, all be it not secure.

For the record Chrome reports this: ERR_EMPTY_RESPONSE on https://www.biodanza-ferdi.nl and indeed correctly with NET::ERR_CERT_COMMON_NAME_INVALID on https://biodanza-ferdi.nl

4

After making some changes, I now get an A rating on https://check-your-website.server-daten.de/?q=biodanza-ferdi.nl

Strangely enough, browsers still give me an error and cannot connect using https (they can if I disable http => https redirecting and connect with http)

Other tools like the W3 validator, the SSL test from Qualisys (A+ on that one) can connect perfectly well using https.

I’m lost for options right now…

5

That looks good.

Do you have a screenshot?

Checked with Ssllabs that's a good result.

6

Unfortunately, I partly have to rely on my site to get customers, so I had to reset the HTTP => HTTPS for now in able to be reachable. It is only 3 lines in my webserver setup but still…
I will try to upload a screenshot soon.

7

Now I see the problem.

Checked with Chrome:

biodanza-ferdi.nl hat keine Daten gesendet.

ERR_EMPTY_RESPONSE

All online tools have correct Tcp-connections and add a SSL-connection. So all tools are happy.

But your webserver doesn't send data.

But I don't know how that Lighttpd works.

And checked your last output, https has Content.

Content-Length: 8898

Is there something like a vHost configuration? Compare the port 80 and port 443- vHost configuration.

PS: And there - https://check-your-website.server-daten.de/?q=biodanza-ferdi.nl#html-content - is a lot of content.

PPS: Checked the header and downloaded the file via https - the same, 8898 bytes, the complete content.

Is there a browser specific switch that blocks?

8

Yep, your Tls.1.3 configuration is buggy. IE11 and Edge don’t use Tls.1.3, so they connect via Tls.1.2.

I don’t know, why this configuration is buggy.

But blocking Tls.1.3 in FireFox -> I can load your site via FF.

Perhaps you have too restricted Cipher Suites.

PS: about:config, search security.tls.version.max, switch 4 (Tls.1.3) to 3 (Tls.1.2) -> your site works.

1 Like
9

Wow I must say, you are of great help!
I will get into this tomorrow, checking out how to setup Tls 1.3 correcly, or disable it from server side.

THANKS a lot!

1 Like
10

Does that version support Tls.1.3?

11

There

https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL

is the answer.

lighttpd supports TLS/SSL using openssl.

Your openssl version must support Tls.1.3.

12

Ubuntu 18.04 LTS supports Openssl 1.1.1 (hence TLS 1.3) if it has been fully (apt full-upgrade) updated as of less than two weeks ago. However it has been said many times than the ciphers need to be revised when updating to TLS 1.3...

2 Likes
13

I have the latest Openssl 1.1.1 installed and working fine, it is also used by Vsftpd, postfix and dovecot on the same server.
I think that the problem is the version of Lighttpd. 1.4.45 is rather old. It does not offer the possibility do disable TLS1.3, that came in 1.4.48.
The current version is 1.4.54, read somewhere that the package had been abandonend by the Debian dev’s for several years. When I checked the Ubuntu repositories, I found that only the current development version (Eoan Ermine) has a newer version (1.4.52 to be precise).
Perhaps I should have a go at compiling the latest stable version and file a bug against the Ubuntu 18.04 package so they can perhaps backport their current version to 18.04

2 Likes
14

So far I have taken an old laptop, installed 18.04 server on it and installed lighttpd from the 18.04 repository, going to replicate my current webserver setup to the laptop so that I have a testing rig that I can use without having to experiment in the live environment.

Already downloaded and compiled the latest version of Lighttpd, and tested, without installing it yet. Seems to be working.

Also tried to install the Lighttpd version from the Ubuntu 19.04 and 19.10 repositories, but they have too many unmet dependencies, and installing those dependencies might break other applications.

Testing continues…

2 Likes
15

Results on the testsystem are reproducable, TLS 1.3 in default configuration with the Ubuntu lighttpd package is buggy, TLS 1.2 works.

I am going to file a bug against the Ubuntu 18.04 lighttpd package on launchpad.

Next is installing my freshly compiled lighttpd on the testsystem. I expect that i will have to do little or no reconfiguration of the server config for it to work.

2 Likes
16

The bug had already been reported, verified and triaged. The corrected version was build tested and placed in the “proposed” repository 7 hours ago.

Installed lighttpd from the proposed repository on my testrig and it works!

Saves me some compiling and other work!

2 Likes
17

Thanks, good to know.

Setting (FireFox)

security.tls.version.min = 4
security.tls.version.max = 4

your site works, my own site (without Tls.1.3) doesn’t work :wink:

1 Like
18

Perhaps I can help you with that?

Glad with your help, learned some more about SSL thanks to you!

2 Likes
19

It's a Windows 2012 Server, that doesn't support Tls.1.3.

Was a check if my browser uses really only Tls.1.3 and nothing else.

21

Indeed even Windows server 2019 does not (yet) fully support TLS 1.3 :face_with_raised_eyebrow:

Last time I configured a webserver with windows was on Windows 2000, it worked, but not more than that. Could not really handle the load.

1 Like