I think the issue is your client code is validating the “ourcname” against the cert, whereas ours is not. Obviously better for security to do the validation. I’m not sure there’s away around it, other than disabling the validation, unless Amazon MQ provides the ability to change the certs used by AMQ.
We’re using CNAMEs that map to the Amazon MQ provided hostnames. I think the reason may be that our clients libraries just aren’t validating the returned cert against the hostname. This isn’t something we’re doing explicitly.
Thanks for the message Dave! I enjoyed reading your post. Sidecars to continually renew the lease ids is also a great solution and not something we’d considered. Would this also work in extending the life of ephemeral credentials? If so, that could allow for tightening of the TTL, so that credentials do not live much longer than the pods. One thing…
Our applications were already using ActiveMQ and this was working well enough for us. We could have chosen a different solution for providing MQ functionality, but this would have introduced more risk, taken much longer to implement and we didn’t see the need. Also, our applications all run on AWS and so using a managed service on AWS made sense.
Not every service is both a producer and a consumer. Some write to one queue and read from another. Many write to a common event queue and then listen to things applicable to them, via virtual queues. It’s not all that complicated, but something we wanted to avoid over-engineering a migration solution for.
Thanks Paul! When I started writing this post, I realized this is one of those topics that is very unspecific to software or engineering in general. But maybe the accelerating pace of software development leads to more breakages and blame opportunities than other industries.