When the B&R PLC sends a HTTPS request to an Ubuntu-server, the HTTPS-client gets a status code: SSL handshake fail.
I checked the certificate of the server on different checking-sites an it said the certificate is valid. In case the PLC sends a request to a server with an older version of the webapp, it gets a 200 OK response.
The same happens when other B&R PLC's send a message to the new server, the response is 200 OK.
can you get more detailed logs around that from PLC?
Perhaps the cert is now ECDSA type and the client only supports RSA type certs.
No I don't cant get more detailed logs because it is running in production mode. The status codes is
35567 which means SSL handshake failed according to the B&R documentation
What type of cert is it?
OR
What is the FQDN of the server?
As far as I know the certificate is RSA type
Are the ciphers the same on the new[er] server as on the old[er] server?
Is there any way to compare the firmware/code running on the PLCs?
name of server is testclms.perfotec.com.
testclms.perfotec.com
has (at least) an ECDSA certificate configured. Note that servers can have both RSA as well as ECDSA certs configured at the same time, but I'm not able to test that currently. But Chrome shows an ECDSA cert in any case.
Same goes for clmsv2.perfotec.com
by the way.
Okay, so maybe that's the problem as @rg305 mentioned? When this is a mismatch, the handshake fails?
Usually, clients support RSA as well as ECDSA, but if the client is either ancient or doesn't support ECDSA for some other reason (e.g., lack of support due to an embedded system which hasn't developed support for it), then it would fail if the server also doesn't support RSA.
SSL Labs only sees the ECDSA cert:
SSL Server Test: testclms.perfotec.com (Powered by Qualys SSL Labs)
This sounds like the way to go forward.
Add an RSA cert to the server [don't replace the ECDSA cert].
If that works, then leave it that way and renew them both.
If that still fails, then remove the ECDSA cert OR speak with the PLC provider about an update/upgrade.
It is possible that the httpsclient is from an older version of B&R. So the ECDSA problem @Osiris mentioned can be the actual problem.
How do I make sure the cert I add is RSA?
Without knowing details about the ACME client used, we can't answer that question.
I mean when I am adding a certificate to the server, how do I make sure it is an RSA certificate?
If you replace the existing certificate with an RSA cert, you can simply use sites like SSL Server Test (Powered by Qualys SSL Labs). But if you're adding the RSA cert to the existing ECDSA cert, I don't think you can see both with SSLLabs.
You can use the openssl s_client
in combination with the -cipher
command by including only (one or more) RSA ciphers or (one or more) ECDSA ciphers. If you use an RSA cipher and it succeeds, the RSA cert has worked.
See e.g. Using certificates with RSA and ECDSA keys at the same time on how to configure Apache or nginx with both RSA and ECDSA at the same time.
You can't add a cert into another cert.
You can add a second cert into a web service.
[when the two certs are of different types - not if the two certs are of the same type]
Yes, it can "see" them both; As both are provided to the client by the web server - and it is the client who choses which one to use.
I should have added 'configuration'.
I believe this is not the case. As far as I know, the server chooses which certificate (chain) to send: either ECDSA or RSA based upon the clients capabilities.