You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am new to Artemis and Kubernetes, and by following the information provided in the examples present in this repo, we were able to get the artemis server runnning successfully on kubernetes.
However we are experiencing a TLS hostname verification error while sending messages to the broker over SSL. We are following the instructions provided in the Setting up SSL with cert-manager and trust-manager page.
Steps to Reproduce:
Deploy the Artemis broker using the steps outlined in the above mentioned page.
Configure the broker for SSL using the example configuration provided.
Attempt to send a message to the broker as instructed in the documentation.
2024-10-08 10:54:05,657 WARN [org.apache.activemq.artemis.core.server] AMQ222208: SSL handshake failed for client from /***.***.**.*:51174: java.security.cert.CertificateException: No subject alternative names matching IP address ***.***.**.* found.
If we set either verifyHost: false or needClientAuth: false in artemis_ssl_acceptor_cert_and_trust_managers.yaml, the connection works and we can send and receive the messages over SSL; however, as documentation mentions, this makes the connection less secure.
While trying to troubleshoot the issue, we found out that, inside the artemis pod, we could resolve the ip which we saw in the logs to a hostname which is the certificate generated by cert manager.
[jboss@artemis-broker-ss-0 bin]$ host ***.***.**.*
***.***.**.*.in-addr.arpa domain name pointer ***-***-**-*.artemis-broker-ssl-0-svc.myproject.svc.cluster.local.
***.***.**.*.in-addr.arpa domain name pointer ***-***-**-*.artemis-broker-ping-svc.myproject.svc.cluster.local.
***.***.**.*.in-addr.arpa domain name pointer artemis-broker-ss-0.artemis-broker-hdls-svc.myproject.svc.cluster.local.
I also checked the certificate from the keystore.jks and the SAN contains the correct hostname.
Any help or advice is greatly appreciated.
The text was updated successfully, but these errors were encountered:
I can reproduce this issue on my Kubernetes cluster with trust-manager:v0.12.0. For some reason it doesn't create the key truststore.jks in the config map ca-bundle. Indeed if you enable SSL debugging before executing the producer command you should get the error certificate_unknown:
Anyway the Setting up SSL with cert-manager and trust-manager page is outdated because the latest broker versions support PEM certificates. This means that the tutorial doens't need anymore the additional jks format.
Describe the bug
I am new to Artemis and Kubernetes, and by following the information provided in the examples present in this repo, we were able to get the artemis server runnning successfully on kubernetes.
However we are experiencing a TLS hostname verification error while sending messages to the broker over SSL. We are following the instructions provided in the Setting up SSL with cert-manager and trust-manager page.
Steps to Reproduce:
And when we check the server logs we find
If we set either
verifyHost: false
orneedClientAuth: false
inartemis_ssl_acceptor_cert_and_trust_managers.yaml
, the connection works and we can send and receive the messages over SSL; however, as documentation mentions, this makes the connection less secure.While trying to troubleshoot the issue, we found out that, inside the artemis pod, we could resolve the ip which we saw in the logs to a hostname which is the certificate generated by cert manager.
I also checked the certificate from the keystore.jks and the SAN contains the correct hostname.
Any help or advice is greatly appreciated.
The text was updated successfully, but these errors were encountered: