If you only need the certificate to be trusted by your own systems – create your own CA and tell your systems to trust that. It's a common procedure in enterprise networks, especially for systems that won't be exposed to outside (or where public CAs aren't trusted enough).
There are many tools for building your own X.509 CA and issuing TLS certificates from it (or any other type of X.509 certificate). The root CA certificate can then be deployed to all your systems the same way as other configuration.
It is possible to issue them for IP addresses – although you really should not set up your environment to rely on fixed IP addresses to begin with; requiring an IP-based certificate for anything other than a DNS server is often a sign of bad design.
services like let's encrypt offers only domain-based SSL keys
The certificates being domain-based is an integral part of SSL/TLS having "trusted" certificates. Merely having "a trusted certificate" is meaningless; what makes it useful is that the certificate is issued for a specific identity and that you (or rather, your software) can match it against the entity that you're connecting to.
Since most TLS communications are made to a system where the client knows it wants to connect to the holder of a specific domain name, that's also what the certificates are issued for. (Generally that's also the case even for internal systems – while connecting services by IP address seems easy, it's a time-delay headache.)
for webpages
They're not limited to webpages. They're SSL/TLS server certificates. There's no difference in using them for HTTPS or RabbitMQ.