Je peux lire des réponses en Anglais :Yes

Mon nom de domaine est :

Mon serveur Web est (inclure la version) : JBoss AS7

Le système d’exploitation sur lequel mon serveur Web s’exécute est (version incluse) : Ubuntu 20.04.5

Mon hébergeur, le cas échéant, est : WebAxsys

Je peux me connecter à un shell root sur ma machine (oui ou non, ou je ne sais pas) : Yes

J’utilise un panneau de configuration pour gérer mon site (non, ou fournit le nom et la version du panneau de configuration) : No


We migrated a Java JBOSS application server to a new hardware today. This application is accessible via the URL GTBox. We therefore modified the DNS declaration of to point to the new machine and we recreated the certificates on this new machine (, and We integrated these certificates in our jboss server by generating a keystore using openssl and keytool.

With Firefox we can connect to our web application via the URL GTBox. The browser indicates a full secured connection.
With Chrome or Edge, we get an error "ERR_SSL_VERSION_OR_CIPHER_MISMATCH. The client and server are not compatible with a common SSL protocol version or encryption method."

We were already using this new server in test before our migration today, by connecting with the URL and we were able to connect with Firefox, Chrome and Edge without any problem !?

I don't understand where the problem comes from!? I really need your help ! Our application on is in production on this new server and the fact of not being able to connect with all types of browser is a main issue for us.

Thanks in advance.

Best regards.


1 Like

Is the webserver Apache? You may need to check your apache configuration and compare it to the old server as you may not have enabled TLS 1.2 or a modern supported cipher.

Here is a tool to suggest modern TLS configurations for difference servers: Mozilla SSL Configuration Generator


As background, your certificate identifies your server as being a match for the requested domain name, but the actual https (http over TLS) conversation relies on the client browser and your server agreeing a set of ways to communication over TLS (previously called SSL) and a set of mutually understood encryption methods (Cipher suites). In recent years major browsers have retired support for TLS 1.1 and instead support TLS 1.2 onwards.


Thank you for your answer. It is a JBoss application server. I'm not sure what web server it relies on, maybe it's Apache? The server uses the TLS1.2 protocol. Everything worked fine as long as I accessed the new server through a new URL (, I could connect using SSL with any browser. It is therefore normally that the configuration of the JBoss server is good.
It's since I switched the address of from our old server to the new one that the problem seems to arise!?

1 Like

ssllabs testing didn't end yet

it ended and it doesn't like this page tto


It looks like you need to update the list of supported TLS Ciphers in your Apache config:

You are running Apache Tomcat directly (your server header is Apache-Coyote/1.1 so you need to update the cipher support in your config:


Thanks for your answer "orangepizza". Looks like in fact Chrome does not support our ssl exchanges : "Server sent fatal alert: handshake_failure". I don't understand where it can comes from, any idea ?

1 Like

By the way both and return ERR_SSL_VERSION_OR_CIPHER_MISMATCH for me using Chrome.


What exact version of JBOSS are you running, i.e. what was it's release date? If its very old (like 2012) you should not connect that directly to the internet and instead seek a more modern version of the software or use a modern webserver as a reverse proxy.


Both return the same IP.
Yet, you make mention of now using new hardware:

But you also mention:

This leads me to believe that at some point multiple servers might have been using the same external IP.
If that the case, is there some proxy in front of these servers?
Are you doing various port mappings [to multiple servers behind that single IP]?
Were there multiple external IPs involved?


To give you some precisions :

We had a machine on which our JBOSS AS7 server was running and to which the address pointed. We had no problem accessing the machine in https with any browser (

We activated a new machine several months ago on which we installed exactly the same JBOSS AS7 software. We had declared a address that pointed to this new machine. We used it in testing for several months and could access https via without any problem.

Today we stopped our old machine and switched everything to the new machine. We have therefore recreated the ssl certificate on the new machine (,,...) and modified the IP addresses so that points to the new machine.
Since then, we are unable to connect in https with Chrome and Edge to this new machine ( while with Firefox it works perfectly!?


I tried changing the cipher_suite as advised but it doesn't work. The only thing I manage to do that Firefox also can't connect anymore!?

from firefox server header if given is Apache-Coyote/1.1 and google suggetest it's a tomcat?
more search found that this header is removed in tomcat 8, and tomcat 7 is EOLed in 2021 by 7.0.109


You can skip trying to reissue a new cert, that part is working correctly: |

The ciphersuites in use are very bad:
SSL Server Test: (Powered by Qualys SSL Labs)


You may wish to contact the vendor for your application server product for support. You will need to update the enabled cipher suites.

You could look at having a reverse proxy such as Caddy, nginx or Apache to act as your main webserver proxied back to the jboss server, if jboss simply can't be modernised enough to work with current generation browser.


Thanks for your answer rg305.

I don't exactly understand what you mean by "You can skip trying to reissue a new cert, that part is working correctly". Sorry but my English is not very good...?

I agree, "ciphersuites in use are very bad", we are currently working to change our JBoss release wich will allow us to use new ciphers but we ar not ready yet. What i don't understand is why the same JBoss software was working with any webbrowser (including Chrome) on tuesday while we were accessing it with the URL ?

Many thanks for your help.

1 Like

5 certs have been issued very recently.
You don't need to issue any more certs.


If your old server is still running you could compare the TLS responses to check which ciphers are being offered when negotiating with the client, or just compare the server config files. They're clearly different configurations, unless you can prove otherwise.

Note that these issues are not related to Let's Encrypt or ACME etc, this is standard server configuration and if you are having trouble you may benefit from hiring a local consultant with the necessary experience.

Personally I would suggest that if you cannot determine why the jboss config is different then create a new reverse proxy server (a web server that simply acts as an https front end, streaming requests back to your actual jboss server).


Hello WebProfusion,

Many thanks for the time you spent on my problem.

Unfortunately, the old JBOSS server no longer works either. I had to recreate the certificate on the new machine so I deleted it on the old one. I recreated a new certificate ( on this old machine but chrome does not recognize it either.

Fortunately, we have another test machine on which we had created a LetEncrypt certificate a while ago. It works with Chrome while it's the exact same JBoss inside!!?

I launched a certificate analysis via ssl labs. Ciphers are indeed different, it is less well rated overall in terms of security than wsv.gtbox. fr (F for this machine against C for but it integrates a Cipher "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA" which seems recognized by everyone and which is not in the ciphers of (and I don't understand besides why not since it is the same version of Ubuntu and JBoss!!?).

I'm trying to add this Cipher in Jboss on hoping it works.

I will tell you.

1 Like

The deletion wasn't a requirement.
[oh well, too late]