another issue to fix with the FAS2 switch: Kojis ssl certificate

Mike Bonnet mikeb at redhat.com
Tue Mar 11 21:16:15 UTC 2008


On Tue, 2008-03-11 at 21:52 +0100, Till Maas wrote:
> On Tue March 11 2008, Dennis Gilmore wrote:
> > On Tuesday 11 March 2008, Till Maas wrote:
> > > Hiyas,
> > >
> > > now that everyone needs to change his password, can we now also deploy
> > > the new certifcate for koji? This will make it possible to verify whether
> > > or not one can trust the certificate for koji and the ticket[1] is now 7
> > > months old, i.e. about a full Fedora release cycle. Therefore I guess
> > > there won't be a better time than now.
> > >
> > > Regards,
> > > Till
> > >
> > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88
> >
> > No,  Because it will break user certs.  To make it work would require that
> > users all get entirely new server cert files.  We need to redo our entire
> > CA system.  We also need to consider  the ramifications for Secondary
> > arches, deploying a new CA  would require each and every Secondary arch to
> > purchase a cert from the same CA.  or somebody to purchase a cert that
> > covered *.koji.fedoraproject.org from the same CA.
> >
> > we are looking at deploying the hub on a separate box from the frontend
> > which would allow us to do what you are wanting  but would not look after
> > secondary arches.
> 
> How about making the hub (I assume this is only used by automated processes 
> and not manually) listen on a different port than 443? Then the web interface 
> could use the new well know certificate. The automated processes the internal 
> ones, where imho using a own ca does not hurt. Also using a different port 
> should be only a matter of configuring it once.
> The secondary arch instances could then use a cacert[0] certificate, which are 
> free and are trusted by some browsers already for the web interface.

The Koji cli communicates with the hub for all operations, so it would
require everyone to update their Koji config.  In addition, I'm sure
running ssl on a non-standard port would mess with some people's
proxy/firewall setups.  I don't think this is the best solution.





More information about the infrastructure mailing list