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
Hello,
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 wsv.gtbox.fr to point to the new machine and we recreated the certificates on this new machine (wsv.gtbox.fr, ecomethodes.gtbox.fr and wsv.madobox.fr). 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 https://noz.gtbox.fr/StoreboxJSF 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 wsv.gtbox.fr 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.
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.
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 (https://noz.gtbox.fr), 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 wsv.gtbox.fr from our old server to the new one that the problem seems to arise!?
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 ?
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?
OR
Are you doing various port mappings [to multiple servers behind that single IP]?
OR
Were there multiple external IPs involved?
We had a machine on which our JBOSS AS7 server was running and to which the address wsv.gtbox.fr pointed. We had no problem accessing the machine in https with any browser (https://wsv.gtbox.fr)
We activated a new machine several months ago on which we installed exactly the same JBOSS AS7 software. We had declared a noz.gtbox.fr address that pointed to this new machine. We used it in testing for several months and could access https via https://noz.gtbox.fr 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 (wsv.gtbox.fr, noz.gtbox.fr,...) and modified the IP addresses so that wsv.gtbox.fr points to the new machine.
Since then, we are unable to connect in https with Chrome and Edge to this new machine (https://wsv.gtbox.fr) while with Firefox it works perfectly!?
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 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.
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 https://noz.gtbox.fr URL ?
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).
Unfortunately, the old JBOSS server no longer works either. I had to recreate the wsv.gtbox.fr certificate on the new machine so I deleted it on the old one. I recreated a new certificate (snt.gtbox.fr) 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 wsv.gtbox.fr) 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 wsv.gtbox.fr (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 wsv.gtbox.fr hoping it works.