Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Your Certificates
Select your existing Certificate and remove it then import the new one from ~/fedora-browser-cert.p12 you will be able to log in to koji
* Please note that you can only have one client side certificate at a time. when you download a new one your old one is revoked. Please also only click on the "Download a client-side certificate" link once as it makes multiple requests and revokes all the transient certs.
the CRL is at https://admin.fedoraproject.org/ca/crl.pem
Thanks for your understanding and patience.
Dennis
_______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce
On Fri, 2008-08-22 at 10:20 -0500, Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Your Certificates
Select your existing Certificate and remove it then import the new one from ~/fedora-browser-cert.p12 you will be able to log in to koji
I did this and I am still not able to log in to koji (trying with epiphany and firefox). This error pops out:
Secure Connection Failed
An error occurred during a connection to koji.fedoraproject.org.
Peer does not recognize and trust the CA that issued your certificate.
(Error code: ssl_error_unknown_ca_alert)
The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
* Please contact the web site owners to inform them of this problem.
Is it me, or is it koji problem?
Thanks, Martin
Martin Sourada wrote:
On Fri, 2008-08-22 at 10:20 -0500, Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Your Certificates
Select your existing Certificate and remove it then import the new one from ~/fedora-browser-cert.p12 you will be able to log in to koji
I did this and I am still not able to log in to koji (trying with epiphany and firefox). This error pops out:
Secure Connection Failed
An error occurred during a connection to koji.fedoraproject.org.
Peer does not recognize and trust the CA that issued your certificate.
(Error code: ssl_error_unknown_ca_alert)
The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
* Please contact the web site owners to inform them of this problem.
Is it me, or is it koji problem?
Thanks, Martin
Parts of the Fedora infrastructure do not use certificates issued by a CA already trusted by Firefox, but from Fedora's own certificate authority.
If you decide to trust Fedora to issue certificates that can identify web sites, you could decide to import that CA cert to your set of trusted roots.
You could go to https://admin.fedoraproject.org/fingerprints and install the CA certificate available from the bottom of that page.
(Unfortunately the mime type currently is not application/x-x509-ca-cert so you have to safe that file, and then open it, you might even have to go to certificate manager and open the authorities tab, then import from there.)
You can confirm the origin of the certificate by comparing the fingerprint presented by Firefox with the one listed on the fingerprints page (at least you'll know that the fingerprints page and the CA are controlled by the same people).
Hope that helps, Kai
On Friday 22 August 2008 16:20:03 Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Your Certificates
Select your existing Certificate and remove it then import the new one from ~/fedora-browser-cert.p12 you will be able to log in to koji
I have tried this procedure and it works with firefox, yet when trying to use konqueror (4.1.0) it fails. I have followed the procedure described by Kevin last year:
http://www.mailinglistarchive.com/fedora-devel-list@redhat.com/msg26818.html
The error message is (the same happens for https FWIW):
The requested operation could not be completed Connection to Server Refused Details of the Request: URL: http://koji.fedoraproject.org/koji/login Protocol: http Date and Time: Friday 22 August 2008 20:08 Additional Information: koji.fedoraproject.org: SSL negotiation failed Description: The server koji.fedoraproject.org refused to allow this computer to make a connection.
On Fri, 2008-08-22 at 21:04 +0200, Kai Engert wrote:
Parts of the Fedora infrastructure do not use certificates issued by a CA already trusted by Firefox, but from Fedora's own certificate authority.
If you decide to trust Fedora to issue certificates that can identify web sites, you could decide to import that CA cert to your set of trusted roots.
You could go to https://admin.fedoraproject.org/fingerprints and install the CA certificate available from the bottom of that page.
(Unfortunately the mime type currently is not application/x-x509-ca-cert so you have to safe that file, and then open it, you might even have to go to certificate manager and open the authorities tab, then import from there.)
You can confirm the origin of the certificate by comparing the fingerprint presented by Firefox with the one listed on the fingerprints page (at least you'll know that the fingerprints page and the CA are controlled by the same people).
Hope that helps, Kai
I've already added an exception for https://koji.fedoraproject.org/ both in epiphany and firefox (I trust the fedora issued certificates), however this pages seems rather like my certificate is not being recognized by koji as signed by "known CA authority"...
Martin
On Friday 22 August 2008 02:33:38 pm Martin Sourada wrote:
On Fri, 2008-08-22 at 21:04 +0200, Kai Engert wrote:
Parts of the Fedora infrastructure do not use certificates issued by a CA already trusted by Firefox, but from Fedora's own certificate authority.
If you decide to trust Fedora to issue certificates that can identify web sites, you could decide to import that CA cert to your set of trusted roots.
You could go to https://admin.fedoraproject.org/fingerprints and install the CA certificate available from the bottom of that page.
(Unfortunately the mime type currently is not application/x-x509-ca-cert so you have to safe that file, and then open it, you might even have to go to certificate manager and open the authorities tab, then import from there.)
You can confirm the origin of the certificate by comparing the fingerprint presented by Firefox with the one listed on the fingerprints page (at least you'll know that the fingerprints page and the CA are controlled by the same people).
Hope that helps, Kai
I've already added an exception for https://koji.fedoraproject.org/ both in epiphany and firefox (I trust the fedora issued certificates), however this pages seems rather like my certificate is not being recognized by koji as signed by "known CA authority"...
Martin
Did you remove the old user certificate from your browser?
and make sure you import the new one. Dennis
On Fri, 2008-08-22 at 14:49 -0500, Dennis Gilmore wrote:
Did you remove the old user certificate from your browser?
and make sure you import the new one. Dennis
Unfortunately epiphany does not allow me to remove the old one [1], I removed it in firefox, added in both and selected correct certificate when asked for (in firefox I have obviously only one choice to choose from, in epiphany strangely enough as well, probably because I already removed the old one from HDD).
Martin
References: [1] https://bugzilla.redhat.com/show_bug.cgi?id=437671
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
[snip details of how to change your user cert]
After I did this, plague-client complains when I try to build for EPEL:
Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in <module> cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 81, in __init__ self._email = self._get_user_email() File "/usr/bin/plague-client", line 138, in _get_user_email cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')] make: *** [plague] Error 1
I'm not really sure what this means (maybe the formatting of one of the certs is incorrect?) Did I do something wrong?
Thanks
Tim
On Sat, 23 Aug 2008 10:22:10 +0100, Tim Jackson wrote:
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
[snip details of how to change your user cert]
After I did this, plague-client complains when I try to build for EPEL:
Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in <module> cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 81, in __init__ self._email = self._get_user_email() File "/usr/bin/plague-client", line 138, in _get_user_email cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')] make: *** [plague] Error 1
I'm not really sure what this means (maybe the formatting of one of the certs is incorrect?) Did I do something wrong?
As a work-around, you can delete the plain-text portion from the .fedora.cert (or move it to the end or shorten it). You can recreate it later anytime.
On Sat, 23 Aug 2008 10:22:10 +0100, Tim Jackson wrote:
After I did this, plague-client complains when I try to build for EPEL:
Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in <module> cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 81, in __init__ self._email = self._get_user_email() File "/usr/bin/plague-client", line 138, in _get_user_email cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')] make: *** [plague] Error 1
I'm not really sure what this means (maybe the formatting of one of the certs is incorrect?) Did I do something wrong?
plague-client is broken. My guess in the other reply was good. Apply this:
--- plague-client~ 2008-01-31 15:08:22.000000000 +0100 +++ plague-client 2008-08-23 12:24:53.000000000 +0200 @@ -133,7 +133,7 @@ print "%s does not exist or is not readable." % certfile sys.exit(1) f = open(certfile, "r") - buf = f.read(8192) + buf = f.read() f.close() cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) cert_email = cert.get_subject().emailAddress [
José Matos <jamatos <at> fc.up.pt> writes:
I have tried this procedure and it works with firefox, yet when trying to use konqueror (4.1.0) it fails.
KDE 4 Konqueror currently doesn't support SSL certificate authentication (KIO::TCPSlaveBase::selectClientCertificate is "#if 0"ed out), so no wonder Koji doesn't work with it.
Kevin Kofler
José Matos <jamatos <at> fc.up.pt> writes:
I have tried this procedure and it works with firefox, yet when trying to use konqueror (4.1.0) it fails.
https://bugs.kde.org/show_bug.cgi?id=167668
Kevin Kofler
On Saturday 23 August 2008 05:28:22 am Michael Schwendt wrote:
On Sat, 23 Aug 2008 10:22:10 +0100, Tim Jackson wrote:
After I did this, plague-client complains when I try to build for EPEL:
Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in <module> cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 81, in __init__ self._email = self._get_user_email() File "/usr/bin/plague-client", line 138, in _get_user_email cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')] make: *** [plague] Error 1
I'm not really sure what this means (maybe the formatting of one of the certs is incorrect?) Did I do something wrong?
plague-client is broken. My guess in the other reply was good. Apply this:
--- plague-client~ 2008-01-31 15:08:22.000000000 +0100 +++ plague-client 2008-08-23 12:24:53.000000000 +0200 @@ -133,7 +133,7 @@ print "%s does not exist or is not readable." % certfile sys.exit(1) f = open(certfile, "r")
buf = f.read(8192)
buf = f.read() f.close() cert =
OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) cert_email = cert.get_subject().emailAddress [
its probably due to the new ca cert being 8096 bit and user certs are now all 2048 bit
Dennis
On Fri, Aug 22, 2008 at 09:04:31PM +0200, Kai Engert wrote:
Parts of the Fedora infrastructure do not use certificates issued by a CA already trusted by Firefox, but from Fedora's own certificate authority.
If you decide to trust Fedora to issue certificates that can identify web sites, you could decide to import that CA cert to your set of trusted roots.
Could perhaps Fedora/RHEL drop these certificates under /etc/pki/tls/certs/ to automatically trust them?
If one trusts the Fedora/RHEL keys and packages like firefox for serving the https connections, then there is not much more further trust needed to blindly add these.
On Sat, Aug 23, 2008 at 3:28 AM, Michael Schwendt mschwendt@gmail.com wrote:
plague-client is broken. My guess in the other reply was good. Apply this:
--- plague-client~ 2008-01-31 15:08:22.000000000 +0100 +++ plague-client 2008-08-23 12:24:53.000000000 +0200 @@ -133,7 +133,7 @@ print "%s does not exist or is not readable." % certfile sys.exit(1) f = open(certfile, "r")
buf = f.read(8192)
buf = f.read() f.close() cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) cert_email = cert.get_subject().emailAddress
[
Filed against plague as BZ#459894.
Dennis Gilmore wrote:
login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
Would be fine if anybody port "fedora-packager" for Fedora 8 as well...
~buc
Dennis Gilmore wrote:
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
Both just downloaded ~/.fedora-server-ca.cert and ~/.fedora-upload-ca.cert look strange. Several first lines have a lot of extra spaces before NL... Whereas bottom lines have not. Is it expected behaviour?
On Mon, 25 Aug 2008 15:46:35 +0400, Dmitry Butskoy wrote:
Dennis Gilmore wrote:
login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
Would be fine if anybody port "fedora-packager" for Fedora 8 as well...
It exists already. I installed it with yum.
$ rpm -q fedora-packager fedora-packager-0.3.0-1.fc8
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
According to the "fedora-packager-setup" script, the sources for these two certificates are: https://admin.fedoraproject.org/accounts/fedora-server-ca.cert and https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert respectively.
Does anybody else see the horizontal scrollbar when opening these certificates' links in a browser? IOW, several first lines in both certificates are too long, because of extra spaces at the end-of-line. Try, fe.:
sed 's/$/<NL>/' .fedora-server-ca.cert
My result is:
-----BEGIN CERTIFICATE-----
<NL> MIIK6zCCBt+gAwIBAgIJAMXcvWMyB9ZeMA0GCSqGSIb3DQEBBQUAMIGxMQswCQYD <NL> VQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xpbmExEDAOBgNVBAcTB1JhbGVp <NL> Z2gxFzAVBgNVBAoTDkZlZG9yYSBQcm9qZWN0MRowGAYDVQQLExFGZWRvcmEgUHJv <NL> amVjdCBDQTEaMBgGA1UEAxMRRmVkb3JhIFByb2plY3QgQ0ExJjAkBgkqhkiG9w0B <NL> CQEWF2FkbWluQGZlZG9yYXByb2plY3Qub3JnMB4XDTA4MDgyMDE0NDkxNloXDTE4 <NL> MDgxODE0NDkxNlowgbExCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Ob3J0aCBDYXJv <NL> bGluYTEQMA4GA1UEBxMHUmFsZWlnaDEXMBUGA1UEChMORmVkb3JhIFByb2plY3Qx <NL> GjAYBgNVBAsTEUZlZG9yYSBQcm9qZWN0IENBMRowGAYDVQQDExFGZWRvcmEgUHJv <NL> amVjdCBDQTEmMCQGCSqGSIb3DQEJARYXYWRtaW5AZmVkb3JhcHJvamVjdC5vcmcw <NL> ggQWMA0GCSqGSIb3DQEBAQUAA4IEAwAwggP+AoID9QDIH2F1s0y5V7xBc2tHlXOA <NL> H7999QZ76BU1qtDg4g4k2KyYTG7Gk5eNnJntbpYtRNPL0bQymJIhcfkMCER+UOfv <NL> mum6hrwYSrb0ehsIP1mY9QXdJnlvA1ViXMpZy74byaue9Rn+9GOaOtRWv9dZ5/j4 <NL> Wf9JDOt7TzgFfTPZrtasqlSaOicWJuAKyp2SkQup3I0fTtM4/LpR6BY+dDr7ud9d <NL> LTukkGuOPnNx1pxKkuN0jKYwZjwUcQHlRUNF5xrARU5youYSD7ReWdJsZkirJ0W2 <NL> dZkUQaIUm55v3p4soMYnbPeJFoAbSJkqSCPI4c/ex/Xr1xp3dXvd0vi9K+w8tvw1 <NL> Q3XUvQxum97dbcM7Sw3gRfpFy6K3Up+xXaEnMDGhX31zQAHFTP/P7N+CWNwLg57r <NL> EmuYVfP31b6qsyvuLnpMqe0fYRNWOiJYMALPyRT15RSFGaLyKevqqzR5DFmHQI2C <NL> wl5UFsmBK4LJWqaxE/shuNWEx70BzRYOnPgPr3ohXKBLLxZZtVSlEh+N5FW07Y7T <NL> LkzFGxc0uArsi6EsA9AS0rGJ7FOqMNctvQoR3UFPh5bkXMHgz7aunrB1n5x5rmHk <NL> g/ni5RoxUZgKDuRu1injapnSDC+C3npyk/18g9L7KI810mI/mGFxAtqUcfzG8LP6 <NL> kk7F4ZvwZJaB/rXBhpYqD6nVvybGP1SEiuSUmj9g6iqkL8dtdrLa8arJHJLvuSE3 <NL> VciBR+QNAUE3vyvuifXK4il4QNuvUEqFJOqehkejKbPDkAkQoyIUdr09XBNK1G9O <NL> NbnfJIh+ufiOLpLHr5ya+IM/2DOQTz9WboT74I1dPaI3nxs2iTRrL5Di2xRQlscq <NL> e3RrLlvZF8O5a4VwHy59TY86YLOnRa4+DbcFv+hBdduOMFfTu3kTxJVSJ8UNRPCL<NL> MMh+jpwBrPLcezA/2S2fRsjn0xrVNkZhfVTkKX3IJif6AwRvAKauSzEMj5rFRxaa<NL> 9sJwGV6kDwlmsmVaqXHS1mloJ5eOw07ch7iQQAsHxojneXU6clAKII2lM7AWwoW6<NL> WZIiGb/BCpRL23YbXcq89Aq/Rb6TCekAhBybbodlkYThZmSrUfVbntzj7489vP0k<NL> ClSfVk6j4DNbSdwC89xfnKaOV2d4oVNWUvnQeXy+XZNfgVEpQraJlsN4Nf/hVrUI<NL> aog7qBaZDYxjiiXg2TFcxNrONQruGngCgDBC9kpdaph+irt5Ddb6j8cgsquRG9/j<NL> +CM+gzw3fjKGkijMMyBDsyvlOuNgy+VAahSJvI95P8LLsw4WLub3H3lI4/o+gp0s<NL> VLPMo+j/SypJw/IxDeCV2UvspqhWRDqUj6CUKWHu3jveW327AgMBAAGjggEaMIIB<NL> FjAdBgNVHQ4EFgQUwNk/0QSeuc4HfmzLbSSZrErtu3owgeYGA1UdIwSB3jCB24AU<NL> wNk/0QSeuc4HfmzLbSSZrErtu3qhgbekgbQwgbExCzAJBgNVBAYTAlVTMRcwFQYD<NL> VQQIEw5Ob3J0aCBDYXJvbGluYTEQMA4GA1UEBxMHUmFsZWlnaDEXMBUGA1UEChMO<NL> RmVkb3JhIFByb2plY3QxGjAYBgNVBAsTEUZlZG9yYSBQcm9qZWN0IENBMRowGAYD<NL> VQQDExFGZWRvcmEgUHJvamVjdCBDQTEmMCQGCSqGSIb3DQEJARYXYWRtaW5AZmVk<NL> b3JhcHJvamVjdC5vcmeCCQDF3L1jMgfWXjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3<NL> DQEBBQUAA4ID9QClrBcpX7Ml41iNEKr/b+Dwa0963DQOBl0mgCyNrm2Wvh1WJ2NJ<NL> HCP24A1jRe/AGR3/ORlvynZWfj7toJYpp0Ao21oXkHr4/8yYJfZ+eD+5R/ZmqbMS<NL> fhsmxsHpFFLfMa3iQsyM/ys/A61Y0f16w77TM0IwaVA3+f23V4xvfirKIMkP+8My<NL> r7TSX9mN7VZd3X4zHBgRBefufOic24SWNKD7zBooh9r+yV63HbmlWRoa6xoJlS/M<NL> OYGO80/AdqQ1iVe+F2zgDHQrQWWARHn3p3oE5JSI4m7UBaLpf1ei2HjeG0tUntVW<NL> 32RGHalofN++bvVBqppKo1ijNQbTBMX9WcCMd3nE80X9LW7ZfqNDGJigl8WBPVNN<NL> 278fMWj/XsCYS4XwojJLzzeBmilEnD6SYwkmgEtcLnY91hsJzvbbglFeSAVUvfyA<NL> iCbnHmZbNugH6HiiTrXlXDI85XUEB3kn3orKhNaeerPfo/GnBXoNFw3tSs3QrWSm<NL> b8KQbPDgErvNP9thug/4xg+rPxo3oh5lbqQJ5HvDne+V/6tvW7TeHqzJ4k+OJguZ<NL> x4GAD87I+cLfPICRGwUFQ4EuA5vhQ4FVAfjKgXSyzqpNuCt8JTotyjIh3t6vk7YQ<NL> udtkBCixVxtM5U7i78SME+h+QhrNj5DsxB4K3BLpqWnqOigLVkxRxeBVXjDL2+hn<NL> izx4eJvkNiIVKtB9tgKjSy7led3Wc/k1Ut0NjZ/iFB8WCo7me0jnVHSebxD9olA7<NL> n606/L5gfAN+Ln4hjbVJL+tEgdWezP5pJHwEDBWyQLtQmsxEKQPeDVgi5BTQNRNi<NL> X0xnfgTShhDKN4mEq+Y1C8IMqbi0vb01P4CA9IU2cHcrH26Apq/xKBSnnfDAh1yy<NL> LHBF738arlYVBeaqoUrKhroXxr4wQprIGu/AdPKEXz2c29TE5H7yjRSvIy7ui7EN<NL> NujCosP/IO7YBFhkpDYPq2fByQO5jiZAF58eVX2TlbjM4N+SDG/bpP0WeWlq0JHK<NL> FmxcI5N+s7mR0uK3h0WF5fl1vK/d53YzFO6dI/I5Kh8LVtq0diyYmw6LHXPlTJiJ<NL> nk7ILFds81Ii6EvMmOPD+MX/BQ/YJRaCclixFLk/KaTap8/fZLBotG/5SjBdwFOd<NL> UwVntskUTnai3Vjw0XuBUuKhotenjH/aPbewm/VN9TDjGq9pxaCI8rHX02CIU64U<NL> QuJak6mhyUyB/km02afEYBDDh+lPljKOnmfQhVJXvtBUSbtY/cWP4gJZ901u27fG<NL> Xs6hMQbMUn3fYy43Z3VX/BCS+P2UhorNQB6p17xTs0kTM9pI8aDy/uCwk3F+K/uW<NL> YPF6KxAYMs2ema7PGl2D<NL> -----END CERTIFICATE-----<NL>
Perhaps the binary data (incapsulated in the base64 form) is OK, but the fact that there are such strange "in general" and strange "invisible" garbage in the security-sensitive data causes people at least to ask about it...
~buc
Dmitry Butskoy wrote:
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
According to the "fedora-packager-setup" script, the sources for these two certificates are: https://admin.fedoraproject.org/accounts/fedora-server-ca.cert and https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert respectively.
Does anybody else see the horizontal scrollbar when opening these certificates' links in a browser? IOW, several first lines in both certificates are too long, because of extra spaces at the end-of-line. Try, fe.:
sed 's/$/<NL>/' .fedora-server-ca.cert
My result is:
-----BEGIN CERTIFICATE-----
<NL> MIIK6zCCBt+gAwIBAgIJAMXcvWMyB9ZeMA0GCSqGSIb3DQEBBQUAMIGxMQswCQYD <NL> VQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xpbmExEDAOBgNVBAcTB1JhbGVp <NL> Z2gxFzAVBgNVBAoTDkZlZG9yYSBQcm9qZWN0MRowGAYDVQQLExFGZWRvcmEgUHJv <NL> amVjdCBDQTEaMBgGA1UEAxMRRmVkb3JhIFByb2plY3QgQ0ExJjAkBgkqhkiG9w0B <NL> CQEWF2FkbWluQGZlZG9yYXByb2plY3Qub3JnMB4XDTA4MDgyMDE0NDkxNloXDTE4 <NL> MDgxODE0NDkxNlowgbExCzAJBgNVBAYTAlVTMRcwFQYDVQQIEw5Ob3J0aCBDYXJv <NL> bGluYTEQMA4GA1UEBxMHUmFsZWlnaDEXMBUGA1UEChMORmVkb3JhIFByb2plY3Qx <NL> GjAYBgNVBAsTEUZlZG9yYSBQcm9qZWN0IENBMRowGAYDVQQDExFGZWRvcmEgUHJv <NL> amVjdCBDQTEmMCQGCSqGSIb3DQEJARYXYWRtaW5AZmVkb3JhcHJvamVjdC5vcmcw <NL> ggQWMA0GCSqGSIb3DQEBAQUAA4IEAwAwggP+AoID9QDIH2F1s0y5V7xBc2tHlXOA <NL> H7999QZ76BU1qtDg4g4k2KyYTG7Gk5eNnJntbpYtRNPL0bQymJIhcfkMCER+UOfv <NL> mum6hrwYSrb0ehsIP1mY9QXdJnlvA1ViXMpZy74byaue9Rn+9GOaOtRWv9dZ5/j4 <NL> Wf9JDOt7TzgFfTPZrtasqlSaOicWJuAKyp2SkQup3I0fTtM4/LpR6BY+dDr7ud9d <NL> LTukkGuOPnNx1pxKkuN0jKYwZjwUcQHlRUNF5xrARU5youYSD7ReWdJsZkirJ0W2 <NL> dZkUQaIUm55v3p4soMYnbPeJFoAbSJkqSCPI4c/ex/Xr1xp3dXvd0vi9K+w8tvw1 <NL> Q3XUvQxum97dbcM7Sw3gRfpFy6K3Up+xXaEnMDGhX31zQAHFTP/P7N+CWNwLg57r <NL> EmuYVfP31b6qsyvuLnpMqe0fYRNWOiJYMALPyRT15RSFGaLyKevqqzR5DFmHQI2C <NL> wl5UFsmBK4LJWqaxE/shuNWEx70BzRYOnPgPr3ohXKBLLxZZtVSlEh+N5FW07Y7T <NL> LkzFGxc0uArsi6EsA9AS0rGJ7FOqMNctvQoR3UFPh5bkXMHgz7aunrB1n5x5rmHk <NL> g/ni5RoxUZgKDuRu1injapnSDC+C3npyk/18g9L7KI810mI/mGFxAtqUcfzG8LP6 <NL> kk7F4ZvwZJaB/rXBhpYqD6nVvybGP1SEiuSUmj9g6iqkL8dtdrLa8arJHJLvuSE3 <NL> VciBR+QNAUE3vyvuifXK4il4QNuvUEqFJOqehkejKbPDkAkQoyIUdr09XBNK1G9O <NL> NbnfJIh+ufiOLpLHr5ya+IM/2DOQTz9WboT74I1dPaI3nxs2iTRrL5Di2xRQlscq <NL> e3RrLlvZF8O5a4VwHy59TY86YLOnRa4+DbcFv+hBdduOMFfTu3kTxJVSJ8UNRPCL<NL> MMh+jpwBrPLcezA/2S2fRsjn0xrVNkZhfVTkKX3IJif6AwRvAKauSzEMj5rFRxaa<NL> 9sJwGV6kDwlmsmVaqXHS1mloJ5eOw07ch7iQQAsHxojneXU6clAKII2lM7AWwoW6<NL> WZIiGb/BCpRL23YbXcq89Aq/Rb6TCekAhBybbodlkYThZmSrUfVbntzj7489vP0k<NL> ClSfVk6j4DNbSdwC89xfnKaOV2d4oVNWUvnQeXy+XZNfgVEpQraJlsN4Nf/hVrUI<NL> aog7qBaZDYxjiiXg2TFcxNrONQruGngCgDBC9kpdaph+irt5Ddb6j8cgsquRG9/j<NL> +CM+gzw3fjKGkijMMyBDsyvlOuNgy+VAahSJvI95P8LLsw4WLub3H3lI4/o+gp0s<NL> VLPMo+j/SypJw/IxDeCV2UvspqhWRDqUj6CUKWHu3jveW327AgMBAAGjggEaMIIB<NL> FjAdBgNVHQ4EFgQUwNk/0QSeuc4HfmzLbSSZrErtu3owgeYGA1UdIwSB3jCB24AU<NL> wNk/0QSeuc4HfmzLbSSZrErtu3qhgbekgbQwgbExCzAJBgNVBAYTAlVTMRcwFQYD<NL> VQQIEw5Ob3J0aCBDYXJvbGluYTEQMA4GA1UEBxMHUmFsZWlnaDEXMBUGA1UEChMO<NL> RmVkb3JhIFByb2plY3QxGjAYBgNVBAsTEUZlZG9yYSBQcm9qZWN0IENBMRowGAYD<NL> VQQDExFGZWRvcmEgUHJvamVjdCBDQTEmMCQGCSqGSIb3DQEJARYXYWRtaW5AZmVk<NL> b3JhcHJvamVjdC5vcmeCCQDF3L1jMgfWXjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3<NL> DQEBBQUAA4ID9QClrBcpX7Ml41iNEKr/b+Dwa0963DQOBl0mgCyNrm2Wvh1WJ2NJ<NL> HCP24A1jRe/AGR3/ORlvynZWfj7toJYpp0Ao21oXkHr4/8yYJfZ+eD+5R/ZmqbMS<NL> fhsmxsHpFFLfMa3iQsyM/ys/A61Y0f16w77TM0IwaVA3+f23V4xvfirKIMkP+8My<NL> r7TSX9mN7VZd3X4zHBgRBefufOic24SWNKD7zBooh9r+yV63HbmlWRoa6xoJlS/M<NL> OYGO80/AdqQ1iVe+F2zgDHQrQWWARHn3p3oE5JSI4m7UBaLpf1ei2HjeG0tUntVW<NL> 32RGHalofN++bvVBqppKo1ijNQbTBMX9WcCMd3nE80X9LW7ZfqNDGJigl8WBPVNN<NL> 278fMWj/XsCYS4XwojJLzzeBmilEnD6SYwkmgEtcLnY91hsJzvbbglFeSAVUvfyA<NL> iCbnHmZbNugH6HiiTrXlXDI85XUEB3kn3orKhNaeerPfo/GnBXoNFw3tSs3QrWSm<NL> b8KQbPDgErvNP9thug/4xg+rPxo3oh5lbqQJ5HvDne+V/6tvW7TeHqzJ4k+OJguZ<NL> x4GAD87I+cLfPICRGwUFQ4EuA5vhQ4FVAfjKgXSyzqpNuCt8JTotyjIh3t6vk7YQ<NL> udtkBCixVxtM5U7i78SME+h+QhrNj5DsxB4K3BLpqWnqOigLVkxRxeBVXjDL2+hn<NL> izx4eJvkNiIVKtB9tgKjSy7led3Wc/k1Ut0NjZ/iFB8WCo7me0jnVHSebxD9olA7<NL> n606/L5gfAN+Ln4hjbVJL+tEgdWezP5pJHwEDBWyQLtQmsxEKQPeDVgi5BTQNRNi<NL> X0xnfgTShhDKN4mEq+Y1C8IMqbi0vb01P4CA9IU2cHcrH26Apq/xKBSnnfDAh1yy<NL> LHBF738arlYVBeaqoUrKhroXxr4wQprIGu/AdPKEXz2c29TE5H7yjRSvIy7ui7EN<NL> NujCosP/IO7YBFhkpDYPq2fByQO5jiZAF58eVX2TlbjM4N+SDG/bpP0WeWlq0JHK<NL> FmxcI5N+s7mR0uK3h0WF5fl1vK/d53YzFO6dI/I5Kh8LVtq0diyYmw6LHXPlTJiJ<NL> nk7ILFds81Ii6EvMmOPD+MX/BQ/YJRaCclixFLk/KaTap8/fZLBotG/5SjBdwFOd<NL> UwVntskUTnai3Vjw0XuBUuKhotenjH/aPbewm/VN9TDjGq9pxaCI8rHX02CIU64U<NL> QuJak6mhyUyB/km02afEYBDDh+lPljKOnmfQhVJXvtBUSbtY/cWP4gJZ901u27fG<NL> Xs6hMQbMUn3fYy43Z3VX/BCS+P2UhorNQB6p17xTs0kTM9pI8aDy/uCwk3F+K/uW<NL> YPF6KxAYMs2ema7PGl2D<NL> -----END CERTIFICATE-----<NL>
Perhaps the binary data (incapsulated in the base64 form) is OK, but the fact that there are such strange "in general" and strange "invisible" garbage in the security-sensitive data causes people at least to ask about it...
...and both of the certificate are identical (previously were different)?
~buc
On Monday 25 August 2008 09:56:10 am Dmitry Butskoy wrote:
Dmitry Butskoy wrote:
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
According to the "fedora-packager-setup" script, the sources for these two certificates are: https://admin.fedoraproject.org/accounts/fedora-server-ca.cert and https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert respectively.
<snip>
Perhaps the binary data (incapsulated in the base64 form) is OK, but the fact that there are such strange "in general" and strange "invisible" garbage in the security-sensitive data causes people at least to ask about it...
ive had one other report of the certs being weird looking. and i was unable to reproduce the issue. they look fine to me in all sources. from the original all the way through what ive downloaded in the three exposed places. what did you use to open them?
...and both of the certificate are identical (previously were different)?
yes we were using 2 CA's previously. now we only use one.
the ca cert is also linked https://admin.fedoraproject.org/fingerprints
Dennis
2008/8/22 Kai Engert kaie@redhat.com:
Parts of the Fedora infrastructure do not use certificates issued by a CA already trusted by Firefox, but from Fedora's own certificate authority.
If you decide to trust Fedora to issue certificates that can identify web sites, you could decide to import that CA cert to your set of trusted roots.
You could go to https://admin.fedoraproject.org/fingerprints and install the CA certificate available from the bottom of that page.
(Unfortunately the mime type currently is not application/x-x509-ca-cert so you have to safe that file, and then open it, you might even have to go to certificate manager and open the authorities tab, then import from there.)
You can confirm the origin of the certificate by comparing the fingerprint presented by Firefox with the one listed on the fingerprints page (at least you'll know that the fingerprints page and the CA are controlled by the same people).
Hope that helps, Kai
Has anyone had any luck importing the revocation list into Firefox? When I choose the import button on the revocation list tab, I do not get a file browser like I do with the other options. I just get a box asking me where the revocation list information is stored, with a text field. I put the absolute pathname in, click OK ... and nothing happens. No error messages. No success either.
Dennis Gilmore wrote:
ive had one other report of the certs being weird looking. and i was unable to reproduce the issue. they look fine to me in all sources. from the original all the way through what ive downloaded in the three exposed places. what did you use to open them?
Vi.
$ vi .fedora-server-ca.cert
Compare top and bottom half of the file. First lines are too long (because of the extra spaces), bottom lines not.
Or use "od -x" ...
~buc
On Monday 25 August 2008 11:02:21 am Dmitry Butskoy wrote:
Dennis Gilmore wrote:
ive had one other report of the certs being weird looking. and i was unable to reproduce the issue. they look fine to me in all sources. from the original all the way through what ive downloaded in the three exposed places. what did you use to open them?
Vi.
$ vi .fedora-server-ca.cert
Compare top and bottom half of the file. First lines are too long (because of the extra spaces), bottom lines not.
Or use "od -x" ...
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
Dennis
Dennis Gilmore wrote:
On Monday 25 August 2008 11:02:21 am Dmitry Butskoy wrote:
Dennis Gilmore wrote:
ive had one other report of the certs being weird looking. and i was unable to reproduce the issue. they look fine to me in all sources. from the original all the way through what ive downloaded in the three exposed places. what did you use to open them?
Vi.
$ vi .fedora-server-ca.cert
Compare top and bottom half of the file. First lines are too long (because of the extra spaces), bottom lines not.
Or use "od -x" ...
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
Sent you in private.
~buc
On Mon, 25 Aug 2008 12:07:10 -0500, Dennis Gilmore wrote:
On Monday 25 August 2008 11:02:21 am Dmitry Butskoy wrote:
Dennis Gilmore wrote:
ive had one other report of the certs being weird looking. and i was unable to reproduce the issue. they look fine to me in all sources. from the original all the way through what ive downloaded in the three exposed places. what did you use to open them?
Vi.
$ vi .fedora-server-ca.cert
Compare top and bottom half of the file. First lines are too long (because of the extra spaces), bottom lines not.
Or use "od -x" ...
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
Just follow the thread...
$ wget https://admin.fedoraproject.org/accounts/fedora-server-ca.cert $ emacs fedora-server-ca.cert
On Mon, Aug 25, 2008 at 09:59:31AM -0600, Jerry James wrote:
Has anyone had any luck importing the revocation list into Firefox? When I choose the import button on the revocation list tab, I do not get a file browser like I do with the other options. I just get a box asking me where the revocation list information is stored, with a text field. I put the absolute pathname in, click OK ... and nothing happens. No error messages. No success either.
I am far from on expert on such things, but I did happen to just do this for my personal infrastructure. (Plus, I stayed at a Holiday Inn Express last night!)
It looks to me like the CRL is in a PEM format instead of a DER format. Perhaps the crl tool will convert it properly (haven't tried)?
http://www.openssl.org/docs/apps/crl.html
Hth!
John
On Monday 25 August 2008 01:00:25 pm John W. Linville wrote:
On Mon, Aug 25, 2008 at 09:59:31AM -0600, Jerry James wrote:
Has anyone had any luck importing the revocation list into Firefox? When I choose the import button on the revocation list tab, I do not get a file browser like I do with the other options. I just get a box asking me where the revocation list information is stored, with a text field. I put the absolute pathname in, click OK ... and nothing happens. No error messages. No success either.
I am far from on expert on such things, but I did happen to just do this for my personal infrastructure. (Plus, I stayed at a Holiday Inn Express last night!)
It looks to me like the CRL is in a PEM format instead of a DER format. Perhaps the crl tool will convert it properly (haven't tried)?
http://www.freesoft.org/CIE/RFC/1422/34.htm
apache expects the crl to be pem format http://www.apache- ssl.org/docs.html#SSLUseCRL we are using the crl with apache on the lookaside cache and koji.
Dennis
On Mon, Aug 25, 2008 at 01:21:26PM -0500, Dennis Gilmore wrote:
On Monday 25 August 2008 01:00:25 pm John W. Linville wrote:
On Mon, Aug 25, 2008 at 09:59:31AM -0600, Jerry James wrote:
Has anyone had any luck importing the revocation list into Firefox?
It looks to me like the CRL is in a PEM format instead of a DER format. Perhaps the crl tool will convert it properly (haven't tried)?
http://www.freesoft.org/CIE/RFC/1422/34.htm
apache expects the crl to be pem format http://www.apache- ssl.org/docs.html#SSLUseCRL we are using the crl with apache on the lookaside cache and koji.
Sure, fine. But Jerry was trying to load the CRL into his browser, and AFAIK Firefox wants the DER format.
John
Dennis Gilmore wrote:
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
Take a look at the files with :set list on in vim, e.g.:
curl https://admin.fedoraproject.org/accounts/fedora-upload-ca.cert%7C%5C vim -c 'set list' -
On Mon August 25 2008, Dennis Gilmore wrote:
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
I can reproduce it with: curl --silent https://admin.fedoraproject.org/accounts/fedora-server-ca.cert | xxd | head -n 241
Regards, Till
Till Maas wrote:
On Mon August 25 2008, Dennis Gilmore wrote:
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
I can reproduce it with: curl --silent https://admin.fedoraproject.org/accounts/fedora-server-ca.cert | xxd | head -n 241
Regards, Till
It is also very easy to see if you go to the page in Firefox and do Edit->Select All. The trailing whitespace is very visible.
rob
Rob Crittenden wrote:
Till Maas wrote:
On Mon August 25 2008, Dennis Gilmore wrote:
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
I can reproduce it with: curl --silent https://admin.fedoraproject.org/accounts/fedora-server-ca.cert | xxd | head -n 241
Regards, Till
It is also very easy to see if you go to the page in Firefox and do Edit->Select All. The trailing whitespace is very visible.
rob
Dennis,
It would be very fine if you have confirmed that you see the spaces as well. Otherwise, in the context of recent events, our concern may grow a lot...
~buc
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
Anyone else seeing issues when running the f-p-s process on Fedora 9?
I'm seeing the following errors
$ fedora-packager-setup Setting up Koji client... Cannot specify -r, -p or -N if -O is given. Usage: wget [OPTION]... [URL]... $
Regards, Peter
Peter Robinson wrote:
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
Anyone else seeing issues when running the f-p-s process on Fedora 9?
I'm seeing the following errors
$ fedora-packager-setup Setting up Koji client... Cannot specify -r, -p or -N if -O is given. Usage: wget [OPTION]... [URL]...
You likely have timestamping=on in a wgetrc file. For a while now, wget has gone stupid when using -N (aka timestamping=on) and -O.
[I think this has changed from an error to a warning wget now, though I'm not sure if that's in a released version of wget or not. I simply use curl instead of wget where possible these days.]
Dmitry Butskoy wrote:
Rob Crittenden wrote:
Till Maas wrote:
On Mon August 25 2008, Dennis Gilmore wrote:
i use vi and it honestly is as expected. could you email me your copy of one of the ca certs so i can see on the file you got. ive not been able to reproduce it at all.
I can reproduce it with: curl --silent https://admin.fedoraproject.org/accounts/fedora-server-ca.cert | xxd | head -n 241
Regards, Till
It is also very easy to see if you go to the page in Firefox and do Edit->Select All. The trailing whitespace is very visible.
rob
Dennis,
It would be very fine if you have confirmed that you see the spaces as well. Otherwise, in the context of recent events, our concern may grow a lot...
I can confirm that I get the version with extra spaces and that the extra spaces are present in the cert that's in puppet (and from there pushed out to the web server). I'll let Dennis handle anything else about this, though.
-Toshio
Axel Thimm wrote:
Could perhaps Fedora/RHEL drop these certificates under /etc/pki/tls/certs/ to automatically trust them?
If one trusts the Fedora/RHEL keys and packages like firefox for serving the https connections, then there is not much more further trust needed to blindly add these.
No comments? I thought this sounded like a good idea...
On Tuesday 26 August 2008, Todd Zullinger wrote:
Peter Robinson wrote:
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
Anyone else seeing issues when running the f-p-s process on Fedora 9?
I'm seeing the following errors
$ fedora-packager-setup Setting up Koji client... Cannot specify -r, -p or -N if -O is given. Usage: wget [OPTION]... [URL]...
A fix/workaround against f-p-s 0.3.1 for that is at https://bugzilla.redhat.com/459826
You likely have timestamping=on in a wgetrc file. For a while now, wget has gone stupid when using -N (aka timestamping=on) and -O.
Right, https://bugzilla.redhat.com/441862
[I think this has changed from an error to a warning wget now, though I'm not sure if that's in a released version of wget or not.
Yep, released upstream (1.11.3+) I hear, but the new version is only in Rawhide in Fedora. Hopefully the wget maintainer acts on this soon for released distro versions (see above bug report).
I simply use curl instead of wget where possible these days.]
Ditto, and have ported a bunch of apps to do that too. Upstreams have been quite receptive to these changes.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Your Certificates
Select your existing Certificate and remove it
In my brower cretificate list, I have a number of Red Hat certificates, but no Fedora certificates.
What might the details be of the Certificate that we are supposed to delete ?
then import the new one from ~/fedora-browser-cert.p12
I do not have a ~/fedora-browser-cert.p12
How/when was this supposed to have been created ?
Thank you, and all the best,
- -Greg
you will be able to log in to koji
- Please note that you can only have one client side certificate at a time.
when you download a new one your old one is revoked. Please also only click on the "Download a client-side certificate" link once as it makes multiple requests and revokes all the transient certs.
the CRL is at https://admin.fedoraproject.org/ca/crl.pem
Thanks for your understanding and patience.
Dennis
Fedora-devel-announce mailing list Fedora-devel-announce@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce
- -- +---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log)
| Greg Hosler ghosler@redhat.com | +---------------------------------------------------------------------+
On Sunday 08 March 2009 07:50:14 am Gregory Hosler wrote:
Dennis Gilmore wrote:
Effective immediately we have replaced the CA that is in use for cvs.fedoraproject.org and koji.fedoraproject.org This effects uploading to lookaside cache and building packages.
There are some manual steps that everyone needs to do to be able to use the systems again.
they are login to https://admin.fedoraproject.org/accounts/ and click on the "Download a client-side certificate" link at the bottom of the home page. save the output to ~/.fedora.cert
rm ~/.fedora-server-ca.cert ~/.fedora-upload-ca.cert fedora-packager-setup
then open your browser got to Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Your Certificates
Select your existing Certificate and remove it
In my brower cretificate list, I have a number of Red Hat certificates, but no Fedora certificates.
What might the details be of the Certificate that we are supposed to delete ?
then import the new one from ~/fedora-browser-cert.p12
I do not have a ~/fedora-browser-cert.p12
How/when was this supposed to have been created ?
when you ran fedora-packager-setup it should have been created. you would have been prompted to create a password for the cert.
Dennis
devel@lists.stg.fedoraproject.org