A certificate has been generated from Let's Encrypt and installed onto an existing (working) crossbar server as follows (and as the documentation suggests):
"endpoint": {
"type": "tcp",
"port": 8089,
"tls": {
"key": "../ssl/key.pem",
"certificate": "../ssl/cert.pem"
}
},
When connecting via Java (I am sure the result would have been similar if differently worded in other APIs) the result is:
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found
Having determined this could be due to requiring Let's Encrypt's intermediate certificate that was linked like this:
"endpoint": {
"type": "tcp",
"port": 8089,
"tls": {
"key": "../ssl/key.pem",
"certificate": "../ssl/cert.pem",
"ca_certificates": [
"../ssl/intermediate.cert.pem"
],
}
},
Unfortunately this also does not work, resulting in a handshake error (I didn't note down the exact wording).
Digging further into the documentation I found this example which explicitly references a lets encrypt intermediate but has a different name for the key parameter:
"chain_certificates": [
"lets-encrypt-x3-cross-signed.pem"
],
Trying this resulted in the same issue (handshake failure)
I then tried the following:
So basically this:
"tls": {
"key": "../ssl/key.pem",
"certificate": "../ssl/cert-plus-intermediate.pem"
}
After restarting the server again (you'll need to restart each time you change SSL settings) the connection established correctly. Note also that once you have a working configuration you should ensure the key file can only be read by a trusted user on the system, ideally just whichever user crossbar will run as (chmod 600 key.pem)