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:edi.ibdata.org:4647
I ran this command:
openssl ciphers -v shows all available ciphers, including TLS1.2 but the Altova Flowforceservice does not offer TLS1.2
It produced this output:
My web server is (include version):Altova Flowforce 2024
The operating system my web server runs on is (include version):Ubuntu Focal
My hosting provider, if applicable, is:TransIp VPS
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):also available but SSH is better.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):not certbot related i think
Yes, your services certificate will have either an RSA or EC key and these map to different cipher suites when the client is negotiating the TLS connection with you. Both the client and your service have to agree on a cipher suite you both support.
As an example some older versions of Windows Server don't have ECDSA cipher suites enabled, even if TLS 1.2 is enabled. So although they can start to negotiate using TLS1.2 if a matching cipher suites isn't enabled at the client then they wont be able to complete the negotiation.
The most compatible is an RSA key (and associated cipher suites), so if you have clients you can't control then an RSA keyed certificate will provide more compatibility.
Every test we have done ourself using openssl s_client also confirms that TLS1.2 will not work, so this is not limited to just 1 client.. Could it still be the cert then? (this is what openssl reports:)
0 s:CN = DOMAININQUESTION.ORG
i:C = US, O = Let's Encrypt, CN = E5
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Jul 26 21:35:31 2025 GMT; NotAfter: Oct 24 21:35:30 2025 GMT
1 s:C = US, O = Let's Encrypt, CN = E5
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
Checking the host you originally provided it looks like your server is only configured to support TLS 1.3 - so it's not really the clients fault that TLS1.2 doesn't work.
If you are unable to configure your service to support TLS1.2 and your client doesn't support TLS1.3 (many don't) you could run a reverse proxy on your server to handle the https conversations between the client and the altova service, however it seems highly unlikely that altova doesn't support TLS1.2 at all.
I Totally agree with you here. weird thing is, this machine is running ubuntu focal, and all the ciphers for TLS1.2 are present but we just cannot get it to work so that is why i needed to check if the cause is not the certificate. We use the same certificate on an other proxy as well and on that machine it work like a charm.
I understand that this is clearly not an issue for this forum so i am going to look elsewhere, but it puzzles me, how it can even be done, configureing a linux machine to only support TLS1.3..
(for those who are intrested, the /etc/ssl/openssl.cnf has this in the config:)
But again, i understand i should not ask for assistance in this matter in this forum, i will ask this in ubuntu forums... .. Thanks for your help though @webprofusion !!! Highly appreciated!
We have already contacted the Altova support, they claim not to do anything with SSL/TLS, they "use" whatever the system has.. so according to them, it is a system limitation...
thanks for the remark on the leaf cert, i will look into that!..
