On 11/18/2014 05:44 PM, Reindl Harald wrote:
Am 18.11.2014 um 16:12 schrieb Michael Catanzaro:
On Tue, 2014-11-18 at 12:11 +0100, Florian Weimer wrote:
Firefox also builds a repository of intermediate certificates over
time
and uses them automatically to fill gaps in certificate chains for
On Tue, 2014-11-18 at 12:11 +0100, Florian Weimer wrote:
Firefox also builds a repository of intermediate certificates over
time
and uses them automatically to fill gaps in certificate chains for
completely unrelated sites. This leads to somewhat non-predictable
behavior regarding the set
Am 18.11.2014 um 16:12 schrieb Michael Catanzaro:
On Tue, 2014-11-18 at 12:11 +0100, Florian Weimer wrote:
Firefox also builds a repository of intermediate certificates over
time
and uses them automatically to fill gaps in certificate chains for
completely unrelated sites. This leads to
On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote:
Nevertheless, I am still unsure how to proceed with RubyGems. Should I
ship the bundled certificates again? Or should I wait until somebody
notices?
Sorry for my late reply, because I didn't have a good suggestion
earlier.
We should work
On Fri, 2014-10-31 at 14:05 +0100, Kai Engert wrote:
On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote:
Nevertheless, I am still unsure how to proceed with RubyGems. Should I
ship the bundled certificates again? Or should I wait until somebody
notices?
Sorry for my late reply, because
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote:
We should work with the upstream OpenSSL and the GnuTLS projects,
and
motivate them to implement more advanced path building. This would
be a
long term project.
Is there some issue with gnutls in F21? As far as I
On Fri, 2014-10-31 at 09:49 -0500, Michael Catanzaro wrote:
We should work with the upstream OpenSSL and the GnuTLS projects,
and
motivate them to implement more advanced path building. This would
be a
long term project.
Is there some issue with gnutls in F21? As far as I understand
Am 31.10.2014 um 15:53 schrieb Nikos Mavrogiannopoulos:
On Fri, 2014-10-31 at 09:49 -0500, Michael Catanzaro wrote:
We should work with the upstream OpenSSL and the GnuTLS projects,
and
motivate them to implement more advanced path building. This would
be a
long term project.
Is there
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote:
Sorry for my late reply, because I didn't have a good suggestion
earlier.
We should work with the upstream OpenSSL and the GnuTLS projects, and
motivate them to implement more advanced path building. This would be a
On Fri, 2014-10-31 at 16:11 +0100, Reindl Harald wrote:
Are you sure that this is the case with the current package? My F21 can
no longer connect to network to test, but gnutls in it should
reconstruct the chain similarly to what nss does (not very similarly to
be precise but the end
On Fri, 2014-10-31 at 15:53 +0100, Nikos Mavrogiannopoulos wrote:
Are you sure that this is the case with the current package? My F21
can
no longer connect to network to test, but gnutls in it should
reconstruct the chain similarly to what nss does (not very similarly
to
be precise but the
On Fri, 2014-10-31 at 16:28 +0100, Kai Engert wrote:
I confirm that using GnuTLS 3.3.9-2.fc21 on Fedora 21 testing,
with ca-certificates-2014.2.1-1.3.fc21,
and ca-legacy set to disabled,
the command
gnutls-cli -p443 www.amazon.com
reports a trusted certificate.
This isn't a recent
- Original Message -
This isn't a recent change, see [1]. I presume Amazon is most likely
still broken in Epiphany (when these roots are removed) as there's been
no action on [1], where we decided that gnutls-cli accepted
www.amazon.com because it uses certs if they're valid for either
Dne 17.9.2014 v 14:05 Kai Engert napsal(a):
On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote:
I believe that we must contact Amazon and Symantec about this issue.
Amazon should remove the second intermediate, ending the path with the
G5 intermediate. This will allow openssl to find the
On Mon, 2014-09-08 at 12:53 +0200, Vít Ondruch wrote:
I believe that we must contact Amazon and Symantec about this issue.
Amazon should remove the second intermediate, ending the path with the
G5 intermediate. This will allow openssl to find the trusted root CA.
Also, Symantec should
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
Unfortunately only NSS works. Both openssl and gnutls fail to connect to
popular sites because of that change. It should not be assumed that the
users of
On Wed, 2014-09-17 at 14:16 +0200, Kai Engert wrote:
I think it's good that we have started experimenting with these
removals
in the testing areas of Fedora, because it raises awareness of these
issues, and hopefully can bring higher priority to getting OpenSSL and
GnuTLS enhanced.
But
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
Unfortunately only NSS works. Both openssl and gnutls fail to connect to
popular sites because of that change. It should not be assumed that the
users of ca-certificates are only programs using nss.
No-one working on
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
Unfortunately only NSS works. Both openssl and gnutls fail to connect to
popular sites because of that change. It should not be assumed that the
users of
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
Unfortunately only NSS works. Both openssl and gnutls fail to connect to
popular sites because of that
On Tue, 2014-09-09 at 10:34 +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
Unfortunately only NSS works. Both
On Mon, 2014-09-08 at 23:26 -0700, Adam Williamson wrote:
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it.
We recently learned the hard
Am 09.09.2014 um 08:26 schrieb Adam Williamson:
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation
On Tue, 2014-09-09 at 15:28 +0200, Reindl Harald wrote:
Am 09.09.2014 um 08:26 schrieb Adam Williamson:
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify
On Sat, 2014-09-06 at 01:58 +0200, Kai Engert wrote:
The failure is with the s3.amazonaws.com host.
Looking at the certificates the server sends:
$ openssl s_client -showcerts -connect s3.amazonaws.com:443 21 \
|egrep s:| i:
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com
Dne 6.9.2014 01:58, Kai Engert napsal(a):
On Tue, 2014-08-26 at 12:36 +0200, Vít Ondruch wrote:
$ gem fetch power_assert
ERROR: Could not find a valid gem 'power_assert' (= 0), here is why:
Unable to download data from https://rubygems.org/ -
SSL_connect returned=1 errno=0
On Mon, 2014-09-08 at 10:06 +0200, Nikos Mavrogiannopoulos wrote:
Unfortunately only NSS works. Both openssl and gnutls fail to connect to
popular sites because of that change. It should not be assumed that the
users of ca-certificates are only programs using nss.
[1] is an interesting read. I
On Mon, 2014-09-08 at 09:00 -0500, Michael Catanzaro wrote:
I guess this is verification based on the rfc5280 path validation.
Unlike that NSS ignores the provided trust chain and tries to construct
a new one internally. That's interesting and happens to work around the
issue here but it
On Mon, 2014-09-08 at 17:07 +0200, Nikos Mavrogiannopoulos wrote:
I understand but this is not the case here. The internet isn't broken
because of gnutls and openssl have some limitation, but because the
current NSS derived ca-certificates work assume the NSS validation
strategy. This should
On Tue, 2014-08-26 at 12:36 +0200, Vít Ondruch wrote:
$ gem fetch power_assert
ERROR: Could not find a valid gem 'power_assert' (= 0), here is why:
Unable to download data from https://rubygems.org/ -
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate
On Mon, 2014-09-01 at 18:03 -0500, Michael Catanzaro wrote:
This update has caused a lot of pain for Epiphany. Could you take a look
at [1] when you get a chance and help us figure out what's gone wrong?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602#c3
Sorry for the delay. I've
On Mon, 2014-08-18 at 23:48 +0200, Kai Engert wrote:
Hello,
this is a heads-up for an update to the ca-certificates package that
I've just submitted for updates-testing for Fedora 19 and 20.
The upstream Mozilla CA list maintainers have decided to start removing
CA certificates that use a
Dne 26.8.2014 17:00, Eric H. Christensen napsal(a):
On Tue, Aug 26, 2014 at 12:36:47PM +0200, Vít Ondruch wrote:
$ gem fetch power_assert
ERROR: Could not find a valid gem 'power_assert' (= 0), here is why:
Unable to download data from https://rubygems.org/ -
SSL_connect
Hi Kay,
This update has potential to break RubyGems with error:
$ gem fetch power_assert
ERROR: Could not find a valid gem 'power_assert' (= 0), here is why:
Unable to download data from https://rubygems.org/ -
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, Aug 26, 2014 at 12:36:47PM +0200, Vít Ondruch wrote:
$ gem fetch power_assert
ERROR: Could not find a valid gem 'power_assert' (= 0), here is why:
Unable to download data from https://rubygems.org/ -
SSL_connect returned=1
- Original Message -
If you experience such situations, the right approach is to contact the
owner of the certificate (or the server), and ask them to get a
replacement certificate, or to install a replacement certificate on
their SSL/TLS server.
That’s the right thing to do of
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
- Original Message -
If you experience such situations, the right approach is to contact the
owner of the certificate (or the server), and ask them to get a
replacement certificate, or to install a replacement certificate on
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
That’s the right thing to do of course, but leaves the users with an
unusable system in the mean time. Could the update description at
least generally point to how to work around this if the certificate
owner is not (sufficiently
- Original Message -
On Tue, 2014-08-19 at 10:07 -0400, Miloslav Trmač wrote:
That’s the right thing to do of course, but leaves the users with an
unusable system in the mean time. Could the update description at
least generally point to how to work around this if the certificate
39 matches
Mail list logo
