Certificate for two subdomains, one subdomain shows handshake failure

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. crt.sh | 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: meet.freundel.net, cloud.freundel.net
I ran this command: browsing with Firefox 86
It produced this output:
Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit meet.freundel.net trat ein Fehler auf. Die SSL-Gegenstelle hat eine
Handshake-Nachricht wegen inakzeptablem Inhalt abgelehnt.
My web server is (include version): nginx version: nginx/1.19.8
The operating system my web server runs on is (include version): Debian 10
My hosting provider, if applicable, is: Strato
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): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): acme.sh

Both - the Cloud and Jitsi - running on one server / one IP. Both subdomains are forwarded to that IP. I created a certificate for both subdomains. The certificate seams to be fine (check at SSL Checker).

When I start browsing to the meet subdomain, the above mentioned error occurs. When I next browse to the cloud subdomain, it works fine. When I after that browse to the meet subdomain again, it works fine as well. Browsing the cloud subdomain is always fine.

The error can be repeated after cleaning the browser cache. Other browsers show different error messages, but the basic behavior is the same.

Any idea why that first error occurs?


Welcome to the Let's Encrypt Community, Paul :slightly_smiling_face:

From my research (and your A+ results from SSL Labs), I believe you may need to look at your your TLS parameters in nginx.

Have a look here:

and here:


1 Like

You can begin tracking things down by running:

nginx -T

This will indicate which configuration files are active for what ports.

1 Like

Hi @Paul56

I'm not firm with these configurations. But checking both domains with SslLabs:

Not working domain:

Uses common DH primes No, DHE suites not supported
DH public server param (Ys) reuse No, DHE suites not supported

Working domain:

Uses common DH primes No
DH public server param (Ys) reuse No

May be change your Tls.1.2 cipher suites.

But it's very speculative and the Google results are old.

PS: You use one certificate with both domain names. So your first domain is broken. Connecting the second domain all works. Then FF has the correct certificate, so it's possible to re-use it. Cleaning the cache -> you have the problem again.

So compare both nginx configurations.

1 Like

Thank you for your input. I could clarify it.

In the nginx-conf-file for the meet subdomain I changed
from ssl_prefer_server_ciphers off;
to ssl_prefer_server_ciphers on;

Now it works. Thank you for your support.

1 Like

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