fedora-infrastructure

#7616 generic cert for rabbitmq prod/stg
Closed: Fixed by kevin. Opened by pingou.

Closed: Fixed
Reopen Issue

We would like to offer our developers a way to connect (in read-only mode) to our rabbitmq clusters (stg and prod). This would give them the possibility to run fedora-messaging consumer (the equivalent to fedmsg-tail) and see if things are working as intended.

For this, we propose creating a generic certification, maybe batcave/batcave.stg that we would make accessible to our sysadmins on the host of the same name. Then we'll be able to provide a configuration file that everyone can adjust for their need and that would be pointing to these certs giving everyone who needs/wants it a read-only access to our cluster.
(The read-only restricting being applied server-side).

\cc @abompard

PS: I've looked in our repo for a way to generate these certs, I saw the rebuild.sh there but it seems to be only for our cluster. I didn't see a way/script to generate new client certs.

Could we solve this with whatever solution we end up using for the external read-only access?

The certs are made with easy-rsa... which we should document.

Metadata Update from @bowlofeggs:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: authentication, rabbitmq

Is this fixed by just having a read-only public queue? If not, why not?

\cc @jcline

Yeah, seems like the public vhost covers this use case. I'm going to look at getting this working in staging this afternoon.

So, public rabbit access should be pretty much done, the only issues I'm aware of left are that port 5671 on the staging proxies isn't being forwarded to rabbit (it is in prod, though) and we need to distribute the credentials (certs and keys) for the public user (fedora in prod, fedora.stg in staging) which have been generated. I think dropping them in the upstream repository and including them in the RPMs should cover things.

@smooge is putting in another ticket to get stg working. We can keep this open for that, or close...

Whatever is easiest for you to track. Once the proxy issue is sorted out and I have a copy of the fedora certs and keys and I can run some final tests to make sure things are truly working, and then make a fedora-messaging release with documentation on usage.

The firewall looks to be working now. @kevin, can you send me the certificate and key for the public access users (fedora and fedora.stg)? Once I make sure I can authenticate from the outside with those I think we can close this ticket

emailed.

I think there's a problem with the broker's certificate setup. It has a CN and Subject Alt name of "rabbitmq01.stg.phx2.fedoraproject.org", but you can't connect to it with that hostname. Right now you can use stg.fedoraproject.org:5671 to connect to it, but that's not a Subject Alt name.

I think, ideally, the certificate for each broker should include "rabbitmq.stg.fedoraproject.org" in their subject alt names and that should resolve externally so clients can connect using that. Same deal for prod.
Edited by jcline

ok, done in both stg and prod.

:rabbit:

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None

authentication rabbitmq

None
None
Normal
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.