Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Wed March 12 2008, Till Maas wrote: Btw. is it really needed that the client and server certificates are signed by the same CA? Please ignore this question, what I wanted to ask is what I asked in the other mail I just wrote. Regards, Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tue March 11 2008, Dennis Gilmore wrote: On Tuesday 11 March 2008, Till Maas wrote: [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 Making the user adjust his koji config for this is afaics unavoidable, except when nothing is changed. To make future transitions easier, the ca could be bundled into the fedora-packager package, so that the ca is updated automatically when needed. 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. I do not see a reason for this, what does need this? According to the pyOpenSSL manual[1] the koji client can load several ca files to authenticate the server certificate, because the pem file that is loaded with load_client_ca can contain several certificates, e.g. the current one and the Equifax one. Regards, Till [1] http://pyopenssl.sourceforge.net/pyOpenSSL.ps signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Wed March 12 2008, Till Maas wrote: with load_client_ca can contain several certificates, e.g. the current one and the Equifax one. The relevant function here is load_verify_locations, not load_client_ca. Regards, Till signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
another issue to fix with the FAS2 switch: Kojis ssl certificate
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 signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
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. We currently use 2 different CA's in our setup. One that is used only for user certs and one that is used for the builders and frontend. I would like to move to a new Single CA setup. In this world when you import your fedora user cert for browser authentication you would automatically recognise the CA. though this would only be valid for Fedora contributors. Is this only about Koji or Fedoraprojet in general? Imho it is better to use a well known CA for the frontend (website) and an own one for internal stuff instead of using an own one for everything. Regards, Till [0] https://cacert.org signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
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. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tue, 11 Mar 2008, Mike Bonnet wrote: 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. It's really not that we don't want to do this. It's a lot of work with high potential for breakage and annoyance to everyone and the benefit to most people is unclear. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
